Implement

Implement

End-to-end workflow for taking MCP work items from queue to PR. This skill composes the schema-driven planning (spec-quality), implementation, review (review-quality), and git/PR workflow into a single pipeline.

Usage:

• /implement <item-id> — work on a specific item
• /implement — with context about what to work on
• Can process single items or multiple items in batch

Step 1 — Assess the Work

Load the item(s) and determine the execution tier and interaction mode.

For each item, call get_context(itemId=...) to understand:

• Current role and gate status
• Schema tag (feature-implementation, bug-fix, etc.)
• Existing notes already filled
• Dependencies and blocked status

When the user or an item references a PR or commit as already landed, verify its merge state before relying on it — gh pr view <n> --json state,mergeCommit plus git log origin/main — and confirm the working tree is current (Step 2, base-freshness precondition) before any pass that checks whether a change is present in the codebase.

Execution tier — classify by this table (canonical source shared with the task-orchestrator:orchestrate skill; edit the fragment, not this copy):

<!-- BEGIN GENERATED:tier-classification | source: claude-plugins/task-orchestrator/_fragments/tier-classification.md · regen: node claude-plugins/task-orchestrator/_fragments/generate.mjs -->

Force-UP signals (bump tier regardless of file count):

• Database migration → min Delegated
• New public API surface → min Delegated
• Multiple independent work streams → Parallel
• User says "let's plan" / collaborative language → min Delegated

Force-DOWN signals:

• User says "just fix it" / "quick" → Direct (unless complexity contradicts)
• Schema tag is default or absent → eligible for Direct

<!-- END GENERATED:tier-classification -->

Delegated with ≥2 ready items, or Parallel → run /task-orchestrator:run-wave.

If the item has no schema tag, apply quick-fix for Direct tier or leave untagged for Delegated/Parallel (the default schema catches these).

Trait application on classification. When the tier resolves to Delegated or Parallel and the workspace defines a delegated trait (it appears in availableTraits on create responses), apply it before any dispatch — traits: "delegated" at item creation, or manage_items(operation="update", items=[{itemId: "<uuid>", traits: "delegated"}]) for an existing item. This makes the orchestrator-filled delegation-metadata note schema-visible instead of convention-only. Direct tier: do not apply it — nothing is delegated.

Model-selection traits. Seat dispatch defaults come from the delegated trait (planner opus, implementer sonnet, test-author sonnet, reviewer opus). Override them per item, at the same point:

• complex-implementation — implementer on opus. Apply for architecture-heavy or multi-file synthesis work: new public API, cross-layer seams, subtle state machines or concurrency.
• high-stakes — planner and reviewer on fable. Apply sparingly, where a wrong plan or a missed review finding is expensive: security predicates, auth, data-loss paths, hard-to-reverse design decisions. Fable draws on its own usage bucket, so it is never a default. needs-security-review does NOT imply it.

Read the resolved per-seat profile from get_context / query_items(operation="schema") (dispatchBySeat) and pass its model explicitly on the dispatch.

Test-author trigger rule. bug-fix.default_traits already includes needs-test-author — no action needed, it applies automatically. For feature-task items, apply needs-test-author per item (manage_items(operation="update", items=[{itemId: "<uuid>", traits: "needs-test-author"}])) when acceptance criteria involve a predicate, algorithm, parser, validator, or state transition, or when any force-ON signal is present: new public API surface, a database migration, a security predicate, or a prior vacuous-test finding in this item's area. Other schema tags (feature-implementation, plugin-change, quick-fix, and the global floor) do not carry the trait. Direct tier: apply the trait only in its temporal-only degraded mode, and only on bug-fixes — the test-plan gate and red-first rule still apply, test-manifest declares a single actor, and there is no separate test-author dispatch. Other Direct-tier items are exempt regardless of the criteria above — the tier is too small to separate authorship into a second dispatch.

Interaction mode — orthogonal to tier:

When processing multiple items, evaluate whether related items (e.g., bugs in the same module, fixes that touch the same files) should be grouped into a single branch and PR. Group when the changes are cohesive and independent fixes would create merge conflicts. Keep items separate when they're unrelated or when isolation makes review cleaner.

