# Codex Judge

> Gets an independent, cross-provider score on a code review verdict — a different model family than the one that implemented or reviewed the change, scoring correctness/security/maintainability/spec-compliance from the diff and the reviewer's verdict alone, never the implementer's reasoning, and gates auto-approve vs. auto-revise on the score. Degrades gracefully when no second provider is available. Use after a code review and before approving anything non-trivial, or when a review verdict feels uncertain or contested.

- Skill: `jsvillalbat/codex-judge` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jsvillalbat/codex-judge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jsvillalbat/codex-judge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: jsvillalbat (https://skillmd.com/u/jsvillalbat)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jsvillalbat/codex-judge

---


# 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 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.