Automatically analyze project plans and generate comprehensive task breakdowns. Use when user describes a project, feature set, or asks to build/implement something complex requiring multiple tasks.
Transform high-level project plans into actionable, well-organized task breakdowns. Persist the breakdown as durable, git-trackable documentation under .claude/plans/ and .claude/tasks/ so it survives across sessions and stays alongside the code.
All output is written to the local .claude/ directory of the current repo (no external task system). The layout mirrors conventions already used elsewhere in the system:
| Path | Purpose | Format |
|---|---|---|
.claude/plans/{slug}.md |
Human-readable project plan: epic, phases, full task list | Markdown |
.claude/tasks/{slug}/{N}.json |
One file per task — granular, machine-readable | JSON |
.claude/tasks/{slug}/index.json |
Task ordering, dependencies, status roll-up | JSON |
Slug rule: kebab-case derived from the project title (e.g. "Auth Refresh Tokens" → auth-refresh-tokens). If a slug collides, append -2, -3, etc.
If .claude/plans/ or .claude/tasks/ does not exist, create it with mkdir -p before writing.
Activates when the user:
Extract from the user's description:
Pick the work areas the project actually needs — do not pad:
For each task, capture:
Context integration:
.claude/memory/active/quick-reference.md and procedural-memory.md if present — reuse proven patternsCLAUDE.md for project-specific guard railsBefore writing files, verify:
Step 1 — derive the slug from the project title and confirm .claude/plans/{slug}.md does not already exist (suffix -2 etc. if it does).
Step 2 — ensure directories exist:
mkdir -p .claude/plans .claude/tasks/{slug}
Step 3 — write the plan markdown to .claude/plans/{slug}.md using the template below.
Step 4 — write per-task JSON to .claude/tasks/{slug}/{N}.json (one file per task, N = 1, 2, 3, ...).
Step 5 — write the index to .claude/tasks/{slug}/index.json summarizing IDs, statuses, and the dependency graph.
Step 6 — call TodoWrite with the Phase-1 critical tasks so the current session can start working immediately.
Print a short summary back to the user:
Write this to .claude/plans/{slug}.md:
---
name: {Project Title}
slug: {slug}
created: {YYYY-MM-DD}
complexity: {Low|Medium|High}
estimated_duration_days: {N}
total_tasks: {N}
areas: [backend, frontend, ...]
status: planned
---
# {Project Title}
## Context
{1–2 sentences on what is being built and why. Include the user's original ask.}
## Analysis
- **Complexity:** {Low|Medium|High}
- **Areas involved:** {comma-separated list}
- **Estimated duration:** {N} days
- **Critical path:** {phase → phase → phase summary}
## Existing code to reuse
- `{path/to/file.ts:LINE}` — {function name} — {why it matters}
- ...
## Phases
### Phase 1 — {Phase Name}
| ID | Task | Area | Priority | Size | Depends on |
|----|------|------|----------|------|------------|
| 1 | {title} | backend | Critical | M | — |
| 2 | {title} | testing | High | S | 1 |
### Phase 2 — {Phase Name}
...
## Tasks
Per-task detail lives in `.claude/tasks/{slug}/{N}.json`. Index: `.claude/tasks/{slug}/index.json`.
## Verification
- [ ] All tasks in `.claude/tasks/{slug}/` reference back to this plan
- [ ] Phase 1 critical tasks are in the active TodoWrite list
- [ ] Acceptance criteria are testable
Each .claude/tasks/{slug}/{N}.json file:
{
"id": "1",
"slug": "{slug}",
"title": "{Brief title}",
"description": "{Detailed context and acceptance criteria}",
"activeForm": "{Gerund form for status display, e.g. 'Adding refresh-token endpoint'}",
"priority": "Critical|High|Medium|Low",
"size": "XS|S|M|L|XL",
"phase": 1,
"area": "backend",
"estimated_hours": 4,
"risk": "low|medium|high",
"dependencies": [],
"acceptance_criteria": [
"Criterion 1",
"Criterion 2"
],
"status": "pending|in_progress|completed",
"blocks": [],
"blockedBy": []
}
The id, subject/title, activeForm, status, blocks, blockedBy fields match the existing ~/.claude/tasks/ JSON convention so other tooling can consume them.
.claude/tasks/{slug}/index.json:
{
"slug": "{slug}",
"plan": ".claude/plans/{slug}.md",
"created": "{YYYY-MM-DD}",
"tasks": [
{ "id": "1", "title": "...", "phase": 1, "priority": "Critical", "status": "pending" }
],
"phases": {
"1": { "name": "Foundation", "task_ids": ["1", "2"] },
"2": { "name": "Polish", "task_ids": ["3", "4"] }
}
}
Always read .claude/memory/active/quick-reference.md and procedural-memory.md first if they exist. Reference matching patterns in the plan's "Existing code to reuse" section so future-you doesn't reinvent.
.claude/plans/)risk: high on anything new to the codebaseIf .claude/plans/{slug}.md already exists, do not silently overwrite. Either suffix the slug or ask the user whether to update in place.
After project building:
/orchestrate-tasks can pick up .claude/tasks/{slug}/ for parallel execution/sprint-plan can pull tasks from any active .claude/tasks/*/index.json/focus can load a single task by {slug}/{N} for deep workUpdating tasks during execution:
status from pending → in_progress → completedindex.json task entries to matchAsk one targeted clarifying question about scope, then proceed with explicit assumptions noted in the plan's Context section.
Default to Medium, mark uncertain tasks risk: high, and call out the assumption in the plan.
Suffix -2, -3, ... and tell the user which slug was used.
Surface the error to the user (likely a permissions or git-init issue) — do not fall back to inline-only output.
Version: 2.0.0
Category: Project Management & Planning
Storage: Local .claude/ directory (no external task system)