The subagent-driven-development Skill — Fresh Context Per Task

When an agent runs a long implementation plan in a single session, context accumulates. Earlier task details mix with later ones, and the agent's decisions in task five are influenced by noise from tasks one through four. The subagent-driven-development skill addresses this by dispatching a fresh, isolated agent for each task and passing it exactly the context it needs — nothing more.

The skill applies when there is an existing implementation plan, the tasks in that plan are mostly independent of each other, and the runtime supports isolated agent dispatch. When those conditions hold, it outperforms inline single-session execution on both quality and speed — quality because each agent starts clean, speed because the controller does not stop between tasks to report progress.

The per-task loop

Before dispatching anything, the controller reads the full plan file once, extracts all tasks with their complete text and surrounding context, and builds a working tracker. This upfront extraction is intentional: implementer agents must never re-read the plan file themselves, because providing full text directly is faster and avoids context pollution.

Each task follows the same loop. An implementer agent is dispatched with the task text, scene-setting context, and a prompt template from ./implementer-prompt.md. If the implementer asks questions before starting — which is correct behaviour — the controller answers them before allowing work to proceed. The implementer implements, tests, self-reviews, and commits. Then a spec-compliance reviewer is dispatched. Only after the reviewer confirms compliance does the code-quality reviewer run. Both reviews must pass before the task is marked complete. Reversing the order — running code quality before spec compliance — is explicitly a red flag in the skill.

Handling implementer status

Implementer agents return one of four statuses. DONE proceeds to review. DONE_WITH_CONCERNS also proceeds, but the controller reads the concerns first: correctness or scope concerns get addressed before review, while observations about file size or style are noted and passed through. NEEDS_CONTEXT means the controller provides the missing information and re-dispatches the same agent. BLOCKED requires the controller to assess the blocker — if it is a context problem, provide more context; if it is a reasoning problem, re-dispatch with a stronger model; if the task is too large, break it down; if the plan itself is wrong, escalate to the human.

The skill explicitly forbids ignoring an escalation or retrying the same model without changes. An implementer that reported it was stuck is telling the truth.

Model selection

The skill specifies model selection by role and task complexity rather than defaulting to the strongest model everywhere. Mechanical implementation tasks — isolated functions with a complete spec touching one or two files — use the cheapest model. Integration tasks that coordinate multiple files use a standard model. Architecture, design, and review tasks use the most capable available model. This keeps the cost of a full plan execution proportional to what each task actually requires.

End of the plan

After all tasks are marked complete, a final code reviewer agent runs across the entire implementation branch. This final pass catches cross-task issues that the per-task reviewers could not see in isolation — shared interface drift, inconsistency in error handling patterns, or scope that crept across multiple tasks without exceeding any single task's threshold. The branch then moves to the finishing-a-development-branch skill.

The skill is one of four required workflow skills. It depends on using-git-worktrees for an isolated workspace, writing-plans for the plan it executes, and requesting-code-review for the reviewer prompt templates. When the runtime cannot spawn isolated agents, the fallback is the executing-plans skill, which runs inline in a single thread.

Read what Datarim is for the overall pipeline context, or see the stage-snapshot-writer skill for how checkpoints persist between the pipeline stages this skill feeds into.