Remove prd-to-plan skill

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Test
2026-04-17 13:02:21 +01:00
parent ab45d5e6e1
commit a77fa6e7a6
2 changed files with 0 additions and 113 deletions
-6
View File
@@ -12,12 +12,6 @@ These skills help you think through problems before writing code.
npx skills@latest add mattpocock/skills/write-a-prd 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. - **prd-to-issues** — Break a PRD into independently-grabbable GitHub issues using vertical slices.
``` ```
-107
View File
@@ -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.
<vertical-slice-rules>
- 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
</vertical-slice-rules>
### 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-template>
# Plan: <Feature Name>
> Source PRD: <brief identifier or link>
## Architectural decisions
Durable decisions that apply across all phases:
- **Routes**: ...
- **Schema**: ...
- **Key models**: ...
- (add/remove sections as appropriate)
---
## Phase 1: <Title>
**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>