Step 2 — Prepare the Branch and Worktree

Sync local main before any implementation begins.

git checkout main
git pull origin main --tags

Base-freshness precondition. Before creating any branch or worktree, and before any source-verification pass (a grep or file read that decides whether a change is present), confirm the intended base is current:

git fetch origin
git log --oneline -1 origin/main
git rev-parse --short HEAD

The two SHAs must match, or HEAD must be a descendant of origin/main on the intended branch. A source-verification pass must never run against a working tree that has not been confirmed current — this includes the orchestrator's own session worktree. If the tree is behind, read the file directly from the remote (git show origin/main:<path>, from PowerShell on Windows — the Bash tool's MSYS layer mangles the ref:path colon) or create a fresh worktree from origin/main (fallback block below). A stale base manufactures absent-looking evidence and absence reads as a discovery, not an error: a 6-commit-stale tree reported four already-adopted proposals as missing (2026-08-04), and a one-commit-stale dispatch re-implemented existing runtime into a conflicting 17-file commit (2026-05-01) — trend 760be80d.

The branching/worktree strategy depends on tier:

Direct tier (orchestrator implements 1–2 files inline) — create a working branch on the main directory:

git checkout -b <branch-name>

Delegated tier (single subagent) — same as Direct: orchestrator creates the branch on the main directory, the subagent works against it. No worktree.

If the main checkout is unavailable (another branch checked out, uncommitted changes present) or the orchestrator itself runs from a worktree — Direct and Delegated tiers both: do not touch the occupied checkout. Create a dedicated worktree instead:

git worktree add .claude/worktrees/<slug> -b <branch-name> origin/main

Work there using absolute paths and git -C (never cd); after the PR merges, remove the worktree and delete the branch. Sync local main via git fetch origin main:main while main is not checked out anywhere, or a normal git pull from the main checkout when it is.

Parallel tier (parent feature with multiple children) — create a single feature worktree that all child agents share:

FEATURE_SLUG=<short-feature-description>          # e.g. issue-117-followup
FEATURE_BRANCH=feat/$FEATURE_SLUG
FEATURE_WORKTREE=.claude/worktrees/feat-$FEATURE_SLUG

# Resume detection — if the branch/worktree already exist (orchestrator restart
# mid-feature), reuse them rather than recreating:
if git show-ref --verify --quiet "refs/heads/$FEATURE_BRANCH"; then
  echo "Resuming existing feature branch $FEATURE_BRANCH"
else
  git branch "$FEATURE_BRANCH" main
fi
if [ ! -d "$FEATURE_WORKTREE" ]; then
  git worktree add "$FEATURE_WORKTREE" "$FEATURE_BRANCH"
fi

All child-task agents will be dispatched into this shared worktree (Step 4). The feature branch is pushed and PR'd once, when the parent feature reaches terminal (Step 6).

Plan file as dispatch contract (3+ children). For every Parallel-tier run, instantiate references/dispatch-contract-template.md into the wave's plan file before the first dispatch, fill every placeholder, and have every Step 3, 4, 4b and 5 dispatch prompt reference it under the template's conflict rule instead of restating design or process details per prompt. The template states the rules; this table only says what each slot is for — do not paraphrase a slot's rule into a prompt. Under /task-orchestrator:run-wave, the Header and File ownership rows are filled from the planner's explain output plus the planner-v1 stage's own returns rather than hand-typed, and the run reuses this same worktree by passing --mode shared --worktree $FEATURE_WORKTREE --branch $FEATURE_BRANCH — the contract file and its slot order are unchanged either way.

Write it to <main-checkout>\plans\<slug>.md and hand agents that absolute path, recorded once in the contract's Header Contract path line. The plans/ directory is gitignored, so it exists only in the main checkout and never in the feature worktree; a prompt that pins a worktree working directory and then names a relative plans/<slug>.md points at a path that is not there.

