sjinks/review-skills

Use when a concrete defect, incident, review finding, failing test, or bug report suggests equivalent defects across a locked scope. Audit sibling fields, paths, modes, contracts, tests, docs, and projections. Excludes greenfield work, broad initial reviews, formatting-only changes, and isolated typos.

Use when planning fixes for supplied review findings: cluster evidenced shared causes, choose root-cause versus symptom-level fixes, and order a fix batch with explicit dependencies. Planning only; excludes finding discovery, validity decisions, implementation, and post-fix approval.

Use when: assessing what a proposed fix or patch could newly break before it is pushed, tracing fix impact through callers, shared state, and contracts, checking whether a fix regresses other resolved findings, or attaching a verification step to each impact risk of a fix.

Use when: structuring a multi-lens review of a change, spec, design, or implementation; combining intent, design, implementation, security, adversarial, and verification perspectives, then synthesizing them into a single integrated decision.

Use when: deciding whether a pull request, diff, or change set is too large or mixed to review in one pass, splitting an oversized PR into reviewable slices, separating refactor from behavior change or mechanical from semantic edits, or planning stacked or sequential PRs for a large change.

Use when: auditing your own change before requesting review, running a pre-review or pre-PR self-check, checking diff hygiene, leftover debug code, commented-out code, unrelated changes, missing tests for changed behavior, commit atomicity, PR description accuracy, or repeated templated edits applied consistently across files before opening or updating a pull request.

Use when: enforcing review-fix cycle quality gates, verifying review findings are closed, checking merge readiness, validating fix evidence after a review round, deciding go/no-go on merge, auditing unresolved or reopened review threads, confirming regressions introduced by fixes are tracked, and producing a final pre-merge gate decision.

Use when: resolving a stalled disagreement between reviewer and author in a code review thread, classifying a review dispute as fact versus standard versus preference, anchoring a dispute to a verifiable source, or applying a decision rule to end review-thread ping-pong.

Use when: writing, rewriting, or auditing code review findings, review comments, or PR feedback for quality: severity tag, evidence anchor, concrete expected fix, and an explicit acceptance condition, so each finding is actionable and closable without extra clarification rounds.

Use when: making one review round complete instead of incremental, enumerating review dimensions up front, covering every file under each applicable dimension, declaring review coverage and uncovered dimensions, or preventing new findings on unchanged code in later review rounds.