5.3 KiB
| name | description |
|---|---|
| prd-to-plan | 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
- Confirm PRD content is complete and in context
- Explore existing codebase to understand architecture and patterns
- Identify persistent architectural decisions across phases
- Decompose PRD into vertical slices (tracer bullets)
- Confirm slice granularity with user
- 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
# 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:
- Identify frontend and backend tasks
- Assign to corresponding agents
- 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