/tasktree

argument-hint: [prd-path]

Convert a PRD, spec, or requirements doc into structured task tree with dependencies and priorities.

Tasktree: PRD to Tasks + Dependencies

**Use this command when:**

• You have a PRD or feature spec to convert into tasks
• Need to break down requirements into actionable work items
• Want to create a batch of related tasks with proper dependencies
• Converting high-level requirements into agent-ready tasks

**What this does:**

• Reads and parses the PRD/spec (file, conversation, or inline)
• Asks clarifying questions if requirements are ambiguous
• Creates an **epic** for multi-task features with **hierarchical child IDs** (e.g., `jat-auth.1`, `jat-auth.2`)
• Creates right-sized tasks (2-8 hour tasks)
• Sets up dependency chains between tasks
• Assigns priorities (P0-P2) based on criticality
• Assigns a model tier per task (`max` research/architecture, `medium` well-specified coding) — must happen at create time
• Reports summary of created tasks

**Usage:**

• `/jat:tasktree` - Parse from conversation context or prompt for input
• `/jat:tasktree path/to/prd.md` - Convert specific PRD file
• `/jat:tasktree "inline: user auth with Google OAuth and email/password"` - Inline spec

---

STEP 1: Get the Input

**If `$1` is a file path:**

• Read the PRD/spec file
• Parse requirements, features, constraints

**If `$1` starts with "inline:":**

• Use the inline text as the spec

**If `$1` is empty:**

• Check conversation for recent feature/requirements discussion
• Look for: "we need to...", "build...", "implement...", requirements lists
• If found: use that as input
• If not found: ask user to provide PRD or paste requirements

---

STEP 2: Parse Requirements

Extract from the input:

1. **Features/Capabilities** - What needs to be built? 2. **Requirements** - Specific constraints or needs? 3. **Technical context** - Stack, integrations, APIs? 4. **Priority signals** - What's critical vs nice-to-have? 5. **Scope boundaries** - What's in vs out?

---

STEP 3: Clarify Ambiguities (if needed)

If the spec is unclear or missing key info, use `AskUserQuestion` (max 4 questions):

• **Scope:** "What's MVP vs future?"
• **Priority:** "What's most critical?"
• **Technical:** "Any tech constraints?"
• **Dependencies:** "External blockers?"

Skip this step if the PRD is already clear and complete.

---

STEP 4: Structure the Tasks

Task Sizing (2-8 hours each)

**Good size:**

• "Implement Google OAuth login flow"
• "Create user profile database schema"
• "Build settings page UI"

**Too big (break down):**

• "Build authentication system" → multiple tasks
• "Implement user management" → multiple tasks

**Too small (combine):**

• "Add button" → part of larger UI task
• "Update import" → part of larger change

Breakdown Strategies

Choose based on the spec:

• **By feature:** Auth, Profiles, Settings
• **By layer:** DB schema, API, UI
• **By user flow:** Signup, Login, Reset password
• **By dependency:** Foundation → Building blocks → Features

Priority Levels

• **P0 (Critical):** Foundation, blocks everything else
• **P1 (High):** Core features, MVP requirements
• **P2 (Medium):** Enhancements, nice-to-have

Identify Dependencies

• What must happen before what?
• What can run in parallel?
• What's on the critical path?

Model Tier (assign one per task — MANDATORY)

⚠️ **Set the tier at CREATE time via `--model`.** Decide it here in Step 4, alongside priority — every task gets one. A tree without tiers makes every spawn fall through to the spawner default: wasteful on simple tasks, underpowered on hard ones. (`jt update --model` also works on postgres projects since jat-uiyr6, so a missed tier is retrofittable — but deciding at create time is still the rule.)

Tiers are **harness-agnostic capability levels** (`low` | `medium` | `high` | `max`), never vendor model names. The spawner resolves (agent program, tier) → concrete model via the Model Routing ladder (/config → Harnesses): under claude-code the defaults are low=haiku, medium=sonnet, high=opus, max=fable; other harnesses ladder to their own models.

| Tier | Use for | |------|---------| | `max` | Research/deep-dive investigations, novel architecture & cross-cutting design that other tasks build on, anything security-adjacent (permissions, auth, RLS), epic verification (the epic itself) | | `high` | Complex-but-scoped coding: state machines, render/engine pipelines, subtle-semantics work (timezones/DST, concurrency, retry logic), registry/API design within one task's boundary | | `medium` | Well-specified coding: vendoring a known lib, building UI over a settled schema, wiring adapters, migrations from a spec, tests for described behavior | | `low` | Trivial mechanical chores: renames, config bumps, copy edits, single-file find-and-replace sweeps |

Heuristics:

• If the task's description contains open design questions ("decide", "resolve the boundary", "recommend one") → `max`.
• If the design is settled but the implementation has sharp edges (a wrong subtle choice fails quietly) → `high`.
• If a competent implementer could finish it without making any non-obvious choice → `medium`.
• Epics are always `max` — they become the integration/verification task when children complete.
• When unsure, the deciding question is blast radius: wrong choice ripples into other tasks → `max`; wrong choice breaks only this task → `high` or below.

---

STEP 5: Create Tasks

For Multi-Task Features: Create Epic + Children

**⚠️ CRITICAL: Always use `--parent` flag when creating child tasks!**

When breaking down a feature into multiple related tasks, create a parent epic first, then add child tasks with hierarchical IDs:

❌ WRONG - Creates standalone tasks with random IDs:
   jt create "Epic: Auth" --type epic           → jat-kvtrr
   jt create "Setup config" --type task         → jat-j2pwt  (NOT a child!)
   jt create "Add login" --type task            → jat-sud88  (NOT a child!)
   jt dep