/implement

name: implement
description: 'Make the code change a ticket or bug report asks for, then prove it with the repo''s own checks. Use when: told to fix, change or build something, such as "fix this bug".'
practices:
- tdd
- refactoring
- small-batch-flow
hexagonal_role: driving-adapter
consumes: []
produces:
- subject-manifest.v1
output_contract: 'content identity, author context ID and check facts through the native handoff; subject-manifest.v1 at the judgment boundary'
context_rel:
- kind: customer-of
  with: plan
skill_api_version: 1
user-invocable: true
metadata:
  graph_root: true
  tier: execution
  dependencies: []
  capabilities: [execute_one_experiment, collect_factual_evidence]
  effects: [modify_declared_subject, derive_subject_manifest]
  canonical_status: canonical
  disposition: keep
  triggers: ["execute the next wave", "per-lane evidence", "fix this bug", "CI is red", "loosen the assertion"]

Implement

Implement the accepted outcome. Repair ordinary known defects directly. Use the existing intent; a clear edit needs no Plan first. An incoming report nobody has accepted yet goes to [Triage](../triage/SKILL.md) first. Implement owns source changes and factual checks.

Rules that decide the result

• **Fix the cause, not the oracle.** Never loosen an assertion, tolerance,

golden, fixture or suppression, or substitute a mock or placeholder, to turn a check green; nor change what the check runs against: code that acts differently under test or CI, a newly silenced failure path, or a check made non-blocking or skipped. A check that fails against accepted behavior points at a product defect; changing what the check accepts is an acceptance change and needs caller authority.

• **Find live consumers before editing.** Search the callers, readers, scripts,

docs and tests of every edited function, type, path, format or message. For each one, state whether the change affects it and which check covers it. When retiring or renaming, consumers include installations, lookups and old-name invocations; preserve historical provenance. If the replaced interface never merged or shipped and every consumer update fits the scope, update them and delete the old version in the same change, with no alias or shim; otherwise keep the old version working or report it.

• **Name discriminating checks.** A behavioral change preserves RED

for the expected missing behavior: name the check that fails before the edit and passes after ([Test's proof rule](../test/SKILL.md#critical-constraints)), plus the check for each affected consumer.

• **Report only what ran.** Give exact commands and results. List every check

you did not or could not run as not run. Never call unrun work verified, fixed or green. Output can show as soon as a command runs, so keep secrets out when you build it: credentials stay in the environment, output that may carry tokens goes to a file, and only redacted excerpts are shown.

When changing a public failure path, preserve its native failure signal and check that its recovery advice matches any work already performed. For uncertain write outcomes or unattended callers, use only the relevant checks in [Test's error recovery method](../test/references/error-recovery.md).

For an accepted bounded shortcut, review feedback or a defect your change introduced, an authorized commit, history rewrite or merge conflict, dependency upgrade, removal, blocked operation, a decision read from another tool's state or your own uncertain write, use only the matching [change safety method](references/change-safety.md). These methods preserve existing authority; they grant no new operation.

For authorized service operations, load only the relevant procedure from [operations methods](references/operations.md) (reliability, delivery, incident recovery, resilience, toil); ordinary edits owe no operations phase.

Workflow

1. Read intent, acceptance, scope and repository boundaries before the first write; reuse loaded contracts. [RPI boundaries](../rpi/references/boundaries.md) apply when RPI is selected; caller-selected episode tracking follows the [session association reference](../orchestrate/references/session-associations.md#work-to-session-associations). Note the revision and files already modified, staged or untracked; report only your own as changed, and ask the caller before editing one holding others' edits. 2. Carry the accepted behavior examples forward unchanged. Use repository domain names in symbols and tests; check observable outcomes through the relevant interface. Run the smallest applicable check before and after editing. Pure refactors, relocations or docs may have an honest green baseline. Prefer existing tests or small discriminating probes. 3. Make the smallest in-scope change. When repairing discovery or checks, preserve the consumer's existing input selection; fixing an error path does not authorize a wider scan. Use a negative control when exclusion matters. Check a representative change against existing constraints before bulk propagation, and the authored source set before broad regeneration. A scripted edit across files first confirms that each anchor matches exactly once; on zero or several matches, write nothing and re-derive it. Repair known failures directly and verify the exact result with a check; a repair does not start another review. A disproved assumption may change the approach within scope; use Plan only for consequential uncertainty. 4. Read the repository's actual check recipe, including instrumentation and environment, rather than reconstructing it from memory. Run targeted tests and lint/static checks before broad integration, and required full checks at integration. Reuse exact-input receipts only while source, tool and relevant environment match. Neither bypass required hooks nor replay a check just to rename its receipt. A required CI job'