Two runs (retros 202b5d42, 6d562acb) produced zero vocabulary deviations across up to five concurrent authors this way, with prompts roughly 60% smaller. The delivery surface is itself the point (proposal 728a3e57 / #307): in a same-day controlled comparison, the wave with no contract file recurred every previously-adopted failure class, while the waves that ran from one held the gains — a rule that lives only in skill prose does not reach the agents, because agents read the dispatch prompt and their item's schema guidance. The contract guarantees deviation-free execution, not plan correctness — pair it with Step 3's "plans are spec inputs" rule so the plan's own factual claims are verified by the implementer rather than merely followed.

Why one worktree per feature, not per child: the feature is the natural PR boundary. Per-child PRs created cross-PR test contamination and PR-body staleness during the #117 follow-up (see retro a7f6024f). Shared worktree means one commit history, one CI cycle, one PR — and the parent feature's review-checklist gives a coherent point at which to finalize.

Branch naming:

• feat/<feature-slug> — feature-implementation parents (the integration branch)
• fix/<short-description> — bug-fix items (Direct or Delegated tier)
• fix/<grouped-description> — batch of related bug fixes (Delegated tier)
• chore/<short-description> — tech debt, refactoring (Direct tier)

Step 3 — Queue Phase: Planning

This step is tier-conditional:

Direct tier: Skip this step entirely. No plan mode. No queue-phase notes. Call advance_item(trigger="start") immediately to move queue→work. The quick-fix schema has no queue-phase required notes, so the gate passes. Exception: if the item carries needs-test-author (temporal-only degraded mode, Step 1), test-plan is a queue-phase note and must be filled before this advance — see the seat-timing rule below.

Delegated tier: Fill queue-phase notes per schema. Use get_context(itemId=...) to see expectedNotes and guidancePointer. Pre-plan-workflow is optional — use only if scope needs exploration. Post-plan-workflow only if child items need materialization. Advance: advance_item(trigger="start").

Parallel tier: Full planning pipeline:

Collaborative mode:

1. Tell the user the item is ready for planning and ask them to enter plan mode. The pre-plan-workflow and post-plan-workflow hooks fire automatically on plan mode entry and exit, handling context gathering and materialization.
2. During planning, follow the guidancePointer for each required note — this will reference the spec-quality skill where applicable.
3. After plan approval and post-plan materialization, advance the item: advance_item(trigger="start")

Autonomous mode:

1. Read and follow the pre-plan-workflow skill — gather existing MCP state, check schema requirements, and understand the definition floor.
2. Research the codebase — explore relevant files, understand current state.
3. Fill all queue-phase notes following the guidancePointer for each. The spec-quality framework applies regardless of mode.
4. Read and follow the post-plan-workflow skill — materialize child items if the plan calls for them.
5. Advance the item: advance_item(trigger="start")

The gate will reject advancement if required notes are missing. If rejected, fill the missing notes and retry.

Plans are spec inputs. Every file path, tool contract, or call sequence a plan names must cite its authoritative location and be verified on disk or in source before the plan is approved — child items' specification notes are generated from the plan and inherit its errors silently (spec-quality, "Cite Contracts, Don't Restate Them"). This reminder lives here because spec-quality is reached via note guidance pointers that plan mode does not traverse.

Do not confuse this with resource-lease contention. A queue→work advance_item can also fail with applied: false, errorCode: "resource_unavailable", errorKind: "transient" — a resource a trait on this item declares (resources:) is currently held by another item. This is not a note gate failure: filling notes will not fix it. Work a different item and retry later (retryAfterMs is a hint), or report the contended key(s) to the user.

Seat timing for needs-test-author items. The queue-phase test-plan note is filled by the planning seat — the orchestrator (Direct tier) or the plan author (Delegated/Parallel tier), invoking the test-author skill's scenario-derivation and oracle-derivation sections — and this happens before advance_item(trigger="start") moves the item queue→work. This is by design: test-plan gates work entry, the same way any other required queue-phase note does. This is a distinct seat from Step 4b's test author seat, which writes test code and fills test-manifest at work phase — see Step 4b's intro for the two-seat distinction.

Planning seat (Parallel tier, one opus agent per stream). Under /task-orchestrator:run-wave this becomes the run plan's planner-v1 stage — it mirrors the same eight fields below, dispatched by the run rather than by hand; the field table stays the semantics either way. Dispatch one opus agent per stream after child items are materialized (post-plan-workflow) and before Step 4's implementer dispatch — this is the concrete, per-stream instantiation of the planning seat named above. Inputs: the stream's diagnosis/task-scope note and the CURRENT codebase, not the plan text alone. Task: verify every claim in that note against source, citing file:line for each correction; write the note if materialization left it missing, or revise it if verification finds it wrong; fill and freeze test-plan per the seat-timing rule above; then return the structured template below instead of free-form prose. Give the seat the contract by its absolute path (Step 2's Contract path line) — never a relative plans/..., which does not resolve from the worktree — so it reads the Items and Conflict rule slots it is about to extend; its return is what fills the File ownership and Planning seat return template slots for the rest of the wave.

