diff --git a/README.md b/README.md index 88bed7f..eb1fc4c 100644 --- a/README.md +++ b/README.md @@ -12,12 +12,6 @@ These skills help you think through problems before writing code. npx skills@latest add mattpocock/skills/write-a-prd ``` -- **prd-to-plan** — Turn a PRD into a multi-phase implementation plan using tracer-bullet vertical slices. - - ``` - npx skills@latest add mattpocock/skills/prd-to-plan - ``` - - **prd-to-issues** — Break a PRD into independently-grabbable GitHub issues using vertical slices. ``` diff --git a/prd-to-plan/SKILL.md b/prd-to-plan/SKILL.md deleted file mode 100644 index a5da1c2..0000000 --- a/prd-to-plan/SKILL.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -name: prd-to-plan -description: 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". ---- - -# 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. - - -- 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 - - -### 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: - -## Architectural decisions - -Durable decisions that apply across all phases: - -- **Routes**: ... -- **Schema**: ... -- **Key models**: ... -- (add/remove sections as appropriate) - ---- - -## 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. - -### Acceptance criteria - -- [ ] Criterion 1 -- [ ] Criterion 2 -- [ ] Criterion 3 - ---- - -## Phase 2: <Title> - -**User stories**: <list from PRD> - -### What to build - -... - -### Acceptance criteria - -- [ ] ... - -<!-- Repeat for each phase --> -</plan-template>