subagent-driven-development

<execution_workflow> Execute tasks sequentially. DO NOT start implementation on main/master branch without explicit user consent. Use using-git-worktrees first.

1. REVIEW MODE OPT-IN (ask ONCE, before dispatching the first task — STOP and wait for the answer):
   • PHASE RULE SYNC (silent, before asking): This skill activates the implementation phase. Per .sumela/RULE_REGISTRY.md <phase_to_rule_matrix>, confirm every universal rule, every implementation-phase rule, and every rule matching the active stack scope(s) and domain(s) is loaded — READ any missing rule file now; if the registry file is missing, tell the user to run setup — do not guess the matrix. Also confirm secure-coding-standard is in context.
   • Present exactly this choice: "How do you want reviews and task gates during execution?
     1. Checkpoint mode (recommended): After EVERY task — Stage-1 spec review + Stage-2 quality/security review, then I stop for your approval before the next task. Maximum control, more interruptions.
     2. Flow mode: Tasks run back-to-back with no per-task reviewer dispatch and no per-task stop. ONE comprehensive review (requesting-code-review) covers all accumulated changes at the end — that final review is mandatory and cannot be skipped. Best for small/mechanical tasks when you'd rather review once."
   • Record the choice for the whole run. The user may switch modes at any task boundary by saying so. NEVER assume Flow mode silently — it requires this explicit opt-in; if the user gives no clear answer, default to Checkpoint mode.

For EVERY task in the plan, follow this strict loop:

1. PREPARE: Read the plan, extract the full text and context for the current task. Note the TDD Mode (Enabled/Skipped) and Security Constraints from the plan header. Do NOT make the subagent read the plan file itself.

2. IMPLEMENTATION (STRICTLY NO COMMITS): Dispatch the Implementer subagent (./implementer-prompt.md). Match model to task complexity: mechanical implementation → fastest model; integration work → standard model; architecture or security boundaries → most capable model.

   • Provide the full task text.
   • Instruct it to follow the plan's TDD Mode (strict Red-Green-Refactor if Enabled; standard implementation if Skipped, but enforcing the automated test rule for Auth/Security boundaries).
   • EXPLICITLY command it to comply with the secure-coding-standard constraints.
   • Instruct it to ONLY stage its changes using git add. It MUST NOT use git commit.
   • If Implementer returns NEEDS_CONTEXT: Provide the missing context and re-dispatch with the same model.
   • If Implementer returns BLOCKED: Assess and act per this matrix — do NOT force the same model to retry without changes:
     • (a) Context problem (subagent missing info): provide more context, re-dispatch with same model.
     • (b) Needs more reasoning (model under-powered for the judgment required): re-dispatch with a more capable model.
     • (c) Task too large (subagent cannot hold the scope): break the task into smaller pieces, re-dispatch each.
     • (d) Plan itself wrong (architectural decision unguided, spec contradicts itself): escalate to the human; do NOT proceed.
   • If Implementer asks questions: Answer them fully before allowing implementation.
   • If Implementer returns DONE or DONE_WITH_CONCERNS: Proceed to Step 3 (Checkpoint mode) or to the FLOW MODE SHORT-CIRCUIT below (Flow mode).

FLOW MODE SHORT-CIRCUIT: If the user chose Flow mode in Step 0, skip Steps 3-4 — mark the task complete in Todo/Checklist, give a one-line progress note (task name + files touched, no stop), and proceed directly to the next task's Step 1; if no task remains, proceed to Step 5. The code stays STAGED; all review weight shifts to the MANDATORY Step 5. Plan ## Checkpoint: blocks: run their verifications, but do not stop unless a verification fails. EXCEPTION: if the Implementer returns DONE_WITH_CONCERNS or the task touches an auth/security boundary, run Stage-1 + Stage-2 AND stop at the per-task approval gate for THAT task even in Flow mode. (NEEDS_CONTEXT/BLOCKED handling in Step 2 is identical in both modes.)