cross-model-reviewlisted

# Cross-Model Review A fresh-context critic of the SAME model shares the author's blind spots; a different model family does not. Use cross-family review as the gate on load-bearing merges; a same-model critic (delegation-and-review §3) is the floor beneath it. **Load-bearing** = a defect would be trusted or propagate downstream: auth/payment/data-deletion paths, a published interface or release, gates/doctrine later sessions obey (this pack's hooks and skills). A routine feature diff or copy tweak is not — the same-model floor covers it. Observed once (2026-07, this pack's own work): after one model family reviewed and its findings were fixed, a second family reviewing the same pack still found further confirmed defects the first pass left behind (five in the hooks, one in a skill). Sequential passes over a changing tree — so this shows a second lens catches residue the first missed, NOT a measured "independent blind spots" rate (the trees differ, so non-overlap is partly by construction). It motivates the discipline; it does not prove a number. ## 1. Pick reviewers at session time — never hard-code a lineup Model lineups drift; a slug written into a rule is wrong within a release. Everything here is a rule about *how to choose*, never *what to choose*. - **Discover per account.** Candidate reviewer CLIs come from the project's own record (its instructions/memory) or a single ask to the user — the pack ships no list and you never invent one; confirm each is installed