mirror of
https://github.com/mattpocock/skills.git
synced 2026-04-30 14:03:53 +07:00
Remove prd-to-plan skill
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -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.
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -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>
|
|
||||||
Reference in New Issue
Block a user