git:20260904.f9b5267 to git:20260904.5a122b3

19 added, 100 removed. Audit A to A.

---

name: implementing-slices

- description: Slice-by-slice execution procedure for the implementer agent — dispatch modes (initial and review-fix), the slice-execution loop, TDD discipline, blocker handling, and the scope fence. Loaded when an implementation plan is executed or a hard-gate review failure needs fixing.

+ description: 'Defines test-first slice execution, commits, and review fixes. Load when an implementer executes `8-plan.md`.'

user-invocable: false

---

# Implementing Slices

- The implementer's execution procedure: consume the plan, work through one

- vertical slice at a time, and commit each slice atomically the moment its

- tests pass.

+ Consume `docs/plans/<id>/`, implement one vertical slice at a time, and commit each atomically when its tests pass.

## Dispatch modes

- The orchestrator dispatches you with the artifact directory

- `docs/plans/<id>/`.

### Initial dispatch (after the test-architect's failing tests are confirmed)

- Your inputs are the plan (`docs/plans/<id>/8-plan.md` — slice list,

- file-level steps, per-slice tests), the structure

- (`docs/plans/<id>/7-structure.md` — order and verification checkpoints), the

- failing acceptance tests (the completion contract), and

- `docs/plans/<id>/4-repos.md` when present. `4-repos.md` defines multi-repo

- mode: each repo's slug, absolute path, and worktree path (under

- `## Worktrees`); every plan step annotated `[repo: <slug>]` is applied

- inside that repo's worktree — `cd` there before running the step's edits,

- tests, and commits. Before implementing, run the test suite once (in each

- involved worktree, in multi-repo mode) to establish the baseline of

- failing tests.

+ Read `8-plan.md` (steps/tests), `7-structure.md` (order/checkpoints), immutable failing acceptance tests, and `4-repos.md` when present. In multi-repo mode, use each slug, absolute path, and `## Worktrees` path; execute every `[repo: <slug>]` step and prefixed test inside that worktree. Run the suite once in every involved worktree to confirm the failing baseline.

### Review-fix dispatch (after a hard-gate failure)

- When dispatched after the aggregate gate fails, you are in a **fix loop**.

- The orchestrator passes you a typed failure class and the reviewers'

- findings. Fix what the findings name, under these constraints:

+ The orchestrator supplies a typed failure class and reviewer findings. Fix every named item:

- - **Security findings: never weaken the fix.** Fix each vulnerability

- directly — parameterize the query, remove the hardcoded secret, add the

- auth check, escape the output. The security reviewer re-checks with

- fresh eyes.

- - **Test failures: fix the code, not the tests.** Tests are the

- contract — the implementation must satisfy them as written.

- - **Code-review findings: do not argue with the review.** Fix what each

- `issue:` comment names.

- - **Lint / format, typecheck, and build failures:** re-run the same check

- until it passes. Auto-fixable lint issues go through `--fix` first.

- - When a failure is **non-obvious** — the cause is not plain from the

- error and the first fix you reach for is a guess — call the Skill tool

- with `systematic-debugging`

- and walk the

- **Root Cause Analysis (5 Whys)** causal chain to the root before

- editing, so you fix the root cause rather than the symptom

- (`skills/principle-fix-root-causes/SKILL.md`). Skip this

- for an **obvious** failure (a typo, a trivially-named assertion, a

- clear one-line fix) — drilling a one-line fix is wasted ceremony. The

- fast path stays intact.

+ - Security: fix the vulnerability directly—parameterize queries, remove secrets, add auth, escape output; never weaken the fix.

+ - Tests: change code, never the immutable tests. Code review: fix every `issue:`. Lint/format/typecheck/build: rerun until passing; use `--fix` first where available.

+ - For a non-obvious failure whose first fix is a guess, call the Skill tool with `systematic-debugging` and complete **Root Cause Analysis (5 Whys)** (`principle-fix-root-causes`). Skip it for an obvious typo, named assertion, or one-line correction.

- After fixing: re-run the full test suite so nothing regressed, address

- every failure type reported in the round before reporting completion, and

- report which findings were fixed and what changed. The orchestrator will

- re-dispatch ALL 5 reviewers to verify your fixes.

