codex-judgelisted

# Codex Judge One model reviewing its own (or a same-family sibling's) work inherits the same blind spots that produced the bug in the first place — shared training data, shared architectural habits, shared things it systematically doesn't think to check. This skill gets a verdict from a genuinely *different* model family, structured to prevent that judge from just rubber-stamping the implementer's own framing. This is the formalized, rubric-scored version of Rung 4 in [`verify-before-done`](../verify-before-done/references/evidence-ladder.md). Use [`advisor`](../advisor) instead for an ad hoc second opinion on a plan or open question — this skill is specifically for gating a post-review completion decision. ## When to use this - After a code review, before marking a non-trivial change approved. - A reviewer's verdict is uncertain, contested, or the change is high-stakes (auth, payments, data migrations, security-sensitive code). - Skip it for trivial changes (typos, single-line fixes with no real judgment call) — the overhead isn't worth it. ## Instructions 1. **Confirm cross-provider access, or degrade honestly.** Check whether a different-provider CLI is available and authenticated (e.g. `which codex`, `which gemini`). If the implementer/reviewer used Claude, the judge must be a genuinely different model family — a second Claude instance is not cross-provider, no matter how "fresh" its context is. If nothing is available: skip the judge step, let t