Implementing Batch

Implement

Run a decided change to completion in one pass. The enemy is checkpoint implementation: repeated confirmation of decisions already made. The overcorrection is unchecked autonomy: one wrong assumption propagates through every file. Use breakers instead of checkpoints.

Activation gate

Skip this skill when the whole request is a version-only bump of an installed dependency with no required API migration, a git operation, or a read-only question.

For every other decided change, count these facts after initial inspection: more than two source/test/config files must change; a dependency is added; a public signature changes; a persisted format or security boundary is crossed; a required file was not covered by the inspection. Zero facts means read the ranges, make the direct edits, run their check, report the result, and stop — applying the test-design row in References first when the change is risky or one of them adds or changes an automated test. One or more means run the loop, because the task list, the baseline and the review cost more than an edit of two files is worth.

Context discipline

Every token a tool call returns here is carried into every turn that follows. Keep this context small.

• Address files by repository-root-relative or absolute paths. Never chain cd &&, and never pipe a test or build runner: a chained or piped runner hides which command failed and its exit code.
• Read bounded ranges: pass an offset and a limit to Read; scope every grep to a path; never cat a file over 100 lines — Read the range you need.
• Delegate discovery that spans several files, or that one direct search failed to settle, to the exo:explorer agent, and the review to code-review, so their output never lands here. Read directly here only the ranges you will edit.

The loop

1. Orient. When a file named implement-next.md exists under the directory git rev-parse --git-dir prints, read it first: a previous context left the task list and the remaining edits there, so they are the orientation, and delete the file once they land. Otherwise dispatch discovery to the exo:explorer agent: give it the change and the files or symbols to locate. When the request already names the file or symbol, read its range here and dispatch no explorer, because a dispatch then costs more than the read. Read directly here only the ranges the explorer names under Read next, plus their direct callers or callees. Treat upstream Decisions as settled. When one plan task is the unit of work, its Files: lines and step code are the orientation: read those regions directly and dispatch no discovery delegate. Name the root documentation path: AGENTS.md when the repository root contains it, otherwise a root CLAUDE.md when present; create neither. After orientation and before ordering, apply the data-migration row in References; do not load it during the initial read.
2. Order. Draw the dependency edges between edits: A → B means B cannot land green before A. Two or more edges load planning at inline depth before editing, unless an upstream shaping brief already lists every edge and places A before B for each one. Then open the task list once in the harness under the progress rule in using-exo: the ordered edits, the inline plan's steps, or the plan artifact's tasks when one exists, one line each.
3. Settle the workspace, then the baseline. Before the first edit, settle where the change commits as ../implementing/references/workspace.md says, and stop until the answer when it asks. Its question offers three options, a new branch, a worktree and the current branch, because a two-option question hides the worktree, with the recommended one as number 1 where that reference puts it. Then, when more than one file will change, confirm the working tree is clean or name every pre-existing changed path. After the baseline and before the first affected test or production edit, apply the security and test-design rows in References; do not load either during orientation.
4. Build. Before the first edit that adds or replaces code, take the rung the right-sizing ladder in the session context names from the ranges already read; the ladder sizes the edit, never the reading, and no skill call brings it. Make the decided edits in dependency order against the ranges you have read; do not re-scan the tree between edits and do not ask between files already inside scope. A comment documents the code as it stands, a constraint, an invariant, or a reason a reader of that file needs; the change's story goes in the commit and the pull request instead, because a comment outlives the change and then reads as a fact about the code. Set each task-list line to in progress as its edit starts and to completed as it lands, with no message between two edits. After a context compaction, rebuild what has landed from the working tree diff before the next edit — the tree, not memory, records what landed.
5. Prove. A risky change, as references/test-design.md defines it, quotes the failing test output before the first production edit and the passing output after it, and no other tier substitutes. Otherwise use the first available tier in this order: exercise the feature; otherwise run a test that failed before and passes after; otherwise run type check and build. Run the proof as one bare command here — no cd &&, no pipe. When its output would exceed the cap, redirect it: <cmd> > .git/implement-proof.log 2>&1; tail -n 40 .git/implement-proof.log, then Grep that log for failures instead of printing it. Inside a worktree, use the directory git rev-parse --git-dir prints instead of .git. A reasoned argument is not completion: when logic changes in a repo with a test runner and no test ran, report unverified, not done.
6. Retain project knowledge. If proof revealed a build, test, or run command, or a failure-causing repository gotcha, missing from the documentation path named in Step 1, append one line there; with no such file, create nothing. Do not record session history: the run's progress stays in the harness's task list, never in project documentation, and reaches a file only through the context breaker below.
7. Fresh eyes. Skip this step when the caller states that a pull-request review follows: that review is the one fresh look, and a second one splits the same findings across two contexts. Skip it too when git diff --stat reports at most two changed files and under 80 changed lines: a review context costs its own body plus the diff and finds nothing Step 5 did not on a change that size. Otherwise run the code-review skill on the session's model on its default target, the branch's commits and working tree, at low effort up to five changed files or 200 changed lines and medium above, and fix each confirmed correctness finding under Step 5's proof; it reads the diff in a context of its own and reports only findings it is sure of. Request match, scope, and claimed proof stay with Step 8, because that skill takes no Goal. When code-review is absent, read references/critique.md, run the seven checks in order, and report that no separate context was available. Do not load references/critique.md earlier.
8. Commit, then finish. Commit the change where step 3 placed it, in Conventional Commits, leaving out every pre-existing changed path step 3 named; outside a git repository nothing commits. Then end on ../implementing/references/finishing.md: its overview carries the goal reached, the proof command with its result, and a decision made on the user's behalf as one line, and its question is the one open action. The task list already carries each edit's final state; the reasoning behind a decision and the work outside the request stay out.

Breakers

Three conditions stop the loop and force an evidence report:

• A hook reports the context budget crossed. Finish the edit in progress at a green state, write the task list with its states and the remaining edits to a file named implement-next.md under the directory git rev-parse --git-dir prints, report, and say a context clear comes next. The name carries no backticks because the skill verifier resolves a backticked .md token as a link.

• The same symptom survives two fix attempts. Report both attempts and observations; do not try a third variation of the same mechanism.

• A required edit lies outside the paths named during orientation or by the brief/plan. Report the path and dependency before touching it; work that belongs on its own branch is reported here, never started.

References

Precedence

debug owns an unproven failure until its cause is established. The frontend-design skill the executing session has loaded owns visual decisions during Build; this skill retains orientation, ordering, non-visual wiring, proof, critique, and reporting. The exo:explorer agent owns read-only discovery; code-review owns the review context.

From a plan

A plan written by planning runs here only when its tasks must build in this session; implementing runs one through delegated contexts and commits per task. Settle the workspace first, as step 3 says. Read ## Goal, ## Plan basis, ## Non-goals and ## Context, then the tasks one at a time in file order, extracted fence-aware between ### Task <n>: headings. For each: confirm every Modify: region reads as the step implies, write each step's code, run its Run: to its Expected:, and run the task's Commit: block under the plan's authorization before the next. A region missing, duplicated or already changed is drift: stop and report PLAN DRIFT: Task <n>. After the last task, end on step 8's finish with nothing left to commit.

Judgment

• Explicit user instructions outrank this skill.
• Settled brief or plan decisions outrank implementation defaults.
• A repair that crosses a second owner, keeps an old route beside the new one, or cannot be explained in one pass goes to debug instead of a further patch, because each sign says the cause is elsewhere.
• Repository test, build, naming, and review conventions outrank unspecified defaults here.