+ Then run the full suite, resolve every failure type from the round, and report each fix. The orchestrator re-dispatches ALL 5 reviewers.

## Slice-by-slice execution

- Execute the plan one slice at a time, in the order the plan specifies. A

- slice is done when its acceptance tests pass and prior slices' tests still

- pass; commit it atomically at that moment, report it, and move on. The

- contract per slice:

- - **Steps.** The plan lists each slice's file-level steps. `[sequential]`

- steps depend on prior steps in the slice; `[parallel]` steps may be done

- in any order. In multi-repo mode each step carries `[repo: <slug>]` —

- cd into that repo's worktree before applying it. Cross-repo steps

- within one slice are routine — switch directories as needed.

- - **Tests.** In multi-repo mode, run each acceptance test in the worktree

- where it lives (the test name in the plan carries a `<repo>:` prefix).

- - **Commits.** Call the Skill tool with `git-commit` and apply its commit

- conventions (Conventional Commits, the 50/72 rule, one logical change per

- commit). Single-repo: one commit per slice

- using the slice's `Commit:` line as the subject, body referencing

- the design and structure paths. Multi-repo: when the slice's

- `Repos:` field names more than one repo, produce **one commit per

- repo** in their respective worktrees, using each per-repo `Commit:`

- subject from the plan. Each commit body references the same

- design/structure paths and notes "part of slice <N>: <name>" so

- reviewers can correlate.

- - **Report.** Return a brief summary to the orchestrator per slice:

- `{slice: <name>, testsPassing: [list], commits: [

- {repo: <slug>, sha: <sha>}, ... ]}` (`commits` is a single-entry

- list in single-repo mode).

- When all slices are done, return a final implementation summary to the

- orchestrator (paths, slice list, final test status).

- ## TDD discipline within each slice

- - Write the minimal code to make the slice's tests pass — no more.

- - If a test requires functionality from a later slice, document the

- dependency but do not preempt that slice.

- - Do not optimize or refactor until the slice's tests pass.

- - If you find yourself writing code that no test exercises, stop and check

- if you are on scope.

- ## Handle blockers

- If a slice is blocked (dependency missing, unclear requirement, test appears

- incorrect):

+ - Follow plan order. `[sequential]` steps depend on prior steps; `[parallel]` steps may reorder. Switch repo worktrees for `[repo: <slug>]` steps and `<repo>:` tests.

+ - A slice finishes only when its acceptance tests and all prior-slice tests pass.

+ - Call the Skill tool with `git-commit`: Conventional Commits, 50/72, one logical change. Single repo: one commit using the slice `Commit:` subject and citing design/structure paths. Multi-repo slice: one commit per named repo using its `Commit:` subject; each body cites the same paths and says `part of slice <N>: <name>`.

+ - Report `{slice: <name>, testsPassing: [list], commits: [{repo: <slug>, sha: <sha>}, ...]}`; single-repo has one commit entry. After all slices, return paths, slice list, and final test status.

- 1. **Document the blocker** — what is blocked, why, and what would unblock it.

- 2. **Continue with the next unblocked slice** if the structure allows it.

- Many slices depend on prior slices. Respect those dependencies.

- 3. **Return to blocked slices** after completing unblocked work, in case the

- blocker has been resolved.

+ ## TDD and scope invariants

- ## Scope fence

+ - Write only minimal code exercised by the current slice's tests. Do not preempt later slices; do not optimize/refactor before green. Stop if code has no test.

+ - Apply `principle-scope-fence`: the plan authorizes exactly its named changes. Do NOT change acceptance tests or invent files/directories absent from the plan. Record concerns but satisfy tests as written.

- Apply `skills/principle-scope-fence/SKILL.md` — the plan authorizes exactly

- the change it names. The implementer's own bounds:

+ ## Blockers

- - **Do NOT change acceptance tests.** They are immutable. If a test seems

- wrong, document your concern but implement to make it pass as written.

- - **Reference real file paths from the plan.** Do not invent new files or

- directories that the plan does not specify.

+ 1. Record what is blocked, why, and the required unblocker.

+ 2. Continue only with dependency-safe unblocked slices.

+ 3. Revisit blocked slices after unblocked work completes.