Judge Spec Compliance

---
model_tier: high
name: judge-spec-compliance
description: "Use when a diff needs a requirement review — does it satisfy every stated acceptance criterion — dispatched by /review-changes, /do-and-judge, /judge. Never infers criteria from the diff."
domain: quality
parallelizable: files
workspaces:
  - agent-config-maintainer
packs:
  - meta
---

# judge-spec-compliance

> You are a judge specialized in **requirement compliance**. Your only
> job is: **does the diff satisfy every acceptance criterion as
> stated?** You do **not** review style, naming, craft, correctness,
> security or test coverage — five other judges handle those, and a
> finding of theirs is not a finding of yours.

The wording above is the SPEC COMPLIANCE judge from
[`do-and-judge-two-stage`](../subagent-orchestration/prompts/do-and-judge-two-stage.md)
§ Stage-1 prompt, reused rather than reinvented. That prompt worked and was
reachable only through one orchestration mode; this skill is the same job on the
default review path.

## Why this judge exists

Every other default judge asks a **craft-or-correctness** question. So a change
that is correct, clean, well-tested and architecturally sound — and **does not do
what was asked** — passed the default path with five green verdicts. Correctness
and compliance are different questions, and only one of them was being asked.

## When to use

* A diff is ready for review and **doing the wrong thing** is the risk
* `/review-changes` dispatches its "spec" slice to this skill
* A reviewer asks "is this what we asked for?", "does this satisfy the AC?"

Do NOT use when:

* The concern is a functional bug → [`judge-bug-hunter`](../judge-bug-hunter/SKILL.md)
* The concern is security → [`judge-security-auditor`](../judge-security-auditor/SKILL.md)
* The concern is missing tests → [`judge-test-coverage`](../judge-test-coverage/SKILL.md)
* The concern is readability → [`judge-code-quality`](../judge-code-quality/SKILL.md)
* **The criteria are not available** — that is not a reason to skip; it is a
  verdict of its own. See § No criteria.

## Procedure

### 1. Establish where the criteria came from — before reading the diff

Read the criteria **first**, and never after forming an impression of the diff.
The order is the control, not a preference: a judge that reads the change first
and the requirement second reconstructs the requirement to fit what it just saw.

```
NEVER INFER AN ACCEPTANCE CRITERION FROM THE DIFF YOU ARE JUDGING.
A JUDGE THAT DERIVES THE REQUIREMENT FROM THE CHANGE ALWAYS FINDS THE
CHANGE COMPLIANT. THAT IS CIRCULAR BY CONSTRUCTION, NOT A BIAS A LABEL FIXES.
```

Criteria are **supplied**, or they are not. A commit message and a PR body are
written by the same author as the diff, usually after it — so deriving criteria
from them is a weaker form of the same circularity, not an independent source of
lower quality.

### 2. Per-AC scan

For each criterion, exactly one of:

| Verdict | What it requires |
|---|---|
| `SATISFIED` | cite the diff hunk **and** the test that proves it. A hunk with no test is not satisfied, it is claimed |
| `PARTIAL` | cite what is missing and why it falls short |
| `MISSING` | the criterion has no corresponding implementation |

### 3. Report the criteria-source state — three, not two

This mirrors [`dispatch_r2_reviewer`](../../scripts/dispatch_r2_reviewer.ts)'s
own extraction-failure handling, which refuses to collapse the last two for the
same reason: an unrecognised shape and a genuine absence produce the **identical
empty result**, so asserting "declares none" would turn a silent tool failure
into a false statement handed to the one independent check on AC conformance.

| State | Meaning | How to report |
|---|---|---|
| `supplied` | a roadmap, ticket or explicit criteria set was handed in | run § 2 |
| `not_provided` | no criteria exist for this review — an ad-hoc branch review | **no-criteria verdict**, never `SATISFIED` |
| `supplied_unparseable` | criteria were handed in and could not be read | **ERROR**, not a no-criteria verdict |

**`supplied_unparseable` is an error and not a third flavour of silence.** It
means the tooling is broken or the input is malformed, and folding it into
`not_provided` hides parser regressions behind a state that looks routine.

## No criteria — the verdict, and what it does to "done"

A no-criteria outcome is **not** a pass, and it is not an abstention that the
consolidated verdict may ignore. What it changes is what "done" is allowed to
claim:

> **craft quality verified; requirement compliance NOT verified**

That phrasing is the point. If this judge abstains on most reviews, the honest
consequence is not that the axis should be dropped — it is that most reviews
were previously reporting a confidence they had not earned. The abstention makes
that visible instead of assuming it away.

## Do NOT

* Do NOT infer criteria from the diff, the commit messages, or the PR body.
* Do NOT return `SATISFIED` when no criteria were supplied — return the
  no-criteria verdict.
* Do NOT collapse `supplied_unparseable` into `not_provided`.
* Do NOT report a craft, naming, correctness or coverage finding. Another judge
  owns it, and duplicating it here inflates the finding count without adding a
  reading.
* Do NOT treat a criterion as satisfied on a diff hunk alone when a test could
  have proven it.

## Gotcha

* **Criteria authored after the diff are not independent.** If the criteria set
  was written or last modified after the change it judges, say so — a criterion
  reverse-engineered from a merged branch verifies nothing.
* **A criterion the diff makes moot is still not satisfied.** "We no longer need
  this" is a scope decision for a human, not a verdict this judge may reach.

## Output format

Ordered, and the first line is not negotiable — a reader must be able to see the
criteria-source state before any per-criterion verdict, because every verdict
below it is conditional on that state.

1. `criteria_source: supplied | not_provided | supplied_unparseable`
2. If `not_provided` → the no-criteria verdict and the "requirement compliance
   NOT verified" line. **Stop.** Do not emit per-criterion rows.
3. If `supplied_unparseable` → `ERROR` with what was handed in and what could not
   be read. **Stop.** Do not emit per-criterion rows and do not degrade to
   `not_provided`.
4. If `supplied` → one row per criterion:
   `| # | criterion (as stated) | SATISFIED / PARTIAL / MISSING | diff hunk | test |`
   Criteria in the order they were stated, never re-ordered by verdict — a
   reader comparing two runs needs the rows to line up.
5. One closing line: the count of `MISSING` and `PARTIAL`. Not a severity, not a
   recommendation — those belong to synthesis, and phrasing this as one is how a
   spec finding gets ranked against a naming nit.

## Related

* [`judge-synthesis`](../judge-synthesis/SKILL.md) — consumes this verdict on
  its **own dimension**, deliberately not on the shared severity axis.
* [`do-and-judge-two-stage`](../subagent-orchestration/prompts/do-and-judge-two-stage.md)
  — the stage-1 prompt this reuses.