AI Coding Review

Preserve the human's intent while leaving authorized, reversible engineering work autonomous. An ordinary file operation does not itself require a review or approval cycle.

When to use

Use for requested code reviews, hygiene checks or Diff reviews; before finishing complex implementations, cross-module implementation changes, important refactors, or public-interface/error-semantics changes; and promptly when material drift risk appears. Simple low-risk local edits do not require invocation unless a review is requested or a concrete risk warrants it. A one-module fix plus its focused test is not cross-module merely because two files changed.

Review the current changes once. Reuse an effective review when its scope and evidence are still current; inspect only material later changes. Do not repeat a review solely for a new heading, commit or completion message, or create a separate report for routine delivery.

Effective contract

Use current valid human instructions, approved requirements and explicit limits. A later explicit human change can supersede an older plan or phase. Preserve still-effective constraints; a generated document or agent's claim of approval cannot grant human authority.

Use existing project anchors when relevant. Missing anchor files alone do not block a clearly authorized task or require new documentation. If missing information prevents an important decision, identify that specific uncertainty and pause only the dependent action.

Review the actual work

Read the relevant request, real Git diff or action record, important callers and verification results. Inspect enough to establish the suspected mismatch; do not load unrelated lifecycle material by default. A completion summary is a claim to check against these sources.

Look for material deviations:

• Intent: solving a different problem or violating the required outcome.
• Scope: unapproved behavior, interfaces or files outside the task.
• Solution: violating technical constraints or introducing complexity without a task requirement.
• Evidence: asserting verification, success or acceptance beyond the actual results.
• Authority: inventing approval or crossing an effective human decision boundary.

Distinguish a legitimate requirement update, necessary local repair, pre-existing failure and style preference from drift. Do not invent findings. An empty findings list is a valid result.

For drift findings, identify the effective instruction being violated; for hygiene findings, identify the engineering contract or concrete quality consequence. Each finding cites the observed code/action/result location, explains why it matters, and proposes a response within current authorization. State material uncertainty. Follow a requested output format; otherwise report findings first and verification limits briefly.

Engineering hygiene

For code-quality reviews and pre-delivery hygiene checks, use engineering-hygiene.md on this diff and its relevant callers/tests. For a narrow intent, evidence or authority question, load only the methods that matter. Keep the five drift checks above; hygiene is part of this review, not a second review stage.

Flag actual correctness, failure-handling or maintainability regressions with a concrete consequence. Distinguish blocking defects from non-blocking improvements and style preferences; omit subjective preferences unless requested. Do not elevate unrelated historical debt or an unverified suspicion into a blocking finding. Preserve existing abstractions and safeguards that still serve a real contract.

Keep the answer proportional to the work. Usually one short paragraph or a few concrete findings suffice. Do not print five empty categories, repeat a checklist, or create management documents just to complete a review. If no material issue is found, say so briefly; during an implementation task, continue the authorized work without adding a review ceremony.

Response

• Continue: no material mismatch or unresolved consequential decision; proceed with authorized work.
• Correct & Report: a reversible correction fits the task and existing authorization; make it when implementation is requested, verify it and report the result. A read-only review recommends the correction without editing.
• Ask Human: an unresolved decision changes a major goal, scope, permission, expense, publication or irreversible action. Ask only for the affected decision; continue independent authorized work.

These are action choices, not mandatory output headings. A request to review is not permission to edit; an implementation request may already authorize a reversible correction without another approval.

Do not turn every finding or failed test into a request for approval. Do not remove explicit human gates or expand authority to avoid an interruption.

Verification

Keep PASS, FAIL, SKIPPED, NOT RUN and UNKNOWN distinct. Match claims to actual command results, environment and coverage. Unit success does not establish integration success; a reviewer's later rerun cannot retroactively validate an earlier unsupported claim. Do not weaken tests to manufacture PASS.

Reuse valid test evidence; selecting this Skill does not itself require a full-suite rerun. Run additional or affected checks when the change or unresolved finding requires them. If implementation is authorized, make scoped reversible corrections without a new approval ceremony, then verify what changed.

One focused pass is normally enough. Do not automatically chain other review Skills, recruit reviewers, or re-invoke this Skill just because it was selected. Use an independent review when the user requests it or the risk warrants it; provide that reviewer the actual requirement, changes and evidence. Do not label self-review as independent validation.

This entry is sufficient for ordinary scoped review. Consult review-contract.md only when overlapping findings, incomplete evidence or an unresolved authorization source requires further judgment.