task-plan

name	task-plan
description	Decompose a PRD into a sequenced checkbox task list. Each task is small enough to complete in one focused pass and tied to one or more PRD success criteria. Use after the PRD is accepted and before implementation begins. Triggers — "plan from the PRD", "break this into tasks", "task list for [feature]", "decompose [PRD]", "give me a plan".

Task Plan

Turn an accepted PRD into a flat, sequenced task list with checkboxes. The plan is the contract between the PRD and the implementation. Tasks too big = invisible progress; tasks too small = ceremonial overhead. Aim for one-focused-pass per task.

When to use

• Right after a PRD is written and accepted
• When picking up an existing PRD that lacks a plan
• When re-planning after a Stage 6 evaluation surfaces structural issues

Input

• prd_path — path to the PRD (e.g., docs/PRDs/oauth-token-refresh.md)

Output

docs/PRDs/<feature_slug>-plan.md, copied from templates/plan-template.md and filled in. Sections:

1. Tasks — checkbox list with Touches, Verifies, Check, Notes per task
2. Parallelizable groups — which tasks can run concurrently
3. Risks per task

Sizing rules

Each task should pass these checks:

1. One-pass completable — ≤ 2 hours of focused work
2. Single responsibility — advances one concern; does not bundle unrelated changes
3. Independent where possible — runs in parallel with siblings when safe
4. Tied to a criterion — advances at least one PRD success criterion
5. Testable in isolation — there is a check (unit test, integration test, smoke) that confirms this task alone is done

If a task fails any of these, split it.

Parallelizable-group analysis

After the flat task list is drafted, invoke task-distributor to produce the parallelizable-group section. It applies the safety rules:

• No shared write target between parallel tasks
• No read-after-write dependencies between parallel tasks
• No contended shared resources (DB row, rate limit, file lock)

Take the task-distributor output verbatim into the plan's "Parallelizable groups" section. The ralph-implement skill at Stage 4 reads this section to spawn parallel work.

Common decomposition patterns

PRD shape	Plan shape
New feature	Schema → API → client → tests → docs
Refactor	Add new path → migrate callers in batches → remove old path
Integration	Contract / types → happy path → error paths → retries → observability
Bug fix	Reproduce → narrow → fix → regression test
Migration	Backup → write new state alongside old → verify equivalence → switch reads → drop old

Starting points, not formulas. The plan must match the actual work.

Stage-pipeline plans

When the work is a fixed sequence of steps with a human review gate between each (research → draft → final; data → eval → report), the plan scaffolds the execution structure instead of only listing tasks:

• Copy templates/stage-pipeline/ from the master tooling repo to where the work lives; rename/renumber stages (01-, 02- — zero-padded prefixes encode execution order; reordering = renaming folders).
• Each stage folder carries a CONTEXT.md contract — Inputs (source / where / why), Process (numbered steps), Outputs (artifact / location / format) — under 80 lines, plus an output/ folder for the handoff artifact.
• A stage reads ONLY its declared Inputs (previous stage's output/ + named references). Everything else is do-not-load.
• Tasks then map 1:1 to stages; each stage's DONE check = its Outputs exist and satisfy the contract. The human inspects output/ before the next stage runs — every output is an edit surface.

Pre-flight checklist

Before writing the plan:

1. Have I read the full PRD, not just the title?
2. Does every PRD success criterion appear as at least one task's Verifies: field?
3. Is every task one-pass completable?
4. Has task-distributor run on the flat task list to produce parallelizable groups?
5. Have I flagged task-level risks separately from PRD-level risks?
6. If a task is large, have I split it before adding to the plan?

Anti-patterns

• One-line tasks ("write tests") that hide a day of work — split
• Mega-tasks ("implement auth") that span the whole feature — split
• Tasks that do not tie to any PRD criterion — either find the criterion or remove the task
• Hand-rolled parallel grouping — let task-distributor do it; the safety rules are easy to skip when humans estimate
• Plans that re-state the PRD — the plan is a decomposition, not a restatement