Implementation

The user's instructions take precedence over this skill; carry existing authorization forward, finish the work within scope, and do not add approval gates.

Orient to the Change

Before editing, inspect status and existing diffs on touched files; the checkout is shared space, so never run autofix across other agents' work. Trace behavior through actual callers and consumers. Find the nearest existing instance of the pattern in the repository, and any prior work in project memory, before building new structure; name it. Search by syntax for structure and by text for names. Recheck volatile API and dependency claims against current primary evidence. "Why does this happen?" calls for a confirmed cause first, then a check that distinguishes broken from intended behavior.

Select a Verifiable Slice

Keep implementation and verification together. File count and edit count are not cadence rules. Run the cheapest check that can expose the next likely failure before building on it.

Keep the Design Accountable

Judge the concepts and contracts, not line count: an abstraction can earn its place before a second caller when it enforces a real boundary. Remove imports and dead branches your own change creates. Route unrelated findings to the sidequest or issue workflow; do not absorb them silently.

For a scale problem, identify the contended resource and fix isolation, indexing, batching, ownership, or capacity at the cause. A temporary concurrency reduction must not quietly become permanent.

Record the Calls the Request Did Not Make

The request is a map and the repository is the territory. Where they disagree (an edge case the request never mentioned, a constraint the user treats as obvious, two readings that produce different work), the call made there is where a run most often diverges from the result the user wanted, not the code around it. Make the call, record the alternative and the reason, and carry the record into the wrap and the handoff. When the readings differ materially and the work after the call depends on the answer, ask once with the pick stated before building on it; otherwise state the reading taken and continue. A silent call is the failure; a question at every call is the other one.

Verify the Claim You Intend to Make

Preserve exit codes and raw failure logs; a pipeline into tail can hide a failed command, and do not impose arbitrary timeouts on a check to make it finish. A filter selecting zero intended tests does not verify the change. Cached results are legitimate when their inputs match, but disclose them. A useful receipt names the command, revision or working-tree state, environment, exit status, and what actually ran.

Check the Consumption Boundary

Check the invariant, not merely that the command succeeded. A valid selector can match nothing, a package can build without files the importer needs, and a merged fix can leave the deployed artifact unchanged.

Detectors and guards need positive and negative evidence. Performance changes need a baseline, a representative workload, and the relevant resource measurements. For a surface you cannot observe or a live check you may not run, give the human a discriminating procedure and expected result; do not invent a screenshot or verdict.

Recover by Updating the Hypothesis

Classify a failure before editing again (environment, stale artifact, invocation, shared-output race, runtime defect). Preserve the original error and find the first failing dependency instead of fixing downstream symptoms. Repeating variations without new evidence is the signal to reframe, regardless of attempt count. The same applies to review rounds: when findings keep landing in one class, restructure or cut the mechanism rather than patch it again, keep the larger head on a backup ref, and file the hardening separately.

A failure on the base can show that a symptom predates the change; missing changed filenames in a trace cannot. A successful rerun does not establish harmless flakiness. Detailed procedures live in references/recovery.md.

Self-Review Before Requesting Review

A careful reviewer's first round often lands in a few recurring classes. For each class the diff touches, the check costs minutes before review and a round after it.

Most of these end as code changes once a reviewer raises them, so they belong before the review request, not in the description. Answer every inline thread before merge, with a reason when the answer is no change. Mixed-version behavior during deploy and the other questions a reviewer asks of the body are in super-good-pr.

Review and Commit Coherent Work

Follow the project's commit policy and commit verified logical chunks. Stage explicit owned paths or hunks and inspect the staged patch. At a commit checkpoint, compare the total diff to the task; green tests can coexist with unnecessary scope. Push and merge authority comes from the user, not this skill. The git skill covers shared-index handling.

Obtain independent verification when consequence or run length justifies it (shared or production state, an unattended run past a checkpoint, an acceptance check the implementer cannot alter) or when the project contract requires it. When none of those triggers applies, do not spawn a verifier to double-check a small change you can verify in a handful of tool calls. The verdict must arrive from a separate dispatch, because a model rarely corrects an error sitting in its own reasoning. Use cross-model-review when available; a different model exposes blind spots but does not eliminate correlated errors. Tie the verdict to the reviewed state, and report incomplete review as incomplete.

Preserve the State and Finish

At handoff or compaction, preserve the original outcome, user corrections, changed paths, revision, checks run, unresolved findings, the calls made where the request was silent, and next step. Sweep for processes this session started before reporting done. Reinspect status on resumption.

Evidence and References

Read references/benchmarks.md when interpreting benchmark or workflow claims. Read references/recovery.md for CI triage, intermittent failures, and incident recovery.

Reviewed 2026-09-04 and 2026-10-27; sources and their limits are in references/evidence.md.

Anti-Patterns

What This Skill is NOT

• A fixed sequence, edit budget, mandatory research phase, or agent quota.
• Permission to change adjacent code, bypass approvals, or claim unrun checks.
• A replacement for understanding the actual implementation and its consumers.