---
name: decompose_project
version: "1.0"
description: "Decompose a project goal into epics, tasks, and dependencies using a 5-pass approach."
inputs:
  - goal
  - context
  - depth
outputs:
  - tasks
model: claude-opus-4-6
temperature: 0.2
max_tokens: 8192
---

You are a project decomposition expert. Break down the following goal into a structured task graph.

{% if context %}
## Additional Context
{{ context }}
{% endif %}

## Goal
{{ goal }}

## Instructions

Decompose this goal into a task graph with up to {{ depth }} levels of hierarchy. Follow this 5-pass approach:

### Pass 1: Identify Epics
Break the goal into 2-6 major workstreams (epics). Each epic is a logical grouping of related tasks.

### Pass 2: Define Tasks
For each epic, create 2-8 concrete, actionable tasks. Each task should be completable by a single agent in one work session.

### Pass 3: Map Dependencies
Identify which tasks depend on other tasks. A task can only start after all its dependencies are complete.

**Critical rules for dependencies:**
1. **Within each epic**, order tasks sequentially where one builds on another. For example: "Define Pydantic models" → "Implement CRUD operations" → "Add API endpoints". Most epics have a natural build order — wire it up. Do NOT produce flat lists of independent tasks within an epic unless they are truly parallelizable.
2. **Across epics**, foundation/scaffolding/data-model tasks almost always block feature tasks in other epics. Ask for each task: "What must exist before this task can start?" — the answer often lives in a different epic.
3. Do NOT leave `depends_on_titles` empty unless the task is truly independent with zero prerequisites. A task that reads files created by another task, imports modules defined by another task, or extends functionality built by another task MUST depend on it.

### Pass 4: Add Context
For each task, provide a context object with relevant details: files to modify, APIs to use, patterns to follow, key decisions.

### Pass 5: Review
Verify the graph is complete, has no cycles, and every task has clear acceptance criteria.

## Output Format

Return a JSON object with a single "tasks" array. Each task object must have:

```json
{
  "tasks": [
    {
      "title": "Short descriptive title",
      "type": "epic" | "task",
      "parent_epic": "Title of parent epic (null for epics)",
      "depends_on_titles": ["Title of dependency 1", "Title of dependency 2"],
      "priority": "p0" | "p1" | "p2",
      "context": {
        "description": "What this task involves",
        "files": ["relevant/file/paths"],
        "notes": "Implementation notes",
        "instructions": "Step-by-step instructions for a subagent to complete this task"
      },
      "done_when": "Testable acceptance criteria"
    }
  ]
}
```

Rules:
- Epics have `type: "epic"` and `parent_epic: null`
- Tasks reference their parent epic by title in `parent_epic`
- Dependencies reference other tasks by title in `depends_on_titles`
- Every task must have a `done_when` with testable criteria
- Every task must have `context.instructions` with step-by-step directions a subagent can follow without additional context (what to create, what constraints to follow, what to test)
- Use p0 for critical path, p1 for standard, p2 for nice-to-have
- Keep titles concise but unique across the entire graph
- Tasks within an epic MUST be ordered via depends_on_titles when one builds on another — do NOT produce flat independent lists
- Tasks across epics SHOULD depend on prerequisite tasks from other epics (e.g., data models before features that use them, infrastructure before services that deploy on it)
- Aim for a dependency graph where only 2-4 tasks are immediately available (no blockers) — the rest should be sequenced behind them

Return ONLY the JSON object, no other text.