Structured return (eight fields, each required — none is a valid value):

The fields are the budget. The return may exceed any line budget when the fields have content — trimming a field to fit a target length is the failure this stage exists to prevent, not a virtue.

Evidence. This seat produced a material correction on 15/15 items across three bug waves (retros 1b8bba5a, cc69671b, 8e6a7cf7) — every wave that ran it found at least one diagnosis error, cross-stream overlap, or missing seam the plan had missed.

Step 4 — Work Phase: Implementation

Verification commands. Throughout this step, "run tests" means running BOTH the test suite AND the project linter:

./gradlew :current:test
./gradlew :current:ktlintCheck

CI enforces both — a green test run with failing lint will still block the PR. If ktlintCheck fails, run ./gradlew :current:ktlintFormat to auto-fix formatting violations, then verify with ktlintCheck again and re-run tests. Include both commands in every implementation-agent and review-agent prompt.

Who runs the lint cycle (proposal ee6f5d32, ~9 sessions of evidence):

• Delegated tier (agent owns gradle): the implementation agent runs the ktlintCheck → ktlintFormat → re-verify cycle itself before committing. Validated 2026-07-13 (PRs #213/#214/#215): zero orchestrator fix-up commits.
• Parallel tier: per-seat gradle ownership is stated once, in the dispatch contract's Compile self-check slot ("Who runs gradle"); this bullet only adds the lint-cycle detail that slot's table implies — agents get :current:ktlintFormat as part of their single pinned self-check, and the orchestrator additionally runs ktlintFormat before ktlintCheck after each commit batch (historically 3-5 fix-up commits per multi-phase run when skipped).

Capturing gradle's real exit code (use this pattern, not 2>&1 | tail -N). Piping gradle into tail discards gradle's exit code — tail always exits 0 on a successful read of the log, so BUILD FAILED at the end of the gradle output is reported by you as a successful run. Combined with gradle's daemon incremental cache, this can hide broken compilation through entire CI cycles (retro 568a8584: 9 silently-failing tests shipped on PR #151 before the followup audit caught it).

The reliable pattern, especially when running in run_in_background:

./gradlew :current:test > /tmp/gradle-out.log 2>&1; EXIT=$?
echo "EXIT=$EXIT"
tail -30 /tmp/gradle-out.log

Redirect ordering matters: use > /tmp/log 2>&1, NOT 2>&1 > /tmp/log — the latter is evaluated left-to-right and leaks stderr (where gradle writes compile errors) to the terminal instead of the log (retro ac25db89: a compileTestKotlin failure was invisible in the captured log until the ordering was fixed).

EXIT=$? captures gradle's actual exit code before any pipe consumes it. Read the captured exit code AND the tail of the log; never trust the tail alone. This applies to every orchestrator-owned gradle invocation throughout this step.

Agent-side gradle is not this pattern. In a Parallel-tier wave, agents get exactly one lock-serialized invocation, pinned verbatim — argument form included — in the dispatch contract's Compile self-check slot, together with the rule for what to do when it fails. Do not hand an agent an ad-hoc gradle command line; point it at that slot.

Use --rerun-tasks after dependency upgrades or large refactors. Gradle's incremental compile cache retains class files from prior good builds. After a gradle/libs.versions.toml bump or a refactor that changes public API surfaces (removed methods, renamed types, sealed-class arms, generic-parameter shifts), incremental compilation can keep the OLD class files alongside source that no longer compiles, producing apparent BUILD SUCCESSFUL on stale bytecode. Run ./gradlew :current:test --rerun-tasks once after such changes to force a clean run; ordinary incremental builds are safe afterwards.

This step is tier-conditional:

Direct tier: Implement directly. Edit the files, run the test suite. No subagent dispatch. No /simplify pass. Exception — a Direct-tier bug-fix carrying needs-test-author: follow Step 4b's Direct-tier test-first-then-fix sequence (test-plan frozen at queue → regression test observed red → fix → green) instead of implementing first. Fill the session-tracking note (required by both quick-fix and default schemas) with a brief summary of what changed and test results. Advance to review: advance_item(trigger="start").

Delegated and Parallel tiers: Use get_context(itemId=...) to see work-phase expectedNotes and guidancePointer values. Fill each required note following its guidance. Follow /task-orchestrator:orchestrate (model table, return formats, UUID inclusion). The key decisions at this step are:

• Single item (Delegated): delegate to one implementation subagent or implement directly. Subagent works in the main directory on the working branch.
• Multiple child tasks, independent (Parallel): dispatch parallel subagents into the shared feature worktree created in Step 2. Each agent receives the worktree path and branch name. Do not use isolation: "worktree" on the Agent tool — that would spawn a separate worktree per dispatch, which is the deprecated per-child PR pattern.
• Multiple child tasks, dependent: dispatch sequentially into the shared feature worktree. Wait for each agent's commit to land before dispatching the next.

Under /task-orchestrator:run-wave, both bullets above are executed by the run plan (Method A via Workflow, Method B via next-scheduling), reading each stage's dispatchBySeat entry for model/agent instead of the table below. The hand-dispatch form in this section and the template it points at remain the fallback for dispatches a run plan doesn't cover — a one-off fix agent, or an arbitration re-dispatch (Step 4b) — not the default path for a Parallel-tier wave.

Test-file ownership boundary. Every implementation dispatch (Delegated single agent or Parallel per-child agent) excludes src/test/** from scope — implementers do not create or modify test files. When a change surfaces a needed test update, the agent reports it in its return (or in implementation-notes) rather than editing the test itself; the test author (Step 4b) owns that file tree exclusively on items carrying needs-test-author.

Parallel dispatch into a shared feature worktree:

Agent(
  prompt="""
  Working directory: <feature-worktree-path>
  Branch (already checked out): feat/<feature-slug>
  Dispatch contract: <ABSOLUTE path from the contract's Header "Contract path" line, e.g.
  D:\Projects\task-orchestrator\plans\<slug>.md> — read it first; it wins on conflict with
  this prompt. It lives in the main checkout, not in the worktree above.
  Scope (modify ONLY these files): <explicit list> — the same list as your row in the
  contract's File ownership slot.
  Do NOT create or modify any file under src/test/** — test authoring is a separate,
  independent dispatch (Step 4b) on items carrying needs-test-author. If your change
  surfaces a needed test update, report it in your return; never edit the test yourself.

  Before returning: run the compile self-check exactly as the contract's "Compile self-check"
  slot pins it, and handle its outcome by that slot's rules. Then commit exactly as the
  "Commit discipline" slot states, including the post-commit verification.
  Do NOT run :current:test or :current:ktlintCheck — the orchestrator owns full build
  verification.
  """,
  model="sonnet",  // or dispatch.model when the item's resolved profile sets one — see "Model selection" above
  subagent_type="<dispatch.agent when the item's resolved profile names one, else general-purpose>"
  // NOTE: no isolation parameter — agents share the feature worktree
)

Why the prompt points at slots instead of carrying the commands: the self-check is fast (~3s) and catches type-mismatch / signature errors that gradle's incremental cache may otherwise mask in the orchestrator's later test run (retro 568a8584: H3's dbNow() shipped with a Result<T> vs Instant return type mismatch hidden for ~6 hours), and its ktlintFormat step is formatting-only and idempotent, preventing the recurring lint fix-up commits (proposal ee6f5d32). But the invocation's exact argument form, the foreign-file early exit and the retry bound only work if every agent gets them identically — six agents in one wave each burned three lock-serialized runs against another agent's mid-refactor file, and a re-typed nested invocation flattened a [string[]] argument (#302). A prompt that restates the command drifts from the contract; a prompt that points at the slot cannot. The same applies to the commit step: never tell an agent to "commit your changes with a descriptive message" in a shared worktree — the Commit discipline slot is the only safe form (#301).

File-edit overlap discipline: Parallel agents in a shared worktree must operate on non-overlapping files. The orchestrator scopes each agent's prompt to a specific file list (per MEMORY.md §"Parallel File-Edit Delegation"). When inherent overlap exists, dispatch sequentially.

Contract-change sweep discipline. When a child task tightens a contract — making a parameter required, adding validate() invariants, narrowing a sealed-class arm, or otherwise rejecting inputs that earlier passed — the orchestrator must sweep the rest of the codebase before advancing to review. Two recurrences (retros a7f6024f and 568a8584) showed that:

• Pre-existing test fixtures constructed under the old contract will fail under the new one. Example: H2's WorkItem.validate() claim-field invariants broke 8+ test fixtures that constructed mixed-state items via separate Instant.now() calls (microsecond drift) or partial claim fields.
• The failure typically surfaces on a different PR's merge commit, not the PR that introduced the contract change — the original PR's tests passed because they used the new contract correctly.

For each contract-tightening change in this run:

1. Identify the affected tool / class / method.
2. Grep all test files (and other call sites) for usages: grep -rn "<tool>\|<class>\|<method>".
3. Verify every usage is consistent with the new contract. Update any that are not.
4. Re-run the full :current:test suite (orchestrator-owned, not the agent) to confirm no fixture-vs-contract conflicts surfaced elsewhere.
5. Fixture repairs are orchestrator-owned and construction-only. When a fixture fails under the tightened contract, the orchestrator may adjust how the fixture is constructed (fix the stale call site) but must never adjust what it asserts. Anything that would touch an expectation instead of a construction call is not a fixture repair — re-dispatch the test author (this preserves the independence the trait exists to protect). Declare these commits in the review handoff: list each orchestrator fixture-repair commit's SHA alongside the impl-range/author-range pair (see Step 4's tracking table and Step 4b's disjointness check) so review-quality can tell a declared fixture repair apart from a silent implementer edit to src/test/**.
6. Doc-claims sweep after behavior-changing fixes: when an orchestrator-owned bug-fix changes shipped behavior after documentation was authored (e.g. a tokenizer or default flips mid-run), grep all changed docs for claims about the OLD behavior before finalizing (retro ac25db89: "case-insensitive" survived in 3 places after the fix made search case-sensitive).

This sweep is part of the orchestrator's verification step between waves, not the implementing agent's responsibility — agents are file-scoped and can't see the full fixture surface.

Model selection — always set model explicitly on every Agent dispatch. Under /task-orchestrator:run-wave, dispatchBySeat already resolves model per seat and this table is the fallback for dispatches the run plan doesn't cover:

Omitting model causes the agent to inherit the orchestrator's model (typically opus), wasting tokens on sonnet-eligible implementation work.

When dispatching an item's phase owner (implementer on work, reviewer on review), read the profile for the phase being dispatched INTO: if the orchestrator already called advance_item, its dispatch field already reports the profile for newRole; if the agent will enter its own phase (agent-owned-phase protocol — dispatched while the item is still in queue), get_context returns the queue profile, not work's, so read query_items(operation="schema", itemId=...)'s per-phase dispatch.work map instead. When that profile names an agent, dispatch with subagent_type = dispatch.agent. Regardless of whether agent is set, still pass model explicitly — dispatch.model if set, else the table above. effort has no Agent-tool parameter; in Claude Code it applies only through the dispatched agent's own frontmatter, so a profile's effort is advisory unless agent names a definition carrying that effort — to change effort, point agent at a definition with that effort.

After implementation agents return:

For Parallel-tier features, agents return having committed to feat/<feature-slug> inside the shared feature worktree. Record each agent's commit SHA range alongside the child's MCP item ID — this map feeds the ownership two-range check below and the dispatch contract's Review scoping slot, where reviews are diffed by owned file rather than by SHA range:

| Child UUID | Agent ID | Pre-SHA | Post-SHA | Test-Pre-SHA | Test-Post-SHA | Changed Files |
|------------|----------|---------|----------|--------------|---------------|---------------|
| <uuid>     | <id>     | <sha>   | <sha>    | <sha>        | <sha>         | <file list>   |

Capture pre-commit SHA before dispatch (git -C <feature-worktree> rev-parse HEAD) and post-commit SHA after the agent returns. In a shared worktree this range can interleave other streams' commits and misses later fix-ups, so use it to confirm ownership, not to bound a review:

git -C <feature-worktree> diff <pre-sha>..<post-sha> --name-only

Test-Pre-SHA/Test-Post-SHA are captured the same way around the test author's dispatch (Step 4b) and stay blank until that wave runs.

Disjointness check (required whenever needs-test-author applies). After both ranges are captured, verify:

git -C <feature-worktree> diff <pre-sha>..<post-sha> --name-only          # impl range
git -C <feature-worktree> diff <test-pre-sha>..<test-post-sha> --name-only # author range

• impl-range ∩ src/test/** = ∅ (the implementer touched no test files)
• author-range ∩ src/main/** = ∅ and author-range is non-empty (the author touched only test files, and touched at least one)

A violation is reverted (git -C <feature-worktree> revert the offending commit, or a targeted git checkout of the crossed-boundary file back to the prior SHA) and recorded in implementation-notes — do not silently keep a cross-ownership commit.

Step 4b — Test Authoring

Applies only to items carrying the needs-test-author trait. Runs after implementation agents return (their commits exist on the branch/worktree) and before the orchestrator's build verification below (Direct tier inverts this ordering — see the Direct-tier bullet below) — the test author compiles against the real implemented surface, not a predicted one. Two distinct seats, do not conflate them: the planning seat already froze test-plan at queue phase, before this step, gating work entry (see Step 3's seat-timing rule); the test author seat here writes test CODE and fills test-manifest — it does not fill or re-open test-plan.

Per-tier sequencing:

• Direct tier: temporal-only degraded mode only (see Step 1) — no separate agent, and on a bug-fix the sequence is test-first-then-fix, not "tests after implementation": (a) fill test-plan at queue phase, before any implementation begins; (b) write the regression test from the diagnosis note's reproduction steps and observe it red against the pre-fix code, recording the red evidence (assertion, observed value) in test-manifest; (c) implement the fix; (d) confirm the test is green post-fix and record that confirmation too. test-manifest declares the single actor, and the disjointness check above does not apply (one actor, one range) — see Step 5's verdict rule for how this tier is scored.
• Delegated tier: one additional sequential dispatch on the same branch, after the implementation agent's commit lands. The test author owns its own gradle cycle on that branch (ktlintCheck → ktlintFormat → re-verify, same rule as Step 4's "Who runs the lint cycle") and runs :current:test itself before committing.
• Parallel tier: one test-author agent per child, dispatched as a dedicated wave between the implementation wave and the orchestrator's build verification (below). Authors in this tier do NOT run :current:test or :current:ktlintCheck — only ktlintFormat plus a compile self-check, mirroring the implementation dispatch template, since the orchestrator owns full build verification for the wave.

Blindness rule. The test author may read: the item's test-plan note, public signatures, domain models, existing test conventions/docs, and the implementer's changed-file names (not content). The test author must NOT read: the implementation diff content, the implementer's own tests, implementation-notes, or session-tracking. This is what makes the separation real rather than nominal — tests probe the spec, not the implementation's behavior.

Oracle-provenance obligation. Every scenario's expected result must trace to a source declared in test-plan (spec clause, stated algorithm, external reference) — never "what the code returns" and never the ticket's own worked example.

Manifest duty. Before returning, the test author fills test-manifest (work, required): actor id, test file paths, commit SHA range, S-id→test coverage mapping (covered / not-covered:reason), probes executed with results, forbidden-pattern declaration (every assumeTrue/escape with justification, or none), and any implementer-modification-to-test-files rationale (should be none if ownership held).

Skill routing. Invoke the test-author skill before filling test-manifest — it carries the scenario-derivation, oracle-derivation, blindness, and forbidden-pattern framework this step depends on. (The planning seat also invokes it earlier, at queue phase, for the scenario-derivation sections that inform test-plan — see Step 3.)