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. Use 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 the reviewer's verdict stand alone, and say explicitly "judge: unavailable" in your report. Don't silently drop this step.

2. Build the judge's input — and withhold what would bias it. Give the judge:

   • the task spec / acceptance criteria
   • the diff itself
   • the reviewer's structured verdict and findings
   • automated check results (tests, lint, types) if available

   Do not give it: the implementer's reasoning, self-assessment, or any narrative explaining why the change was made a certain way. That narrative is exactly what anchors a judge toward agreeing with the implementer instead of evaluating the artifact on its own terms. See references/judge-prompt-template.md for a ready-to-use prompt built around this constraint.

3. Invoke it headlessly, with a fully self-contained prompt. The judge call has no access to this conversation — everything it needs must be in the prompt (rubric, diff, verdict, requested output format). Run it via whatever CLI is available (e.g. codex exec "$(cat judge-prompt.txt)") and capture the structured response.

4. Score against this rubric — four dimensions, 1–5 each:

   Dimension	What it measures
   Correctness	Does the change actually do what the spec asked, including edge cases?
   Security	Any new vulnerabilities, unsafe patterns, or weakened guarantees?
   Maintainability	Is the result clear, structured, and sustainable — not just working?
   Spec compliance	Does it satisfy the acceptance criteria, not a narrower interpretation of them?

   Ask the judge for an overall_score (aggregate 1–5) and a list of any critical violations (security holes, data loss risk, silently broken behavior) separate from the numeric score — a violation can sink an otherwise-high score.

5. Apply the decision matrix:

   Score	Critical violation?	Verdict	Action
   ≥ 4	No	PASS	Auto-approve
   ≤ 2	—	REJECT	Auto-revise (spawn a fixer)
   any	Yes	REJECT	Auto-revise, regardless of score
   = 3	No	NEEDS_REVISION	Reviewer's verdict is the tiebreaker

   If the judge and reviewer flatly conflict outside this matrix, prefer the reviewer when the disagreement is about code-context nuance the judge couldn't see (it only got the diff, not the live codebase); prefer the judge when it's flagging something the reviewer's own verdict didn't address at all.

6. Report the verdict with the evidence, not just the label. State the per-dimension scores, any critical violations found, and which action follows — don't just say "judge approved it."

Reference files

• references/judge-prompt-template.md — the self-contained prompt to send the second-provider CLI, including the requested structured output format.