opencode-workflow/skills/generate-plan/SKILL.md

---
name: generate-plan
description: "Generate the implementation plan from architecture and code design. Produces the single strict output file with task breakdown, dependency graph, execution order, milestones, deliverables, and traceability."
---

This skill produces the complete planning document for a feature.

**Announce at start:** "I'm using the generate-plan skill to produce the implementation plan."

## Primary Input

- `docs/architecture/{feature}.md`
- `docs/code-design/{feature}.md`

## Primary Output (STRICT PATH)

- `docs/plan/{feature}.md`

This is the only file artifact produced by the planning pipeline.

## Hard Gate

Do NOT start this skill if the architecture or code design documents contain unresolved ambiguities that block task sequencing.

## Process

You MUST complete these steps in order:

1. Read the architecture document end-to-end
2. Read the code design document end-to-end
3. Apply internal analysis from `analyze-design-inputs`
4. Determine the smallest meaningful execution units without drifting into implementation detail
5. Group related work into milestones
6. Define all task dependencies
7. Define which tasks can run in parallel
8. Define concrete deliverables and completion criteria for every task
9. Build a design traceability matrix from upstream design artifacts to tasks
10. Write the plan document to `docs/plan/{feature}.md`

## Planning Rules

1. Tasks must be implementation-ready, not vague
2. Tasks must be grounded in upstream design documents
3. Do not collapse unrelated work into one oversized task
4. Do not split work so finely that the plan becomes mechanical noise
5. Include migration, rollout, config, and operational tasks when the upstream design requires them
6. Keep QA responsibilities out of the plan, but provide enough completion criteria for QA to build tests later

## Plan Document Template

```markdown
# Plan: {Feature Name}

## Overview

Summary of the implementation objective and the scope of planned work.

## Inputs

- Architecture: `docs/architecture/{date}-{feature}.md`
- Code Design: `docs/code-design/{date}-{feature}.md`

## Planning Assumptions

- Assumption 1
- Assumption 2

## Task Breakdown

### Task P1: {Task Name}
- Objective: ...
- Inputs Used: ...
- Design References: ...
- Dependencies: None / P0 / ...
- Deliverables: ...
- Completion Criteria: ...
- Suggested Owner Type: ...

## Dependency Graph

```mermaid
graph TD
  P1 --> P2
  P1 --> P3
```

## Execution Order

1. Phase 1: ...
2. Phase 2: ...

## Milestones

### Milestone M1: {Name}
- Included Tasks: P1, P2
- Exit Criteria: ...
- Rationale: ...

## Deliverables

| Task | Deliverable | Source Design Reference |
|------|-------------|-------------------------|
| P1 | ... | ... |

## Design Traceability

| Upstream Design Element | Planned Task(s) |
|-------------------------|-----------------|
| Architecture: ... | P1, P2 |
| Code Design: ... | P3 |

## Risks And Sequencing Notes

- Risk 1: ...
- Risk 2: ...

## Planning Review

(Populated by challenge-plan)

## Open Questions

1. ...
2. ...
```

## Guardrails

Do:
- Use both architecture and code design as authoritative inputs
- Keep tasks concrete and traceable
- Include dependencies and completion criteria for every task

Do not:
- Change design decisions
- Add QA test cases
- Add implementation code
- Produce any file artifact other than `docs/plan/{feature}.md`

## Transition

After generating the plan, invoke `challenge-plan` to audit and refine it.