203 lines
5.3 KiB
Markdown
203 lines
5.3 KiB
Markdown
---
|
|
name: prd-to-plan
|
|
description: "Converts PRD into a multi-phase implementation plan using vertical slices (tracer bullets). Orchestrator uses this skill at Stage 8 to produce implementation plans for Stage 9 Backend/Frontend Agent implementation. Trigger: After Design Review passes, when Orchestrator performs Task Breakdown."
|
|
---
|
|
|
|
# /prd-to-plan — PRD to Implementation Plan
|
|
|
|
Orchestrator uses this skill to convert PRD into vertical slice implementation plans.
|
|
|
|
## Responsibilities
|
|
|
|
1. Confirm PRD content is complete and in context
|
|
2. Explore existing codebase to understand architecture and patterns
|
|
3. Identify persistent architectural decisions across phases
|
|
4. Decompose PRD into vertical slices (tracer bullets)
|
|
5. Confirm slice granularity with user
|
|
6. Produce implementation plan document
|
|
|
|
## Input
|
|
|
|
- PRD document (`docs/prd/{date}-{feature}.md`)
|
|
- API specification (`docs/api/{date}-{feature}.yaml`)
|
|
- DB Schema (`docs/db/{date}-{feature}.sql`)
|
|
- Design documents (`docs/design/{date}-{feature}/`)
|
|
|
|
## Output
|
|
|
|
- Implementation plan: `./plans/{feature}.md`
|
|
|
|
## Process
|
|
|
|
```
|
|
Confirm PRD in context
|
|
↓
|
|
Explore codebase (architecture, patterns, integration layers)
|
|
↓
|
|
Identify persistent architectural decisions (routes, schema, models, auth)
|
|
↓
|
|
Draft vertical slice decomposition
|
|
↓
|
|
Confirm slice granularity with user
|
|
↓
|
|
Iterate until user approves
|
|
↓
|
|
Write plan file
|
|
```
|
|
|
|
### Step Details
|
|
|
|
**1. Confirm PRD in context**
|
|
|
|
The PRD should already be in the conversation. If not, ask the user to paste or point to the file.
|
|
|
|
**2. Explore codebase**
|
|
|
|
If the codebase hasn't been explored yet, explore to understand:
|
|
- Current architectural patterns
|
|
- Existing code conventions
|
|
- Integration layers (DB, API, external services)
|
|
- Existing test patterns
|
|
|
|
**3. Identify persistent architectural decisions**
|
|
|
|
Before slicing, identify high-level decisions unlikely to change during implementation:
|
|
|
|
- Route structure / URL patterns
|
|
- Database schema shape
|
|
- Key data models
|
|
- Authentication / authorization approach
|
|
- Third-party service boundaries
|
|
|
|
Write these decisions in the plan file header for all phases to reference.
|
|
|
|
**4. Draft vertical slices**
|
|
|
|
Decompose PRD into **tracer bullet** phases. Each phase is a thin vertical slice cutting through all integration layers end-to-end, **not** horizontal slicing.
|
|
|
|
**Vertical slice principles:**
|
|
|
|
- Each slice delivers a narrow but complete path through all layers (schema, API, usecase, logic, tests)
|
|
- Completed slices can be demonstrated or verified independently
|
|
- Prefer multiple thin slices over few thick slices
|
|
- Don't include specific filenames, function names, or implementation details that may change with subsequent phases
|
|
- Include persistent decisions: route paths, schema shapes, data model names
|
|
|
|
**Horizontal slice (wrong) vs Vertical slice (correct):**
|
|
|
|
```
|
|
❌ Horizontal slice:
|
|
Phase 1: All domain entities
|
|
Phase 2: All usecases
|
|
Phase 3: All API handlers
|
|
Phase 4: All repository implementations
|
|
|
|
✅ Vertical slice (tracer bullets):
|
|
Phase 1: User registration (entity + usecase + handler + repo + tests)
|
|
Phase 2: User login (same)
|
|
Phase 3: User list (same)
|
|
Phase 4: User profile update (same)
|
|
```
|
|
|
|
**5. Confirm with user**
|
|
|
|
Present decomposition as a numbered list, each phase containing:
|
|
|
|
- **Title**: Brief descriptive name
|
|
- **User stories covered**: Which user stories from PRD this maps to
|
|
|
|
Ask the user:
|
|
- How does the granularity feel? (too coarse / too fine)
|
|
- Need to merge or split any phases?
|
|
|
|
Iterate until user approves.
|
|
|
|
**6. Write plan file**
|
|
|
|
Create `./plans/` directory (if it doesn't exist). Write Markdown file.
|
|
|
|
## Plan Template
|
|
|
|
```markdown
|
|
# Plan: {Feature Name}
|
|
|
|
> Source PRD: {PRD link or identifier}
|
|
> Source API: {API specification link}
|
|
> Source DB Schema: {DB Schema link}
|
|
|
|
## Architectural Decisions
|
|
|
|
Persistent decisions across all phases:
|
|
|
|
- **Routes**: {API route structure}
|
|
- **Schema**: {database schema shape}
|
|
- **Key models**: {key data models}
|
|
- **Auth**: {authentication/authorization approach}
|
|
- **Third-party services**: {external service boundaries}
|
|
|
|
---
|
|
|
|
## Phase 1: {Title}
|
|
|
|
**User stories**: {list of user stories from PRD}
|
|
|
|
### What to build
|
|
|
|
End-to-end behavior description for this vertical slice. Describe complete behavior, not layer-by-layer implementation details.
|
|
|
|
### Acceptance criteria
|
|
|
|
- [ ] Acceptance criteria 1
|
|
- [ ] Acceptance criteria 2
|
|
- [ ] Acceptance criteria 3
|
|
|
|
---
|
|
|
|
## Phase 2: {Title}
|
|
|
|
**User stories**: {list of user stories from PRD}
|
|
|
|
### What to build
|
|
|
|
...
|
|
|
|
### Acceptance criteria
|
|
|
|
- [ ] ...
|
|
|
|
---
|
|
|
|
<!-- Repeat for each Phase -->
|
|
```
|
|
|
|
## Role in Vibe-Kanban
|
|
|
|
```
|
|
Stage 7: Design Review passes
|
|
↓
|
|
Stage 8: Task Breakdown (Orchestrator uses prd-to-plan)
|
|
↓
|
|
Output ./plans/{feature}.md
|
|
↓
|
|
Stage 9: Implementation (Backend/Frontend Agent implements according to plan)
|
|
```
|
|
|
|
Orchestrator will parse the plan and:
|
|
1. Identify frontend and backend tasks
|
|
2. Assign to corresponding agents
|
|
3. May trigger parallel task distribution
|
|
|
|
## Dependent Skills
|
|
|
|
- **Prerequisite**: `write-a-prd` (PRD complete), `be-api-design` (API spec), `dba-schema` (DB Schema), `design-review` (design review passed)
|
|
- **Follow-up**: `go-backend-dev` (Backend implementation), frontend implementation skill
|
|
|
|
## Rollback Mechanism
|
|
|
|
```
|
|
Implementation plan infeasible
|
|
↓
|
|
Rollback to Stage 7 (Design Review) for re-review
|
|
or
|
|
Rollback to Stage 4 (API Design) to adjust design
|
|
``` |