---
name: implement
description: Execute the planned code change with the smallest coherent diff and run the relevant validation. Use when source, tests, or behavior must change. Do not use for planning-only or docs-only tasks.
---
## Use when
- code, tests, or config must change
- a bug fix needs a repro and validation
- a planned change is ready to execute

## Do not use when
- the task is still exploratory and needs planning first
- the work is docs-only
- the task is purely release-note or final-gate work

## Inputs
- agreed goal or plan
- touched files and invariants
- canonical repo commands

## Outputs
- files changed
- reason the change is correct
- tests or validation run
- skipped checks and residual risk
- gate status for the applicable delivery checks

## Success criteria
- the diff is minimal and follows local patterns
- validation matches the blast radius
- the result is ready for docs and final review

## Mandatory gates
Treat these as the default delivery state machine for this skill.

### G0 - Instruction gate
Required: always.

Pass when:
- the full applicable instruction chain has been read
- conflicting guidance has been resolved by precedence
- deeper local overrides are checked before editing

### G1 - Command gate
Required: always.

Pass when:
- canonical commands are identified from repository evidence
- guessed or substituted commands are not used
- validation scope is selected before code changes

Block when:
- commands are still guesses
- the validation plan relies on toolchain assumptions rather than repo evidence

### G2 - Schematic gate
Required: every non-trivial task.

Pass when a change schematic exists and answers:
- where the behavior starts
- what modules or layers change
- how data or state moves
- what contracts or invariants must stay true
- what side effects, failure modes, or rollback concerns exist

Block when:
- the change crosses layers without an explicit reason
- the intended ownership of logic or state is unclear
- contract changes are implicit rather than named

### G3 - Implementation gate
Required: every code change.

Pass when:
- the source of truth is changed instead of generated output
- the diff is minimal and coherent
- public behavior is preserved unless intentionally changed
- comments, names, and abstractions reflect domain intent
- unrelated refactors or formatting churn are excluded

Block when:
- generated files are hand-edited despite a generation path
- unrelated cleanup is mixed into the fix
- control flow, naming, or abstractions make the changed behavior harder to understand

### G4 - Validation gate
Required: every code change.

Pass when:
- relevant tests are added or updated where practical
- the smallest meaningful checks ran during iteration
- validation depth matches blast radius
- unrun checks are explicitly called out with residual risk

Block when:
- no evidence supports the claimed behavior
- failing checks are ignored or hidden
- assertions were weakened to make tests pass

### G5 - Clean-code gate
Required: every non-trivial task; strongly recommended for every code change.

Pass when the changed code is:
- cohesive: each changed unit has one obvious reason to change
- schematic: a reader can follow the top-level flow without hunting through indirection
- explicit: side effects, state transitions, and failure paths are visible
- low-friction: naming is precise, branching is controlled, nesting is shallow
- non-duplicative: repeated logic is removed or consciously justified
- typed or structured: avoid stringly-typed control flow, magic values, and boolean-flag APIs when better structure exists
- testable: seams are clear enough to validate behavior without fragile setup

Block when:
- a unit mixes parsing, policy, orchestration, I/O, and persistence with no clear separation
- hidden temporal coupling or ambient state is introduced
- complexity rises materially without necessity
- dead code, debug prints, broad catches, or TODO debt remain in changed paths without explicit tracking

### G6 - Security / privacy gate
Required: when trust boundaries, permissions, external input, network access, secrets, tenancy, or file handling change.

Pass when:
- changed trust boundaries are reviewed
- misuse cases are considered
- sensitive data handling remains safe
- validation covers the risky path

Block when:
- the change weakens authorization, validation, or data protection
- secrets or sensitive data could leak
- external input is trusted without adequate parsing, encoding, or verification

### G7 - Docs / contract gate
Required: when behavior, API, CLI, config, schema, examples, or migrations change.

Pass when:
- user-facing or contract-facing docs are updated
- examples and configuration references match the new behavior
- migration or rollout notes are included when needed

Block when:
- a behavior or contract changed but docs, examples, or config did not

### G8 - Handoff gate
Required: every non-trivial task.

Pass when the final handoff includes:
- what changed
- why it changed
- change schematic
- commands run and outcomes
- commands not run
- gate status
- residual risk, waivers, or follow-ups

Block when:
- evidence is missing
- skipped validation is concealed
- material risk is not disclosed

### G9 - Instruction-eval gate
Required: when changing repository instructions, skills, or custom agents.

Pass when:
- routing behavior was checked with a small prompt set
- at least one negative trigger case was included
- any required output contract or schema was verified
- tool scope and least-privilege settings were reviewed where applicable

Block when:
- instructions changed with no routing or behavior check
- a skill description remains vague enough that triggering is unreliable
- a specialist gained broader tools than its role needs without justification

## Routing
Calling this skill means execute this agent chain in order:
1. clear G0 and G1 before editing
2. clear G2 before any non-trivial implementation
3. split the requested change into independent implementation scopes only when ownership is clean
4. record owned scope for every spawned agent in the handoff
5. spawn one `implementer` per scope only when those scopes are disjoint and can be edited safely in parallel
6. merge the implementation outputs into one result
7. run `test-engineer`, `clean-code-reviewer`, and `reviewer` only when needed by gates or risk
8. merge their findings into one review summary
9. resolve any blocking findings and verify G3 through G8 before the skill completes
10. if repository instructions, skills, or custom agents changed, also clear G9 before completion

Do not emulate this chain in one thread. If any required subagent cannot be spawned, stop and report the skill as blocked.
If docs changed, call `docs` after this skill completes.
If the task is still unplanned, call `plan` before this skill.
