/devflow-execute

/devflow-execute

Implementation phase. Assumes a plan already exists (file path or inline checklist).

Plan / task: $ARGUMENTS

Flow

1. Locate plan (inline):

   • $ARGUMENTS is a file path → read it.
   • $ARGUMENTS is an inline task list → use it directly.
   • Else if docs/devflow/plans/ has exactly one file → use it.
   • Else list candidate plan files (with dates) and ask the user which one. Do not guess.

   Resume support: if the plan file has checked boxes, resume at the first unchecked task. Say which tasks are already done.

2. Dependency scan (inline): Scan the plan for external modules, sibling repos, or libraries whose source isn't in the working directory (imports outside src/, external models/mappers, column names or enums from external jars). If found, ask at the session gate for local paths or git URLs — or the specific types/fields needed. Save confirmed paths as a reference memory (external-source-paths); check existing memory first.

3. Session gate (inline — one message, one approval): Post a single summary: plan source, session scope (which tasks run now, which are deferred and why), run order, per-task verification, external dependencies resolved/pending, anything explicitly NOT touched, open risks, and the test mode.

   Test mode defaults to Targeted — state it, don't ask: "Test mode: Targeted. Say 'manual' or 'autonomous' to override." Mode semantics live ONLY in devflow-executing-tasks §Test-mode rules — don't restate them here.

   Then: "Approve this session plan, or want changes?" Wait for clear approval. Exception: if the user's original request already explicitly approved execution (e.g. "execute the plan, no questions") and the scope is ≤3 tasks with no unresolved dependencies, post the summary and proceed without re-asking. Approval covers the whole session scope — no re-gating between tasks.

4. Dispatch implementation (subagent per task batch):

   Batch up to 3–4 related tasks per dispatch — group by same file, same feature area, or sequential dependency. Each batch: print ▸ devflow-implementer · fable @ medium, then Agent(subagent_type="devflow-implementer") — model (Fable) and effort come from the agent frontmatter; never pass model=.

   Prompt must include:

   • Plan path + specific task IDs (the implementer reads the plan and ticks checkboxes as tasks complete)
   • The context packet from planning, if available — key files + line ranges, conventions, verification commands — so the implementer doesn't re-discover the repo
   • "Load devflow-executing-tasks" (canonical hard rules, test-mode rules, context hygiene)
   • Test mode for this session
   • External source paths from step 2 (if any)
   • The safety line: "Safety: never run git push, destructive SQL, or write secret-looking files unless the user explicitly asked. devflow hooks may additionally deny these — report a denial as a blocker, never work around it."
   • "Return: task IDs completed, files changed (paths), 1-line verification per run, blockers."

   Blockers → present to user inline → get direction → re-dispatch. Implementer caps at 2 fix attempts per error (3rd failure = blocker; rule lives in devflow-executing-tasks).

5. Self-review + verification (merged): print ▸ devflow-reviewer · fable @ medium, then Agent(subagent_type="devflow-reviewer") Prompt: "Load devflow-code-review. Review this session's changes (git diff to find files; read changed hunks only; don't re-read files already summarized). If test mode is Autonomous or Targeted: load devflow-verification and run the suite per the test-mode rules in devflow-executing-tasks. Return: findings + recommendation, verification output."

   Manual mode → skip verification in the subagent; list commands in the delivery summary.

6. Delivery summary (inline, <30 lines): files changed (paths only), review findings summary, verification output OR manual commands, anything skipped, what's left in the plan for a future session.

Do not claim completion without fresh verification output (autonomous/targeted) or explicit user confirmation (manual).