---
name: prd-to-plan
description: "Converts PRD into phased plan via tracer-bullet vertical slices. Triggers: PRD to plan, break down PRD, implementation plan, tracer bullets, phased plan."
user-invocable: true
effort: high
argument-hint: "[PRD issue number or paste PRD]"
allowed-tools: Read, Grep, Glob, Bash, Agent
---
# PRD to Plan
$ARGUMENTS
Break a PRD into a phased implementation plan using vertical slices (tracer bullets). Output is a Markdown file in `./plans/`.
## Usage
```
/prd-to-plan [PRD issue number or description]
```
## What This Command Does
1. **Loads** the PRD (from GitHub issue or conversation)
2. **Explores** the codebase to understand architecture
3. **Identifies** durable architectural decisions
4. **Drafts** vertical slices (tracer bullets)
5. **Quizzes** user on granularity
6. **Writes** plan file to `./plans/`
## Process
### 1. Confirm PRD is in Context
If not provided, ask for the PRD GitHub issue number or content. Fetch with `gh issue view <number>` if needed.
### 2. Explore the Codebase
Use Agent (subagent_type=Explore) to understand current architecture, existing patterns, and integration layers.
### 3. Identify Durable Architectural Decisions
Before slicing, identify decisions unlikely to change:
- Route structures / URL patterns
- Database schema shape
- Key data models
- Authentication / authorization approach
- Third-party service boundaries
### 4. Draft Vertical Slices
Break PRD into **tracer bullet** phases. Each phase is a thin vertical slice cutting through ALL layers end-to-end.
| Rule | Description |
|------|-------------|
| Complete path | Each slice delivers narrow but COMPLETE path through every layer (schema, API, UI, tests) |
| Demoable | A completed slice is demoable or verifiable on its own |
| Thin over thick | Prefer many thin slices over few thick ones |
| Durable | Do NOT include file names, function names, or implementation details likely to change |
| Include decisions | DO include durable decisions: route paths, schema shapes, data model names |
### 5. Quiz the User
Present breakdown as numbered list. For each phase show:
- **Title**: short descriptive name
- **User stories covered**: which stories from the PRD
Ask:
- Does the granularity feel right? (too coarse / too fine)
- Should any phases be merged or split?
Iterate until approved.
### 6. Write Plan File
Create `./plans/` if needed. Write as `./plans/{feature-name}.md`.
## Plan Template
```markdown
# Plan: {Feature Name}
> Source PRD: #{issue-number}
## Architectural Decisions
Durable decisions that apply across all phases:
- **Routes**: ...
- **Schema**: ...
- **Key models**: ...
---
## Phase 1: {Title}
**User stories**: {list from PRD}
### What to build
Concise description of this vertical slice. End-to-end behavior, not layer-by-layer.
### Acceptance criteria
- [ ] Criterion 1
- [ ] Criterion 2
---
## Phase 2: {Title}
(repeat for each phase)
```
## Rules
- **MUST** slice vertically — every phase cuts through all layers (schema, API, UI, tests). Horizontal layer-by-layer phases defer integration risk to the end.
- **MUST** identify Architectural Decisions **before** slicing — decisions that apply across phases live in their own section, not repeated in each phase
- **NEVER** embed file paths, function names, or implementation details that couple the plan to current code — the plan outlives the code it describes
- **NEVER** write the plan file before the user approves the slicing — drafts burn tokens and invite scope drift
- **CRITICAL**: each phase is independently demoable on its own. If phase N only makes sense in combination with phase N+1, merge them.
- **MANDATORY**: the first phase ships **end-to-end** (however thin). Deferring any layer to a later phase defeats tracer-bullet discipline.
## Gotchas
- Architectural Decisions feel like premature commitment — "we can decide routes later". In practice, every phase needs a route to hit, so postponing them creates conflicting guesses across phases. Decide once, apply everywhere.
- PRDs with long lists of user stories tempt the planner to make each story a phase. User stories are requirements, not phases — group several stories into one vertical slice when they share architecture.
- "Demoable" means an external stakeholder can watch the feature work, not that a unit test passes. If a phase only ships backend API with no UI to exercise it, it is not demoable.
- Fetching the PRD with `gh issue view <n>` captures the body but not the comments. Crucial clarifications often live in the comments — include `--comments` or remind the user to paste important threads.
- Plans written against a moving PRD (the PRD is still being edited) invalidate on every edit. Freeze the PRD snapshot at plan-write time, reference the snapshot commit or comment ID.
## When NOT to Use
- For filing GitHub issues from a plan — use `/prd-to-issues`
- For writing the PRD itself — use `/write-a-prd`
- For planning without a PRD — use `/plan` (general-purpose)
- For stress-testing a plan that already exists — use `/grill-me`
- For refactor planning — use `/refactor-plan` (incremental commits, not tracer bullets)