git:20260913.7de9794 to git:20261027.93e47a5

---

name: execute

description: Use in Build to run an approved plan. Direct work or up to 5 workers; orchestrator exclusively owns git, plan/roadmap files, status, gates. Workers write only assigned files. (Lineage: agent-skills/incremental-implementation, godmode/task-runner)

phase: Build

---

# Execute — approved plan, checked landing, orchestrator owns the books

## Prime directive

Workers write assigned files only. The orchestrator alone touches git, plans, statuses, and gates.

## Steps (in order)

1. **Direct execute** small/single-file tasks.

2. **Workers (max 5)** for independent mechanical/long items: briefs carry requirements, constraints, decision-log lines, acceptance criteria. Workers: assigned files only; no git; no plan edits; no gates; no sub-workers. Shared files serialize.

3. **Merge + review** each worker diff vs acceptance criteria, THEN commit (per `version`).

4. **Checkpoint report** plainly: built/where/what passed/what owes. Offer continue/adjust/stop. Wait on structural.

5. **Long-running tasks** (training, bulk jobs): start them, report the job id/log path, and DON'T block the checkpoint loop — queue completion review as a task with its metric band from the budget line.

6. **Session close:** status footer update + commit + one-sentence stopping point.

7. **Diff-size flag** at ~2x estimate: stop; report growth.

## Cognitive traps

- "Workers can run their own git" — one hand writes the books.

- "Launch-and-pray is parallelism" — long jobs are launched with completion reviews queued.

- "Checkpoints slow him down" — checkpoints are his control.

## Guardrails

- Workers never hold approval power.

- No code outside the approved plan; discoveries go back to the plan.