subagent-driven-development

Continuous execution

Do not pause to check in between tasks. When the orchestrator (this skill) receives a plan, it dispatches the first task's three subagents, waits for their verdicts, applies the resolution rule below, and immediately dispatches the next task. The user is not in the loop on a per-task basis — that is the loop SDD exists to remove.

Pause points the user does see:

• The plan itself, before any task is dispatched (user approves the task list).
• A NEEDS_CONTEXT from any implementer (orchestrator surfaces the question, waits for an answer).
• A BLOCKED from any implementer that the orchestrator cannot unblock by re-dispatch (e.g. missing dependency the user must install).
• The final summary after all tasks DONE (or DONE_WITH_CONCERNS triaged).

Everything else — RED-GREEN-REFACTOR cycles, reviewer rounds, re-dispatch on NEEDS_REVISION — runs without user intervention.

Subagent capacity errors (usage limit / "529 Overloaded"). If a subagent dispatch fails with a monthly-limit or 529 error mid-run: (1) do not silently retry in a loop; (2) finish and commit any tasks already DONE in the current wave; (3) surface ONE recovery question to the user with three options: wait for capacity to recover; proceed with explicit B2 orchestrator self-review (mark every verdict "[self-review — confirmation bias risk]"); or push the branch as-is and rely on CI. Phrase this per §Asking the user.

Asking the user

When you surface one of those pause points — the「下一步？」hand-off after a task DONE, a NEEDS_CONTEXT question, a BLOCKED, or the 4th-retry escalation — run the decision through three gates: ① whether to ask at all, ② what to bring when you do ask, and ③ how to phrase it. The reader is a warm-but-interrupted human, not the reviewer subagent. The anchor for all three gates is Horvitz, Principles of Mixed-Initiative User Interfaces (CHI 1999): scale the act-vs-ask threshold by the cost of being wrong, and scope each question's precision to your confidence.