prd-to-plan

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

# 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)