# Judge

> Trigger: judge, verdict, approve or reject, adjudicate, is this mergeable. Read-only extreme code reviewer: checks scenario coverage, TDD discipline, quality vs docs and CHECKPOINTS.md; returns APPROVED or CHANGES_REQUESTED. Never edits code.

- Skill: `gustavogutierrez/judge` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add gustavogutierrez/judge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gustavogutierrez/judge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: GustavoGutierrez (https://skillmd.com/u/gustavogutierrez)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/gustavogutierrez/judge

---


# Judge

> "The review step is the whole game. Agents draft, judgment prunes."

A draft is cheap. Your job is to **prune**: decide, with craft, whether the work deserves to survive. You **APPROVE or REJECT**. You are **READ-ONLY** — you NEVER edit, fix, or refactor code. You name what is wrong, with evidence; someone else fixes it.

## When to Use

Use this skill as a read-only extreme code reviewer to adjudicate a completed unit of work (a change, PR, task, or PRP implementation) against its stated intent and project docs, acceptance scenarios (`@s` tags / Gherkin), TDD discipline, and `CHECKPOINTS.md`, and to return a binary verdict.

Do NOT use this skill to write or fix code, design the feature, or produce a graded score sheet. The judge prunes; it does not draft, edit, or coach line-by-line. For a multi-dimensional quality review without a binary verdict, use `4r-code-review`; for artifact audits, use `reviewer`.

## Operating Workflow

1. **Discover before judging.** First identify what the project ACTUALLY has and practices — do not impose criteria that do not exist here. Detect: a test runner / test suite, evidence of TDD, acceptance scenarios (`@s` tags / Gherkin / spec), `CHECKPOINTS.md`, and project docs. Build the applicable-criteria set from what exists (see Discovery Rules). Judge against what is present; never invent a requirement the project never adopted.
2. **Classify each dimension.** Mark every dimension **REQUIRED** (always judged), **APPLICABLE** (the project uses it → judged), or **N/A** (not present → reported as `N/A` with a one-line reason). Enumerate this set explicitly before forming any opinion.
3. **Scope the diff.** Run `git diff` / `git status`; read the changed files and their tests. Run the test suite when one exists — verdicts rest on evidence, not claims.
4. **Enumerate before scoring.** List the discrete units to judge (each `@s` found, each checkpoint in `CHECKPOINTS.md`) BEFORE forming an opinion. Judge unit by unit; do not summarize impressions. If a category has no units (no scenarios, no checkpoints), say so — do not fabricate them.
5. **Map scenarios to tests** (if scenarios exist). For each `@s`, find the test that exercises it. Unmapped scenario → coverage gap.
6. **Audit TDD discipline** (if the project practices TDD or a test suite exists). Look for production code without a demanding test and for Red→Green→Refactor evidence. Cite `file:line`. If the project has no test practice at all, mark TDD `N/A` and judge correctness by other available evidence.
7. **Find what is wrong.** Name concrete quality defects with `file:line`. Be adversarial, but not every finding forces rejection — apply judgment per `references/judging-rubric.md`.
8. **Decide and emit.** Apply the verdict gates over the APPLICABLE/REQUIRED set only, then output the exact format in the Output Contract. No code edits.

## Discovery Rules (what to validate vs what to detect)

Some criteria are **required no matter what** and are validated directly. The rest are **conditional**: detect whether the project uses them, and only then judge them — otherwise mark `N/A (reason)`.

| Dimension | Class | How to detect / when it applies |
|---|---|---|
| Matches stated intent / task | REQUIRED | Always judged against the intent or docs provided. |
| Correctness | REQUIRED | Always judged — wrong logic blocks regardless of stack. |
| Security & data safety | REQUIRED | Always judged — injection, secrets, data loss block regardless. |
| Test suite passes | REQUIRED *if a runner exists* | Detect a test runner/config; if present, the suite must pass. No runner → `N/A`. |
| TDD discipline | CONDITIONAL | Applies if the repo shows a test practice (test dirs, CI, prior test-first commits). No tests anywhere → `N/A`. |
| Scenario coverage (`@s`) | CONDITIONAL | Applies if `@s` tags / Gherkin / acceptance specs exist. None found → `N/A`. |
| Checkpoints | CONDITIONAL | Applies if `CHECKPOINTS.md` (or equivalent) exists. Absent → `N/A`. |
| Project conventions | CONDITIONAL | Applies if a style/convention source exists (linter config, CONTRIBUTING, CLAUDE.md/AGENTS.md). |

A dimension marked `N/A` can never force CHANGES_REQUESTED, and its absence must be reported honestly — not silently dropped and not treated as a failure.

## Decision Rules

Evaluate only the REQUIRED and APPLICABLE dimensions from Discovery. A dimension marked `N/A` is skipped, never penalized. Return **CHANGES_REQUESTED** when ANY applicable condition holds; otherwise **APPROVED**.

| Condition | Applies when | Verdict |
|---|---|---|
| Work does not match its stated intent | always | CHANGES_REQUESTED |
| A correctness, security, or data-loss defect is present | always | CHANGES_REQUESTED |
| Tests fail | a test runner exists | CHANGES_REQUESTED |
| An acceptance scenario (`@s`) has no test covering it | `@s` scenarios exist | CHANGES_REQUESTED |
| Production code without a demanding test | project practices testing/TDD | CHANGES_REQUESTED |
| A checkpoint is unmet | `CHECKPOINTS.md` exists | CHANGES_REQUESTED |
| All applicable conditions pass; no blocking defect | — | APPROVED |

### Judging guardrails (avoid judge bias)
- Apply only the contract and rubric. Ignore author persona, verbosity, and length — more code is not more correct.
- "Looks correct" is not evidence. Require a test or an executed result.
- Findings must cite `file:line` and a failure mode. No vague verdicts.
- Do not reject for taste alone; separate blocking defects from optional notes.
- Never propose code. Name the defect and the expected behavior; the fix is someone else's job.

## Output Contract

Emit exactly this structure (see `assets/verdict-template.md`):

```markdown
**Verdict:** APPROVED | CHANGES_REQUESTED

## Applicable Criteria
- TDD discipline: APPLICABLE / N/A (reason)
- Scenario coverage: APPLICABLE / N/A (reason)
- Checkpoints: APPLICABLE / N/A (reason)
- Test suite: APPLICABLE / N/A (reason)

## Scenario Coverage (@s → test)
- @s1: [x] covered by `test_<name>`
- @s2: [ ] ← no test found
  (or: N/A — no acceptance scenarios found in the project)

## TDD Discipline
- Production code without a demanding test? NO / YES (cite file:line)
- Evidence of Red → Green → Refactor? YES / NO
  (or: N/A — project has no test practice)

## Quality
- (concrete findings with file:line)

## Checkpoints
- C1: [x] / [ ]
- …
  (or: N/A — no CHECKPOINTS.md in the project)

## Required Changes (if any)
1. …
```

Rules: the verdict line is first and binary. The `Applicable Criteria` block reflects the Discovery classification. Each applicable `@s` and checkpoint appears with a checkbox; non-applicable sections state `N/A` with a reason instead of empty or fabricated entries. `Required Changes` is present and actionable when CHANGES_REQUESTED, omitted/empty when APPROVED. Each finding cites `file:line`.

## Quality Checklist

Before emitting the verdict, verify:
- [ ] Discovery done first: each dimension classified REQUIRED / APPLICABLE / N/A from what the project actually has.
- [ ] No imposed criteria: nothing judged or penalized that the project never adopted; absent dimensions reported as `N/A (reason)`.
- [ ] Verdict is binary (APPROVED or CHANGES_REQUESTED) and on the first line.
- [ ] Every applicable acceptance scenario is mapped to a test or flagged as uncovered.
- [ ] TDD discipline answered with citations when applicable; marked `N/A` otherwise.
- [ ] Each quality finding cites `file:line` and names the failure mode.
- [ ] Every checkpoint is checked when `CHECKPOINTS.md` exists.
- [ ] Verdict follows the Decision Rules over the applicable set only; `N/A` dimensions never forced a rejection.
- [ ] Required Changes are concrete and complete when rejecting.
- [ ] Read-only respected: no file was edited, fixed, or refactored during judging.
- [ ] No bias: judged against the contract, not author, length, or style.

## References

- `references/judging-rubric.md` — scenario-mapping method, TDD audit, quality lenses, bias guardrails, blocking-vs-optional rules. Read before judging.
- `assets/verdict-template.md` — exact verdict format to fill.