PRD Slice
Break a PRD into independently-deliverable vertical slices (tracer bullets) and push them to the right tracker.
Tracker reference files — use the dedicated skill when available; fall back to the reference file only when it isn't:
| Tracker | Preferred source | Fallback (skill absent) |
|---|---|---|
| Azure DevOps | azure-devops-cli skill (if loaded) | references/azure-devops.md |
| GitHub Issues | gh-cli skill (if loaded) | references/github.md |
| Jira | — | references/jira.md |
The dedicated skills (gh-cli, azure-devops-cli) carry richer, up-to-date platform context. When one is present in your available_skills, use it and skip the reference file — loading both is redundant and wastes context.
Scope
In scope: reading a PRD from a tracker, proposing and refining vertical slices with the user, creating work items in dependency order.
Out of scope: writing implementation code, modifying the parent PRD, managing project boards, deciding architecture or technology choices.
Process
1. Identify tracker and locate the PRD
If the tracker isn't already clear from context, ask the user which one they're using.
Ask for the PRD reference (work item ID, issue URL, or document path). Then fetch the PRD content using the command in the relevant reference file.
2. Explore the codebase (optional)
If the codebase hasn't been explored yet, do a quick scan to understand the current state — this helps size slices correctly.
3. Draft vertical slices
Break the PRD into tracer bullet work items. Each slice is a thin end-to-end cut through ALL integration layers — not a horizontal layer slice.
Slices are either:
- HITL — requires human interaction before proceeding (e.g. an architectural decision, a design review)
- AFK — can be implemented and merged without human interaction
Prefer AFK slices where possible.
When the PRD involves many slices — broad scope, many cross-cutting concerns — propose wave grouping to the user before creating work items. Group slices into waves where Wave 1 delivers a standalone, MVP-sufficient experience on its own. Subsequent waves add depth and breadth. Label each slice with its wave (e.g. [Wave 1], [Wave 2]) so the tracker reflects delivery order and teams can plan parallel workstreams within a wave.
4. Quiz the user
Present the proposed breakdown as a numbered list. For each slice show:
- Title: short descriptive name
- Type: HITL / AFK
- Blocked by: which other slices (if any) must complete first
- User stories covered: which PRD user stories this addresses
Ask the user:
- Does the granularity feel right? (too coarse / too fine)
- Are the dependency relationships correct?
- Should any slices be merged or split further?
- Are the HITL / AFK labels right?
- If waves were proposed: does Wave 1 represent a sufficient MVP? Are the wave boundaries right?
Iterate until the user approves the breakdown.
5. Create work items
For GitHub and Azure DevOps, check whether the matching skill (gh-cli or azure-devops-cli) is in your available_skills. If it is, use it — no need to also load the reference file. If it isn't, read references/<tracker>.md for commands and the issue body template. For Jira, always read references/jira.md.
Create work items in dependency order (blockers first) so you can reference real IDs in the "Blocked by" field.
Do NOT close or modify the parent PRD work item.
The skill's work is complete when all approved slices have been created in the tracker and the user has the issue numbers. Return control to the user.