# Matt Prd To Plan
> Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices, saved as a local Markdown file in ./plans/. Use when user wants to break down a PRD, create an implementation plan, plan phases from a PRD, or mentions "tracer bullets".
- Skill: `douglance/matt-prd-to-plan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add douglance/matt-prd-to-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/douglance/matt-prd-to-plan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: douglance (https://skillmd.com/u/douglance)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/douglance/matt-prd-to-plan
---
# PRD to Plan
Break a PRD into a phased implementation plan using vertical slices (tracer bullets). Output is a Markdown file in `./plans/`.
## Process
### 1. Confirm the PRD is in context
The PRD should already be in the conversation. If it isn't, ask the user to paste it or point you to the file.
### 2. Explore the codebase
If you have not already explored the codebase, do so to understand the current architecture, existing patterns, and integration layers.
### 3. Identify durable architectural decisions
Before slicing, identify high-level decisions that are unlikely to change throughout implementation:
- Route structures / URL patterns
- Database schema shape
- Key data models
- Authentication / authorization approach
- Third-party service boundaries
These go in the plan header so every phase can reference them.
### 4. Draft vertical slices
Break the PRD into **tracer bullet** phases. Each phase is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
When a phase has significant unknowns, include an explicit **prototyping milestone** to de-risk before full implementation. Prototypes are additive, testable, and clearly labeled. State criteria for promoting or discarding the prototype.
- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
- A completed slice is demoable or verifiable on its own
- Prefer many thin slices over few thick ones
- Do NOT include specific file names, function names, or implementation details that are likely to change as later phases are built
- DO include durable decisions: route paths, schema shapes, data model names
- Each phase MUST have observable validation — exact commands and expected output, not just "code changes"
- Prefer additive changes followed by subtractions that keep tests passing
### 5. Quiz the user
Present the proposed breakdown as a numbered list. For each phase show:
- **Title**: short descriptive name
- **User stories covered**: which user stories from the PRD this addresses
Ask the user:
- Does the granularity feel right? (too coarse / too fine)
- Should any phases be merged or split further?
Iterate until the user approves the breakdown.
### 6. Write the plan file
Create `./plans/` if it doesn't exist. Write the plan as a Markdown file named after the feature (e.g. `./plans/user-onboarding.md`). Use the template below.
# Plan:
> Source PRD:
This plan is a **living document**. The Progress, Surprises & Discoveries, Decision Log, and Outcomes sections MUST be kept up to date as work proceeds. This plan must be fully self-contained — a novice with only this file should be able to implement the feature end-to-end.
## Purpose / Big Picture
Explain in a few sentences what someone gains after this change and how they can see it working. State the user-visible behavior you will enable.
## Architectural decisions
Durable decisions that apply across all phases:
- **Routes**: ...
- **Schema**: ...
- **Key models**: ...
- **Interfaces & Dependencies**: Name libraries, modules, types, traits/interfaces, function signatures that must exist. Be prescriptive.
- (add/remove sections as appropriate)
## Context and Orientation
Describe the current state relevant to this task as if the reader knows nothing. Name key files and modules by full path. Define any non-obvious terms.
---
## Phase 1:
**User stories**: <list from PRD>
### What to build
A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
### Validation and Acceptance
Phrase acceptance as **observable behavior** a human can verify — exact commands to run, expected output, what to observe. Not just "code compiles" but "running `X` produces `Y`". If tests are involved: "run `<test command>` — the new test `<name>` fails before the change and passes after."
### Idempotence and Recovery
Can these steps be run multiple times safely? If a step is risky, provide retry/rollback path.
---
## Phase 2: <Title>
**User stories**: <list from PRD>
### What to build
...
### Validation and Acceptance
...
<!-- Repeat for each phase -->
---
## Progress
Use checkboxes with timestamps. Every stopping point must be documented, even if it requires splitting partial work into "done" vs "remaining."
- [ ] Phase 1: ...
- [ ] Phase 2: ...
## Surprises & Discoveries
Document unexpected behaviors, bugs, performance tradeoffs, or insights discovered during implementation. Include concise evidence (test output is ideal).
- (none yet)
## Decision Log
Record every decision made while working on the plan:
- (none yet)
## Outcomes & Retrospective
Summarize outcomes, gaps, and lessons learned at major milestones or at completion. Compare result against original purpose.
- (to be filled at completion)
</plan-template>