Looper review method

Read this file, then read every always-required referenced file below before reviewing. Read on-demand references only when their trigger matches the changed set.

Do not treat skill selection as a scope reduction: if no specialty skill matches, still complete the base review using this looper-review method. Apply the disposition schema, publish split, and repair-frontier contracts from the Looper reviewer prompt; this skill does not restate those execution contracts.

Procedure

1. Understand stated intent from the PR seed, title/body, linked spec, and stated goals/non-goals.
2. Enumerate in-scope changed files/ranges with local Git at the seeded base/head SHAs. Do not shrink that set because a specialty skill matches.
3. Read the surrounding context needed to judge each change (callers, tests, contracts, lifecycle).
4. For large PRs (roughly ≥15 changed files, or changes that cross packages), write an internal related-file plan grouping interface/impl/callers, db/readers, and prod/tests. Stay one reviewer; do not spawn sub-agents or subtasks.
5. Establish concrete evidence for each independent in-scope finding: implementation trigger → code path → wrong consequence, or spec/docs section/omission → ambiguity or contradiction → implementation/validation consequence. Investigate uncertain candidates and omit unsupported claims from published findings. Group only the same root cause; keep unrelated concerns separate.
6. Run a counterexample pass on those evidence-backed candidates in the same context before finalizing. The authority for dropping a candidate is that same review context (diff, callers, tests, contracts), not the agent's first structured finding list. Drop an evidence-backed candidate only when evidence proves it factually wrong or a same-root-cause duplicate. A missing reproduction is not disproof; static evidence can establish a finding.
7. Deliver the existing disposition schema from the Looper prompt (must_fix | follow_up | needs_human, severity, scopeBasis, scopeEvidence). Write comments that meet the quality bar in the reference files.

References

Always read:

• Comment quality
• Evidence and counterexamples
• Implementation review rubric
• Spec/docs review rubric

Read on demand:

• CSS linting — when the change set includes CSS parsing or linting logic, including Go, TypeScript, or other non-style implementations. Do not require a CSS or style file in the changed set. Ordinary CSS-only edits do not need this fixture-matrix guidance.