prd-to-tickets
PRD to Tickets
Break a PRD into independently-grabbable Linear tickets using vertical slices (tracer bullets).
Process
1. Locate the PRD
Ask where the PRD lives (doc URL, markdown file path, GitHub issue/PR, Notion page, or pasted text).
If the PRD is not in context, fetch or read it first.
2. Explore the codebase (optional)
If you have not already explored the codebase, do so to understand current constraints and integration points.
3. Draft vertical slices
Break the PRD into tracer-bullet slices. Each slice should be a thin end-to-end path through all layers, not a horizontal layer-only task.
Slices may be HITL or AFK.
HITL: requires human interaction (architecture/design/policy sign-off)AFK: can be implemented and merged without human interaction
Prefer AFK where possible.
4. Quiz the user
Present the proposed breakdown as a numbered list. For each slice, show:
- Title: short descriptive name
- Type:
HITLorAFK - Blocked by: required preceding slices, if any
- User stories covered: which PRD user stories this slice addresses
Ask:
- Does granularity feel right? (too coarse or too fine)
- Are dependency relationships correct?
- Should slices be merged or split further?
- Are
HITLandAFKmarks correct?
Iterate until approved.
5. Create Linear parent ticket + subtickets via MCP
Use the Linear MCP to create tickets.
Default hierarchy:
- Create one parent ticket representing the PRD rollout.
- Create one child subticket per approved slice.
- Link all child tickets to the parent.
- Add dependency links between child tickets (
blocked by) where needed.
If the workspace does not support hierarchy, fall back to:
- shared project
- shared labels (
prd,slice,afk,hitl) - parent ticket key included in each child description
Before creation, resolve:
- Linear team
- Linear project (if used)
- Ticket state (Backlog or Todo)
- Label set
- Parent strategy (new parent vs existing parent key)
Create blockers first so dependencies can reference existing ticket IDs.
Use this template for each child ticket description.
What to build
A concise description of this vertical slice. Describe end-to-end behavior, not layer-by-layer implementation. Reference specific PRD sections instead of duplicating content.
Acceptance criteria
- Criterion 1
- Criterion 2
- Criterion 3
Blocked by
- (if any)
Or "None - can start immediately" if no blockers.
User stories addressed
Reference by number or identifier from the PRD:
- User story 3
- User story 7
Execution mode
AFK or HITL
Do not modify the parent PRD source unless the user asks.
Hand-off
After tickets are created, suggest tdd as the implementation skill for each child ticket.
More from ajoslin/dot
pinescript
Use when creating or reviewing TradingView Pine Script v6 indicators/strategies/libraries, applying non-repainting best practices, generating Pine Script from other languages, or running Pine Script linting.
51session-export
Update GitHub PR or GitLab MR descriptions with AI session export summaries. Use when user asks to add session summary to PR/MR, document AI assistance in PR/MR, or export conversation summary to PR/MR description.
21find-skills
Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
20vercel-composition-patterns
React composition patterns that scale. Use when refactoring components with
19kimaki-expert
Provide expert support for Kimaki setup, Discord bot wiring, OpenCode session orchestration, slash-command troubleshooting, and automation workflows. Use when users mention Kimaki, kimaki.xyz, Discord-controlled coding agents, or channel-to-project mapping.
18init-review-policy
Initialize repo-scoped code review policy files under .opencode/review. Use when setting up project-specific review rules for /code-review.
18