Code Review

code-review

Registry Trigger

Use when

• review code for defects regressions contracts security performance maintainability readability structure quality side effect pollution weak signatures change locality cleanup debt

Do not use when

• no task-local code review decision is required

Skill Role

Inspect a bounded code change for correctness, contract preservation, security and reliability effects, test adequacy, maintainability, and actionable findings. Exclude implementation and release authority.

High-Value Rules

• Resolve the review surface. Identify the Current Task Boundary, latest diff, all changed files, and reachable caller, consumer, sibling, or configuration impact before judging local lines.
• Trace consequential paths end to end. Follow input, validation, authority, state mutation, external effect, failure, cleanup, and observable output far enough to test whether the change preserves its claims.
• Check invariants and boundary behavior. Inspect missing, invalid, denied, duplicate, concurrent, partial, stale, timeout, cancellation, and rollback outcomes that are reachable for the changed mechanism.
• Verify APIs and assumptions from source. Confirm symbols, signatures, versions, defaults, configuration, framework behavior, and generated contracts rather than accepting plausible names or comments.
• Evaluate proof against the failure mechanism. Require focused evidence for the changed behavior and consequential negative outcomes; broad green status or coverage alone does not close an unexercised risk.
• Classify relation before severity. Use current-task for accepted repair, scope-blocker for Main-to-analysis routing, or non-blocking adjacent with residual risk and a next step.
• Preserve analysis decisions. Caller, consumer, sibling, and configuration reads are evidence without repair authority; findings cannot redefine Brief decisions or write scope.
• Separate defects from optional improvement. Report behavior, safety, contract, or maintainability risks that affect the change; keep style preference and unrelated redesign outside the blocking verdict.

Anti-Patterns

• Review only edited lines while indirect consumers, configuration, generated code, or side effects carry the real regression.
• Raise speculative findings without a reachable path, violated contract, or falsifiable consequence.
• Accept a large refactor, mock-only proof, retry-to-green result, or suppression as evidence that the named defect is absent.

Stop Conditions

Escalate when the review surface is unresolved, critical behavior or authority is externally owned, runtime semantics are unavailable, or a consequential path lacks admissible evidence. Also escalate when the change crosses security, privacy, money, destructive data, public compatibility, concurrency, or production reliability boundaries that need specialist review.

Output Contract

• bounded review with inspected surface, contract and path evidence, actionable findings, consequence-based severity, proof limits, and non-blocking improvements

Targeted References