Deliver Code Change

Deliver Code Change

Implement and verify one bounded outcome. This skill owns execution, not multi-stage planning, architecture decisions, or unfamiliar-codebase exploration.

Entry and exit gates

Use this skill when one bounded implementation outcome needs coordinated editing and verification because its behavior, consumers, uncertainty, or acceptance evidence are material. Keep ordinary exploration, review, trivial documentation or formatting, and localized obvious reversible edits in the direct workflow. A risk keyword or file category alone does not select this skill.

If this skill was already selected for such an edit, use the Fast route, load no supporting reference without a concrete uncertainty, and create no planning or persistent-state artifacts.

Use phase-step-planner before implementation for multiple independently accepted outcomes or persistent phase state. If product or architecture decisions remain unresolved, stop and return the required decision, viable options and tradeoffs, affected contracts, and smallest safe temporary boundary.

Execution contract

Before editing:

1. Read applicable repository instructions, inspect Git/current changes and relevant implementation, and preserve unrelated work.
2. Confirm one outcome, its consumers, expected behavior, file or module boundary, and acceptance evidence.
3. Choose Fast, Standard, or High-risk; risk overrides diff size.
4. Plan only to that route's depth.
5. Implement the smallest coherent change.
6. Verify with repository-native evidence.
7. Follow applicable authority rules; selecting a route grants no additional permission.

Source diffs, raw command output, test results, and inspected runtime behavior are evidence. Generated reports and assumptions are not.

This skill may edit code and required tests and validate the result. It must not define requirements, redesign unrelated components, create engineering processes, or silently widen scope.

Phase-managed work

Do not infer phase control from nearby files. Before loading phase resources, confirm that this request implements, resumes, or advances one identified non-terminal phase, whose STATUS and current STEP govern the requested outcome and boundary. If authority is absent, use a non-phase route; if authority exists but the boundary fails, stop and return the conflict. Only after this gate:

• read references/phase-handoff.md;
• run the validator named by repository instructions;
• treat the verified STEP as the complete implementation boundary;
• implement only its approved outcome.

The repository-named validator is authoritative. Do not bypass a failure using a bundled validator, manual digest, inferred compatibility, or silent artifact repair. Stop before editing when the handoff is not executable.

The executor must not modify phase status, create STEP files, expand file or side-effect boundaries, redefine acceptance, approve its work, or define the successor. Return evidence to the planner.

Route selection

Choose exactly one route after the direct-edit gate:

A one-line authentication or permission change is High-risk.

• Fast: keep only a short internal checklist and normally load no reference.
• Standard: track implementation steps, affected areas, and verification.
• High-risk: identify invariants, failure modes, recovery strategy, and acceptance evidence before editing.

Implementation

For Standard and High-risk work, read references/implementation.md. For High-risk work, also read references/risk-controls.md.

Inspect definitions and consumers, follow repository conventions, and implement established decisions with a minimal compatible diff. Stop when the outcome would require a new requirement, architecture decision, or wider boundary.

Verification

For Standard and High-risk work, read references/verification.md, then only a matching references/toolchain-*.md when it adds useful repository-specific commands. Fast work normally runs its focused repository-native check directly.

Prefer existing scripts, CI commands, and test frameworks. Do not install missing tools automatically. Classify every relevant check:

• PASS: executed and satisfied its criterion;
• FAIL: executed and found a defect;
• BLOCKED: could not execute because a dependency, credential, service, or permission was unavailable;
• NOT_APPLICABLE: does not apply.

Never convert skipped, assumed, or blocked checks into PASS, and do not claim unit tests prove external integration behavior.

Persistent state and handoff

Do not create persistent task state by default. It is justified only for cross-session work or interruption recovery when no project mechanism exists. Then read references/recovery.md, use one explicit path, and never create a second state file beside an applicable phase STATUS.md.

The final handoff reports:

1. outcome and files changed;
2. verification commands and classified results;
3. assumptions and skipped or blocked checks;
4. remaining risks and required user actions.

For phase-managed work, also report boundary compliance, deviations, and evidence for planner review. Do not mark phase acceptance, update STATUS, or define next steps.

Resources and final rule

Applicable Global and repository safety, Git, and authority rules remain in force. This skill and its route selection grant no additional authority.

Read supporting material only when its condition applies:

Use scripts/detect_project.py only when repository shape or toolchains remain unclear. Use scripts/check_python_contracts.py only for an explicit supported Python contract. Scripts supply evidence, never permission or wider scope.

Higher-priority repository instructions win. Prefer the smallest correct change and report rather than silently crossing the agreed boundary.