compose:subagent

Read the plan once, extract all tasks with full text, create a tracked task per plan task, then dispatch a fresh implementer subagent per task bound to its task ID. After each implementation, run spec compliance review first, then code quality review, before marking the task done.

Subagent-driven development stays in the same session with no context switch, using a fresh subagent per task and automatic review checkpoints. Parallel session execution hands the plan to a separate session, which suits work that should not share the current conversation.

The spec reviewer runs in two phases: phase 1 receives only the covered spec sections and the git diff, returning a per-claim verdict; phase 2 runs only if phase 1 flagged items, letting the implementer's report explain flagged diffs. The task passes only when every in-scope claim passes with verifiable evidence.

Use cheap models for mechanical single-file tasks, standard models for multi-file integration, and the most capable model for architecture and review. The spec reviewer must be at least as capable as the implementer to avoid rubber-stamping shared misreadings.

Assess the blocker: provide more context and re-dispatch if it is a context problem, use a more capable model if reasoning is the issue, split the task if it is too large, or escalate to the human if the plan itself is wrong. Never force the same model to retry unchanged.

Avoid it when there is no implementation plan yet, when tasks are tightly coupled and cannot run independently, or when work belongs in a separate parallel session. In those cases brainstorm first or use the parallel execution workflow instead.