← ClaudeAtlas

independent-reviewlisted

Domain-agnostic cross-model review gate: run a planning markdown (PLAN gate) or a branch/PR diff (DIFF gate) through INDEPENDENT external reviewers via scripts/independent_review.sh — the standard pair (Codex + your signed-in ollama-cloud model) runs automatically; Antigravity/Gemini only on explicit opt-in, its credits are scarce. Consolidates a ranked BUG/RISK/NIT list and BLOCKS until every BUG is fixed, refuted, or owner-deferred (only a BUG the change did not introduce), and every RISK/NIT is fixed, refuted, or owner-waived; first use runs a guided onboarding wizard. Use BEFORE building from any non-trivial plan, BEFORE merging any non-trivial PR, and whenever asked for a "codex review", "gemini review", "antigravity review", "agy review", "adversarial review", "cross-model review", "independent review", "get a second model to review", "review before I merge", "which review tool should I use", or to "set up AI code review" / "set up codex, ollama, or antigravity for review".
karero/website-builder · ★ 4 · Code & Development · score 74
Install: claude install-skill karero/website-builder
# Independent review — the cross-model gate A blocking review gate for two artifact types. The value is *independence*: a model that did not write the artifact, ideally from a different model family, cannot share the author's blind spots. Dogfooded on its own design plan — two rounds caught 5 BUGs the author had shipped. ## The two gates - **PLAN gate** — reviews a planning markdown *before* any code is written. Catches strategy errors, stale assumptions, internal contradictions. - **DIFF gate** — reviews a branch/PR diff *before* merge. Catches test blind spots: a guard passing while the thing it protects regressed. ### "It's only a docs row" is the wrong test — ask what the reader will DO (Codified 2026-08-03 after a single session sent five MRs through this gate and **every one came back with something real**, including two where the defect was in the artifact's *proposed fix* rather than its description.) The instinct that a BUGLOG row, a ledger row, or a runbook is "too small to review" is about the artifact's SIZE. The thing that matters is whether someone will later ACT on it without re-deriving it. A deferred-bug row's "suggested fix" field is a **delegated instruction**: months later, an implementer reads it, trusts it, and builds it. It is simultaneously the field the author reasons about least (the bug is already understood; the fix is an afterthought) and the one the reader trusts most. That asymmetry is where the defects were: - A row said "add the mis