---
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
```