Code Review Pass

Review, consolidate, remediate, verify. Keep every distinct finding visible, but verify it before changing code. Respect the user's target, write scope, resource limits and integration permissions. Do not infer permission to commit, stage, push, post comments, create worktrees or provision runners.

1. Freeze the target

State the target: PR, commit, merge-base range, staged changes, or current working tree. Default to the working tree only when no other target was supplied. Read applicable project instructions and inspect existing changes before writes.

When evidence-file writes are permitted, use scripts/collect-changes.sh from the repository, with an approved durable output directory outside the repository or under an already-ignored directory. Set SKILL_DIR to the directory containing this SKILL.md and REVIEW_OUTPUT to an approved, existing durable artifact directory. Invoke the script by its path inside this skill:

bash "$SKILL_DIR/scripts/collect-changes.sh" --output-dir "$REVIEW_OUTPUT" working
bash "$SKILL_DIR/scripts/collect-changes.sh" --output-dir "$REVIEW_OUTPUT" staged
bash "$SKILL_DIR/scripts/collect-changes.sh" --output-dir "$REVIEW_OUTPUT" commit <sha>
bash "$SKILL_DIR/scripts/collect-changes.sh" --output-dir "$REVIEW_OUTPUT" range <base>..<head>
bash "$SKILL_DIR/scripts/collect-changes.sh" --output-dir "$REVIEW_OUTPUT" pr <number-or-url>

The helper uses Git, plus gh only for GitHub PRs. It captures a diff and target identity without changing the index, branches or checkout. If the helper is unavailable or artifact writes are not permitted, use equivalent read-only host tools and report the same identities and limitations without creating files. No changes means stop; collection failure does not mean a clean review.

Inspect relevant complete files, callers and contracts at the reviewed revision. A historical/PR diff does not prove the current checkout contains those bytes. Read immutable blobs or use an already-authorized matching checkout; ask before switching the user's tree. Refresh the snapshot if its target changes.

2. Run the two lenses

Read both self-contained role briefs before dispatch:

• Best practices reviewer: design, duplicated knowledge, ownership boundaries, clarity and project idioms.
• Senior code reviewer: correctness, regressions, contracts, concurrency, persistence and production risks.

These briefs are portable prompts, not requirements for registered agent types. When independent delegation is available and permitted, use two separate native review contexts. Pass each its own brief, the exact root/revision/diff, relevant instructions, evidence gaps, and a read-only assignment. Do not share the other lens's conclusions before both return. Inherit the user's model choices; no particular model, vendor, tool name or terminal manager is required.

If delegation is unavailable or disallowed, perform both lenses sequentially and label them as one agent's two passes, not independent reviews. Never skip a lens. Restrict reviewer tools to read-only operations where the host supports it; the coordinator owns approved remediation. Reviewers do not recursively launch teams.

3. Consolidate and rule

Keep one finding ledger, deduplicated by mechanism and location, ordered by severity: blocker, high, medium, low, nit. For each entry record:

ID · severity · category · file:line
Problem: concrete defect or violated project convention, with evidence
Consequence: failure scenario or maintenance cost; confidence/unknowns
Remedy: principled correction and required scope
Disposition: confirmed / fixed / rejected-with-reason / needs-decision
Verification: regression control or other relevant check

Include actionable low-priority items and nits; do not manufacture style findings or delete disputed findings silently. Judge actual contracts and language idioms, not arbitrary size limits or pattern preferences. Resolve conflicting reviews from source and tests. Hypotheses are questions to investigate, not automatic fixes.

4. Remediate within authority

For an authorized review-and-fix request, address every confirmed in-scope finding, including nits. For review-only, return the findings without edits.

Name necessary refactors; prefer the correct seam, type or ownership model over a workaround that preserves a defective shape. A substantial refactor can be within scope; size alone does not make it forbidden. Ask for a ruling when the remedy expands ownership, changes an agreed contract or requires an unapproved migration/ rollout decision. Continue unrelated authorized fixes while awaiting that decision.

Do not hide defects with weaker tests, blanket suppressions, unsafe casts or silenced errors. Legitimate boundary narrowing, deliberate recovery and explicit compatibility requirements remain valid; follow the project's actual rules. Preserve other contributors' edits and avoid opportunistic repository-wide cleanup.

5. Verify and close

Use the project's real quality gates, affected scope, exact flags and authorized runner. Witness behavior-changing regressions fail without the fix and pass with it where feasible; distinguish environment failures from product failures. Do not bypass hooks or reinterpret a blocked check as passing.

Refresh the change-set after fixes. Recheck both lenses on affected code, and repeat while concrete in-scope findings remain. Stop for missing authority, unavailable infrastructure, scope drift or budget limits; report what remains. Do not chase endlessly changing personal preferences or claim convergence without an actual final review. Substantive later edits invalidate affected witnesses.

Report fixed findings, rejected findings with reasons, unresolved decisions, remaining risks and exact verification results. State whether reviews were independent. Leave changes unstaged/uncommitted unless separately authorized; “clean review” does not mean the Git working tree has no changes.

For maintaining this skill, use references/validation-cases.md. No client-specific trigger detector or automatic launch of paid agents is required.