--- name: implement description: This skill should be used when a task's design has closed cleanly and it is time to begin building, for example "start implementing this task", "begin the build", or "Phase 3". It freezes the criteria and the work orders into a snapshot, opens the ledger that tracks each order's progress, refuses to land the build on the project's own trunk branch, establishes whether this repository can build and test at all, writes the tests for one work order and freezes them, writes the code for that order until it passes all eight deciding checks, reviews the diff, repairs what the review finds, closes the order, and once every order is closed records the task's implementation as finished. argument-hint: "[]" arguments: [taskId] allowed-tools: Bash(${CLAUDE_PLUGIN_ROOT}/skills/implement/scripts/implement-actions.sh *), Agent --- # Implement Implementation builds each work order design wrote, one at a time, against tests it cannot change once they are frozen. One freezes the contract and the work orders into a snapshot and opens the ledger that will track every order's progress. Two establishes whether this repository can run a test at all. Three writes the tests for one work order, watches each one fail, and freezes them. Four writes the code until it passes all eight deciding checks. Five reviews the diff, repairs what the review finds, verifies each repair, and closes the order. Once every order closes, `finish` records the task's own implementation as done and hands it to the review stage. ## Find the task Resolve the active project's own folder first, then the task, `` when given or whichever task is already active in this conversation. Neither known: say so in one line and name the task skill. Stop; there is nowhere to act. Once found, the task's own folder is `/tasks/`. Every call below takes that folder. ## Read what is already there Run: ``` "${CLAUDE_PLUGIN_ROOT}"/skills/implement/scripts/implement-actions.sh read "" ``` This prints summary lines, one `key: value` each: - the contract's state, and whether design has started and how many work order files it left; - the task's project, its code repository, the current branch, and the trunk branch when derivable; - the task's own run mode; - the snapshot's path and hash, the ledger's path, and whether a preconditions record and a finished record exist; - one `order(...)` line per work order: its last step, its halt reason, its counters and its review state; - the criteria counted by row state; - a `next:` line naming the step the table below would choose. No contract, or design has not started: say so in one line and name the missing stage. Stop. ## Which step, and where its instructions are The `next:` line from `read` names the step. It is derived from the ledger the way this table reads it. Match it to one step, open that step's own file, and follow it. Each file holds everything for its step and nothing for another, so only the step being run is in this conversation. The table is the derivation, kept here so a person can check the line against the state the other lines report. | The summary says | The step | Step name | |---|---|---| | `snapshot: none`, or a snapshot with `ledger: none` | Start the build | `start` | | A ledger, `preconditions: none`, and an order that could move | Check the preconditions | `preconditions` | | Preconditions recorded, and an `order(...)` line reading `not started` whose dependencies are all `closed` | Write the tests for one work order | `tests` | | An `order(...)` line at `tests-frozen`, or `code-written` with attempts remaining and `halt: none` | Write the code for one work order | `build` | | An `order(...)` line at `checks-passed` | Review the order | `review` | | An `order(...)` line at `reviewed` or `fixed`, with `review: open=` above zero and a fix round left | Fix, then verify | `review` | | An `order(...)` line at `reviewed` or `fixed`, with `review: open=0` | Close the order | `review` | | An `order(...)` line at `closed` | Nothing left to do on it. Take the next ready order | | | Every order `closed`, `finished: none` | Finish the task | `finish` | | An `order(...)` line whose halt holds a `design drift...` segment, anywhere in it | Offer the restart | `finish` | | An `order(...)` line whose halt holds an `attempts spent...` or a `budget spent...` segment and no `design drift...` one, a person present | Offer the grant | `finish` | An order in flight comes before a new one, and a halted order is named only when nothing else can move. A resumed run starts at `start` regardless, because that is where drift since the snapshot is checked, and it says which orders halted. Its own `next:` line then applies. ## One order halting does not stop the run When an order halts, at its attempt cap or for drift, only the orders that depend on it wait. Everything else that is ready still builds. Run `start` again: it is safe on a resumed run, and it reports which orders are ready, which halted and why, and which are in flight. Take the next ready order and apply the table. Stop only when nothing is ready. Then report what halted, with the reason the ledger holds, and what is waiting on it. Interactive puts that to the person, who decides from the recorded attempts which of three things is true: the test is wrong, the order is wrong, or the code is hard and a person writes it. Unattended, the run ends there with the report, and decides none of the three. A model ruling that a test is wrong, with nobody watching, is the test describing the code again. A halt beginning `attempts spent`, `budget spent` or `design drift` has its own next step in `references/finish.md`. The first takes the grant of one more attempt. The second takes the same grant, after the run's budget is raised. The third takes the restart after a design change. Offer any of them only when a person is present to decide it. A run has a ceiling when the task sets `budget` in its own record, in dispatches or in minutes. `dispatch-open` recomputes what was spent from the ledger before every dispatch and halts the order at the ceiling. Absent budget means no ceiling, and the per-order caps still hold. Open the step file through the script, not through the Read tool: ``` "${CLAUDE_PLUGIN_ROOT}"/skills/implement/scripts/implement-actions.sh step ``` This prints `references/.md`. A `Read` rule naming that folder does not reliably expand `${CLAUDE_PLUGIN_ROOT}`, which is why this skill grants only the one Bash rule above. Run `step` every time this table sends you to a file, even a file already read this turn. A step run from memory of an earlier invocation is a step run against rules that may have changed. ## Five rules every step repeats These hold for every step below, and each step file names them rather than restating them. This file is always loaded; a step file is loaded only while its own step runs. **The conversation holds summaries and paths. The records hold the bodies.** Every action prints `key: value` lines and a path, and each record action ends with `next:`. Never read a record, a brief, a diff, a tool output or a finding's evidence into this conversation, and never paste one back. Name the path the script printed, and say the person can open it in an editor. Each brief action writes its brief to a file and prints the path; the dispatch prompt names that path and carries no brief content. **Only the dispatched role reads bodies**, and it opens them itself, from the paths its brief names. The one exception is text a person must read to answer: a checklist row at `tests-freeze`, or a question a step asks. A body pasted here costs the build the context its own steps need. **Name the role on every dispatch.** A dispatch that names none runs as the general agent, with every tool and this session's own model, and the dispatch record just opened then matches nothing: the hook compares the agent's own type against the role in the record, so an unnamed dispatch is an unenforced one. **A recipe lookup has three answers, not one.** No recipe for this framework, a listing that could not be reached, and a failed network are three different things, and only the first says anything about the framework. Pass the one that happened, in its own word. **A test green on its first run has four outcomes.** Wrong test: corrected once. Still green, and the author names the existing code that satisfies it: frozen, and the reason recorded. Still green with nothing to name: reported, and the step stops. Failed: frozen with its red run. `references/tests.md` holds the flags. **The script reads a recipe's command blocks, never you.** Pass a recipe path straight through to the action that takes it. `## Test commands` and `## Check commands` are parsed by the script, one entry per tool, each with its own argv, its `{paths}` placeholder, and its `signal` and `extensions` keys where present. It refuses (exit 72) when two frameworks each command one tool. **Close the dispatch record as soon as the role returns**, whether it succeeded or not: ``` "${CLAUDE_PLUGIN_ROOT}"/skills/implement/scripts/implement-actions.sh dispatch-close "" ``` It refuses (exit 75) when the open record names a different task than this one: closing another task's record would leave that task's own role holding every permission the record withheld. ## What this skill does The permissions this step describes are applied by the runtime, not by the words above. Two hooks do it, and both report through a message when they cannot find what they need rather than passing in silence. Neither has run inside a live dispatch yet, so say that plainly rather than reporting them as proven. The read denial covers Read and Grep, and not the shell. The test author runs its own tests, so it holds Bash, so a `cat` of a denied file is not refused. That is deliberate: the rule exists to stop the role opening the source because reading the code is the obvious way to write a test about it, and a role working around the rule on purpose has already failed in ways no hook catches. Say that when the person asks what the dispatch enforces, rather than describing the denial as complete. `dispatch-open`'s `--allow-write` is a third thing withheld, beside the read denial and the shell door above. It is recorded for a reader, and no hook applies it. The frozen-test hook decides by whether a path is frozen, never by this flag. Say the same about it that you say about the other two: recorded, not enforced. The five answers a builder or a fixer writes into its report are a fourth. The record steps refuse an empty report file, and nothing checks the file holds five answers, that they preceded the write, or that the diff stayed inside them. Recorded, not enforced. The tool grants in this file's own frontmatter hold for one turn. The runtime clears them at your next message to the person, so a multi-turn build asks again for the Bash rule after that message. That is how a skill's grants work, not a fault in this one. Say so when a person asks why the same command prompts again partway through a build.