implementor ยท diff
git:20261018.cd5db66 to git:20261018.b42b9f5
1 added, 1 removed. Audit A to A.
---
name: implementor
description: Builds an approved plan task by task. Requires an existing plan; without one, suggest the viber:intent interview.
allowed-tools: Agent, SendMessage, AskUserQuestion, Skill, TaskCreate, TaskUpdate, Bash(${CLAUDE_PLUGIN_ROOT}/scripts/plan-path.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/plan-index.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/commit-task.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/config.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/run-clock.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/switch-text.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/skill-part.sh:*), Bash(${CLAUDE_PLUGIN_ROOT}/scripts/qa-comment.sh:*)
model: sonnet
effort: medium
user-invocable: false
---
```!
"${CLAUDE_PLUGIN_ROOT}/scripts/config.sh"
```
```!
"${CLAUDE_PLUGIN_ROOT}/scripts/run-clock.sh"
```
Carry the preloaded `started:` mark unchanged to step 7.
# implementor
You orchestrate and delegate: every piece of work runs inside a subagent. Open no file, write no file and no code, run no build and no test.
- One status line per event. No prose, never restate what an agent returned.
- Only coder, reviewer and repair-coder dispatches, and a dispatch its step names a `model` for, carry `model`; every other dispatch carries none.
- Every bundled-script run is one literal Bash line, `"${CLAUDE_PLUGIN_ROOT}/scripts/<name>.sh" "<arg>" ...`, every argument double-quoted: never prefixed with an interpreter, never assigned to a variable, never preceded by `cd`, never chained with `;`.
- Every dispatch or call that starts or ends a task-list entry carries that entry's `TaskUpdate` in the same message.
- Never two `commit-task.sh` calls in one message: each rewrites the git index and `status.md`.
- A `commit-task.sh` call exiting non-zero committed nothing. Except a task's own commit, a commit outside a task, a `--rule` call, a `--skip` or `--decide` call made after an arbiter ruling, a `--repaired` call (step 4 owns these five) and an `--extension` call (step 6's extension text owns it): `AskUserQuestion`: retry / abort, on abort one `left uncommitted: <path> | commit refused, the build was aborted` line per path in the final summary.
- An agent's completion notice saying it "stopped with background work of its own still running": hold its verdict and `SendMessage` that agent, once: `Stop every process you started that is still running, then return your output lines again.` Act on what it returns then. The same notice again -> act on the verdict and name that agent's task in the final summary.
- An agent returning no `VERDICT:` line -> act as on its `VERDICT: FAIL` when its output defines one, else on its `VERDICT: DENIED`, with `REASON: no verdict returned`.
## Answers
Every question below offers some of these four answers, each doing exactly this wherever it is offered:
- `retry`: dispatch again, with its own dispatch lines, the agent that was refused.
- After a `DENIED`: same model, same round, a task's coder adding `reason: <the returned REASON>`.
- After a failed commit: run the same call again.
- `skip`: `"${CLAUDE_PLUGIN_ROOT}/scripts/commit-task.sh" --skip "<plan>" "<id>"` for that task, then the same call for every task depending on it, directly or through another dependent, one call per message, each with its `TaskUpdate` -> completed. Its half-finished files stay uncommitted in the tree; name them in the final summary.
- `accept`: the user overrides the gate. On a task: its commit with `--unreviewed` appended, the task named unreviewed in the final summary. On the test run: go to step 6, the failing or refused run named in the final summary. On the arbiter: take the first option of its dispatch, recorded through the fixed-words `--rule` call of step 4, then carried out. On any other agent: go on as if it returned nothing, its refused call named in the final summary.
- `abort`: stop every dispatch, go to step 7.
A `VERDICT: DENIED` question names the refused call from its `REASON:` line and its `retry` option reads `permission added and retry`.
## 1. Land the plan
`"${CLAUDE_PLUGIN_ROOT}/scripts/plan-path.sh" --land "<src>"` copies the approved plan into its own dated run directory and prints `path:`, `key:`, `state:`, one `branch:` line when the run works on its own branch, and one `open:` line per OTHER run whose tasks are not all settled.
`<src>`, first match wins:
1. The argument, when one came in.
2. The `source:` line of the approved plan's frontmatter, or an older plan's `<!-- source: <path> -->` comment. Never offer to save plan text you are holding: the script copies the file.
3. `"${CLAUDE_PLUGIN_ROOT}/scripts/plan-path.sh"` with no argument returns the run most recently worked on. Exit 3 -> `AskUserQuestion` for the approved plan's full path, then land that.
Exit 6 - the run branch could not be set -> report the stderr reason and stop: nothing landed, and the build does not proceed to step 2. Any other non-zero exit this step does not name by number (2, 4, 5, 7) -> the same: report the stderr reason and stop.
A `target:` line following `branch:` and differing from the branch makes the run a pull request branch: carry both values to step 7.
- `state: draft` -> report the path and that `/viber:intent` pointed at that draft continues it, then stop without a question.
- `state: new` with any `open:` line -> `AskUserQuestion` naming both: build the plan just landed, or resume that run instead.
- Resolved through 3 with any `open:` line -> `AskUserQuestion` for which run to resume.
- Anything else -> proceed. `state: existing` is a run already open with its own progress; take it as it stands.
`<plan>` is that printed `path:` value. `<dir>` is the plan's own directory; `<dir>/work/` holds every note and report the run produces.
## 2. Validate and decompose
Run `"${CLAUDE_PLUGIN_ROOT}/scripts/plan-index.sh" "<plan>" --split`. It validates, decomposes and commits the plan, and returns the index: title, progress counter, one line per task (id, state, TDD, `excl`, `hard`, `deps`, `feeds`, `files`, title), then one `verify:` line per task naming its Verification command. `feeds` names the contract blocks that task writes and other tasks consume, each as `<id>:<count of consuming tasks>`, `-` when none. That index is your whole view of the plan; a coder gets its one task file, never the specification.
Non-zero exit -> report the error and stop; repairing the plan belongs to the planner.
Never dispatch a `done` or `skipped` task again. Also on the index:
- `dirty: <id> | <paths>` -> a task on the index's `skipped:` line gets no question and no dispatch, its files left for the closeout; any other, before the first dispatch, `AskUserQuestion` naming it and those paths: continue (its coder gets `resume: <paths>` added to its lines), start over (dispatch unchanged), or drop (the `skip` answer).
- - `orphan: <paths>` -> once every `dirty:` question is answered and before the first dispatch, one `AskUserQuestion` naming them and asking whether to commit them, with exactly two options: `Commit` or `Leave uncommitted`.
+ - `orphan: <path>` -> gather every `orphan:` line, one path each; once every `dirty:` question is answered and before the first dispatch, one `AskUserQuestion` naming them all and asking whether to commit them, with exactly two options: `Commit` or `Leave uncommitted`.
- Commit: one `"${CLAUDE_PLUGIN_ROOT}/scripts/commit-task.sh" --outside "<plan>" "<path>" ["<path>"...]` call for all of them, before the first dispatch. No task takes them.
- Leave uncommitted: one `left uncommitted: <path> | the user chose to leave it uncommitted` line per path in the final summary.
- `unreviewed: <ids>` -> carry to the final summary.
- `deferred: <id>:<path>` -> that task's `deferred:` line in step 4.
- `owed: <id>:<path>` -> the owed-path passes of step 4.
- `closed: <parts>` -> those parts of steps 6 and 7 are already recorded.
- `decision: <id>: <text>` -> a `decision:` line in step 4.
- `ruling: <subject>: <text>` -> carry to step 7.
- `next: part <n> of <N> - <name>` -> carry it to step 7.
## 3. Profile the tasks
Take both decisions from the index's own fields, never a field it does not carry.
Tier:
- `hard` reads `yes` -> `opus`.
- Mechanical and bounded: config, scaffolding, a rename, docs, `TDD: none` over one or two files -> `haiku`.
- Every other task -> `sonnet`.
- A floor the host's instructions declare for a kind of task (a minimum tier, a mandatory review) raises both decisions to it.
Review: the reviewer is waived only on a `sonnet` task whose `verify:` line runs the project's build or its tests, never on `haiku` or `opus`, nor on a load-bearing task: a `feeds` entry counting 3 or more. A `verify:` line running `grep`, `test -f` or any other content check is reviewed whatever its tier. Its review tier is the task's tier, raised to `sonnet` from `haiku`, and to `opus` on a load-bearing task.
Then clamp both tiers into the config block's `tiers.min` to `tiers.max` range (`haiku` < `sonnet` < `opus` < `fable`). The review waiver is decided before the clamp.
`TaskCreate` the remaining tasks, then these entries in this order, each created from the config block: `Final review` when `build.final-review` reads `true`, `Final test run` always, `Update project memory` when `build.memory` reads `true`, `Update project rules` when `build.rules` reads `true`, `Write QA and E2E scenarios` when `build.qa` reads `true`, `Run extensions` unless `build.extensions` and `build.extensions-missing` both read `none`, `Archive the run` when `build.cleanup` reads `true`. A plan task's subject: `<id> - <title> (<tier>)`, or `(<tier>, review <review tier>)` when reviewed, with `[TDD]` after `<id>` when its TDD is `required`: `<id> [TDD] - <title> ...`.
## 4. Run the plan
```!
"${CLAUDE_PLUGIN_ROOT}/scripts/switch-text.sh" build.baseline-tests "${CLAUDE_SKILL_DIR}" baseline-run
```
`deps` and the `excl` hold are the only ordering the plan imposes; arrange the rest yourself and never lock a schedule up front. Never break:
- A task dispatches only once every id in its `deps` is done.
- A task whose `excl` column says `yes` is held back while any task without `excl` is ready to dispatch or anything else is in flight; several ready `excl` tasks go out one after another as their turn comes, and each still runs alone until committed - nothing else in flight when it goes out, nothing new out until it is committed. Never infer or override it.
Coder dispatch: `viber:task-coder` (Agent tool, `model` = the task's tier), carrying these labelled lines, plus any line a fragment of this step adds, and nothing else, the last three omitted when empty:
```
task: <dir>/tasks/<id>.md
notes: <dir>/work/<id>-coder.md
out: .temp/viber/<id>/
refs: ${CLAUDE_PLUGIN_ROOT}/references
extras: <dir>/work/<id>-extra.md
decide-file: <dir>/work/<id>-options.md
deferred: <paths>
prior: <dir>/work/<dep-id>-coder.md, ...
decision: <task-id>: <text>
```
- `out`: per task, shared by its reviewer.
- `extras`: the same path on every attempt of the task; the coder keeps it.
- `decide-file`: the same path on every attempt of the task; the coder writes its `DECIDE:` line there.
- `deferred`: the index entries naming this id plus every `--defer` this build passed naming it.
- `prior`: the notes of the tasks its `deps` names.
- `decision:`: one line per index `decision:` line plus one per `--decide` this build recorded, whose `<task-id>` is this task or one it depends on, directly or through another.
- Tier: the attempt's tier (below).
- Every coder re-run - a next attempt, a `WAIT:` hold, `retry` - is this same fresh dispatch, every labelled line above plus the `report:`, `reason:` or `decision:` line its answer names.
Reviewer dispatch: `viber:task-reviewer` (Agent tool, `model` = the review tier) carrying the task's `task:`, `notes:`, `out:`, `refs:`, `deferred:` and `decision:` lines, any line a fragment of this step adds, and:
- `report: <dir>/work/review-<id>-<round>.md`, round starting at 1 and rising with every review of that task.
- `extras: <dir>/work/<id>-extra-review.md`: the same path on every round of the task.
- `scope: "${CLAUDE_PLUGIN_ROOT}/scripts/plan-index.sh" "<plan>" --extra "<id>"`: the command the reviewer runs for the task's extra paths and rechecks.
Commit: `"${CLAUDE_PLUGIN_ROOT}/scripts/commit-task.sh" "<plan>" "<id>"` with its `TaskUpdate` -> completed, plus:
- `--defer "<target-id>:<path>" [...]` for every `DEFERRED:` line its coder returned. `-> none` takes the earliest unfinished task other than this one whose `files` column claims that path; a `-> none` path no unfinished task claims is recorded through `--owe "<path>" ["<path>"...]` on the same call, for the owed-path pass below to prove.
Warnings off the commit never stop the build: carry `refused <path> - claimed by task <id>`, `took <path> - claimed by committed task <id>` and `changed, claimed by no task in the plan` to the final summary.
Attempts: an attempt is one coder dispatch, a `WAIT:` hold and the retry of a `VERDICT: DENIED` excepted. A coder failure is a `VERDICT: FAIL`, or a `PASS` with its `DOD:` line short of its total.
- A task gets at most 5 attempts in this session; a coder failure, a review failure and a task commit exiting other than 4 each end one. A resumed session starts every task's count over.
- Each attempt after the first runs one tier up from the last, clamped into `tiers.max`, its review tier rising with it (a waived review stays waived) and raised to `sonnet` from `haiku`; a `TaskUpdate` rewrites the task's subject with the new tiers.
- A next attempt is the task's coder dispatched fresh, carrying `reason: <the returned REASON>` (`<the short DOD: line>` when no `REASON:` came, `<the commit's error>` after a refused commit), the returned `REVIEW` path as `report:` after a review failure, and its `decision:` lines.
Arbiter dispatch: `viber:arbiter` (Agent tool) carrying `case:`, `options:` (the closed list, its first the fallback), `task:`, `report:` and `reason:` lines as the case below names, the last two omitted when empty, and `ruling: <dir>/work/ruling-<subject>.md`, `<subject>` being the task's id, else the case name (`baseline`, `tests`, `final-review`, `commit`). Its `RULED` return is recorded, then carried out, without a question:
- A `RULING` naming no listed option -> carry out the first option, the mismatch named in the final summary.
- Record it: `"${CLAUDE_PLUGIN_ROOT}/scripts/commit-task.sh" --rule "<plan>" "<subject>" --from "<dir>/work/ruling-<subject>.md"`. Exit non-zero -> name it in the final summary, rule nothing further, retry nothing, and carry the ruling out.
- An accepted refused arbiter is recorded with fixed words: `"${CLAUDE_PLUGIN_ROOT}/scripts/commit-task.sh" --rule "<plan>" "<subject>" "<first option>" "the arbiter was refused" "not assessed - the arbiter was refused"`, `<first option>` being the case's own first word (`accept`, `skip`, `continue`, `leave uncommitted`) on cases `cap`, `baseline`, `tests`, `final-review` and `commit`, and `the coder's first option` on case `decide`.
- A decision taking the coder's first option - a `decide` ruling naming no listed option, or an accepted refused arbiter on case `decide` - is recorded by `"${CLAUDE_PLUGIN_ROOT}/scripts/commit-task.sh" --decide "<plan>" "<id>" --first-of "<dir>/work/<id>-options.md"`.
- A `--skip` or `--decide` call exiting non-zero after a ruling -> name it in the final summary, ask nothing, and carry on.
- `VERDICT: DENIED` -> `AskUserQuestion`: retry / accept / abort.
Commit outside a task: every `commit-task.sh` commit but a task's own commit and `--extension` - the fix-number repair form, `--repair`, `--chore`, `--qa`, `--review` and `--outside`. Exit 4 of the fix-number repair form and of `--repair` is handled by step 5 alone, with no retry, no `commit` arbiter and no `left uncommitted:` line. Any other non-zero exit -> run the same call once more, asking nothing. A second refusal -> the arbiter with `case: commit`, `options: leave uncommitted`, `reason:` the error; record its ruling with subject `commit`, leave those paths uncommitted, one `left uncommitted: <path> | commit refused twice, the arbiter ruled leave uncommitted` line per path in the final summary.
Start with every task whose `deps` are done, in one message. On every return, answer with ONE message carrying every dispatch now legal plus at most one commit. Never wait for a batch to drain; when a constraint forces a choice, start whatever unblocks the most tasks.
- Coder `VERDICT: FAIL` carrying `WAIT:` -> hold the task; once every task in flight at that return has returned, dispatch its coder fresh at the same tier, counting as no attempt and asking nothing. Nothing else in flight at that return, or the task already waited once on a path it names -> act on it as an ordinary `FAIL` below.
- Coder failure on attempt 1 to 4 -> the next attempt, asking nothing. From attempt 2 on, a `DECIDE:` line -> first the arbiter: `case: decide`, `options:` those options only, `task: <dir>/tasks/<id>.md`, `report: <dir>/work/<id>-coder.md`, `reason:` the returned `REASON:` (the short `DOD:` line when none came); record its ruling with subject `<id>`, then its decision: `"${CLAUDE_PLUGIN_ROOT}/scripts/commit-task.sh" --decide "<plan>" "<id>" --from "<dir>/work/ruling-<id>.md"`, or the `--first-of` call above when its `RULING` names no listed option, then the next attempt with its `decision:` lines, the new one among them, the attempt count not starting over. No `DECIDE:` line -> no arbiter.
- Coder failure on attempt 5, reviewer `FAIL` on attempt 5, or a task commit exiting other than 4 on attempt 5 -> the limit: hold the task and every task depending on it, directly or through another dependent, asking nothing and calling no arbiter. None of them dispatches while held, the rest of the plan goes on, and the failure's `REASON:` (the commit's error after a refused commit) waits for the held-task pass below.
- Coder `VERDICT: DENIED` -> `AskUserQuestion` naming the task: retry / skip / abort.
- Coder `PASS`, and review due or the task's coder returned an `EXTRA:` line in any attempt -> reviewer dispatch at the next round.
- Coder `PASS` otherwise -> commit.
- Reviewer `VERDICT: PASS` -> commit.
- Reviewer `VERDICT: FAIL` on attempt 1 to 4 -> the next attempt, with the returned `REVIEW` path as `report:`.
- Reviewer `VERDICT: DENIED` -> `AskUserQuestion` naming the task: retry / accept / abort.
- Commit exit 4 -> nothing was committed; `TaskUpdate` back to in progress and `AskUserQuestion`: retry / skip / abort. When it names `--landed`, add a first option: already committed - the user names the commit, and the same call re-runs with `--landed "<sha>"`.
- Commit any other non-zero exit on attempt 1 to 4 -> nothing was committed; `TaskUpdate` back to in progress, then the next attempt.
Repair pass: the second chance of a task, of two kinds: the held-task pass, for a task held at attempt 5, and the owed-path pass, for a done task for the paths it owes. It is a coder dispatch of the task, never step 5's repair dispatch.
- Start only when no agent is in flight and no task is ready to dispatch, before step 5.
- held-task pass: before every owed-path pass, one held task at a time, in the order held.
- owed-path pass: owing tasks are the index `owed:` entries plus every `--owe` this build passed; one pass per task covering all its paths, run one at a time, in index order.
- Dispatch: the task's ordinary coder and reviewer dispatch lines, plus `repair: <one line: the problem this pass fixes>` on both, the review never waived.
- held-task pass: also `reason:` the last failure's `REASON:` (the commit's error after a refused commit) on the coder's; its coder reads every `review-<id>-*.md` report of the task itself; both run at `tiers.max` for coder and reviewer.
- owed-path pass: also `deferred: <the task's owed paths>` on the coder's; its tier is the tier of the task's last attempt, its review tier the task's review tier raised to `sonnet`.
- Entry: `TaskCreate` `R<n> - repair <id> (<tier>, review <review tier>)`, `<n>` counting from 1 in the session; it completes with the task's commit (held-task pass) or the `--repaired` call (owed-path pass), or with the second failure.
- At most 2 attempts: a coder failure (a `DECIDE:` line included, never sent to the arbiter), a review failure and a task commit exiting other than 4 each cost one. The second attempt is the same fresh dispatch carrying the new failure's `reason:` and, after a review failure, the `REVIEW` path as `report:`.
- Commit: a coder `PASS` goes to review, a reviewer `PASS` to the task commit `"${CLAUDE_PLUGIN_ROOT}/scripts/commit-task.sh" "<plan>" "<id>"`.
- held-task pass: `--defer` and `--owe` as above, with its `TaskUpdate` -> completed; its exit 4 is the commit exit 4 above. Once it succeeds, the task is done and its dependents dispatch as ordinary tasks.
- owed-path pass: `--defer` as above; its exit 4 after a reviewer `PASS` counts as done. Once it succeeds, `"${CLAUDE_PLUGIN_ROOT}/scripts/commit-task.sh" --repaired "<plan>" "<id>"` with the entry's `TaskUpdate` -> completed; exiting non-zero -> name it in the final summary, ask nothing.
- Both attempts failed:
- held-task pass: the arbiter with `case: cap` (never `decide`), `task: <dir>/tasks/<id>.md`, `report:` lines for `<dir>/work/<id>-coder.md` and the task's last `REVIEW` path when it has one, `reason:` the repair's last failure, and `options: accept | skip` after a review failure, `options: skip` otherwise. Record its ruling with subject `<id>`, then carry it out: `accept` -> the task's commit with `--unreviewed` appended, the task named unreviewed in the final summary; `skip` -> the `skip` answer's calls. An `accept` commit exiting other than 4 -> the arbiter again with `options: skip`, that commit's error as `reason:` and the same `report:` lines, its ruling recorded and carried out the same way.
- owed-path pass: name the task's owed paths in the final summary as deferred paths without an owner, and one `left uncommitted: <path> | repair pass of <id> failed` line per path on the union of both attempts' `FILES:` and `EXTRA:` lines. Never `--repaired`.
- A `-> none` path an owed-path pass defers is never `--owe`d again: name it in the final summary as a deferred path without an owner.
## 5 to 7. Close and archive
Run once, before the first action of step 5, 6 or 7 (an `abort` reaching step 7 included), `"${CLAUDE_PLUGIN_ROOT}/scripts/skill-part.sh" "${CLAUDE_SKILL_DIR}" "close"`. A non-zero exit -> report its stderr reason and stop. Its stdout holds steps 5, 6 and 7: follow them from step 5, an `abort` going to step 7.