The failure here is **omitting a required element from something they already produce** — the subagents reliably generate review reports, but those reports lack the commit range. Per "Match the Form to the Failure," this is NOT a discipline failure (they're not skipping the review under pressure) and NOT a shaping failure. It's a missing-element problem, so the right form is **structural: a REQUIRED field/slot in the template they already fill in** — not a prose reminder ("remember to include the commit range") and not a prohibition ("never omit the range").

But first — the Iron Law applies to edits too. I will not write the change and ship it. Below is the change I *would* make, then the test that must pass before it goes anywhere.

## (1) The exact change

In the code-review SKILL.md, locate the review-report template/output section and add a required slot as the **first** field of the report, so it's structurally impossible to fill out the template without it.

```markdown
## Review Report

Every review report MUST begin with this header, before any findings:

​```
Reviewed-Range: <base-sha>..<head-sha>   # e.g. a1b2c3d..f4e5d6c
Reviewed-At: <ISO-8601 timestamp>
​```

Obtain the range with:
​```bash
git log --oneline <base-sha>..HEAD   # confirm these are the commits you reviewed
git rev-parse HEAD                   # head-sha
​```

The base-sha is the commit the branch/PR started from; the head-sha is the
tip you actually read. If you reviewed only part of a range, report the
range you read — not the full PR range.
```

Why this form, not the alternatives:
- **A REQUIRED structural slot** in the template they fill in — matches "omits a required element from something they already produce."
- **Not a prose reminder** near the template ("don't forget to mention which commits") — those get skipped exactly the way the current reports skip it.
- **Not a prohibition** ("never submit a review without the range") — prohibitions backfire on omission/shaping problems; there's nothing to forbid, only a slot to fill.
- The slot is **first**, so an incomplete-but-submitted report is visibly missing its header rather than burying the gap.
- The "report the range you read, not the full PR range" line is a real exception expressed as a conditional on an observable predicate, not a nuance clause ("...unless it matters").

## (2) Verification plan before deploying

I have not seen this fail in a controlled way yet — I've only got a report of the symptom. I need RED before GREEN.

**RED — baseline, capture the real failure (and confirm there is one):**
1. Take a real-ish scenario: a branch with 2 commits, where a 3rd commit was pushed after review started (the stale-vs-latest case the controller described).
2. Dispatch the code-review subagent with the **current** skill (no change). 5+ fresh-context reps.
3. Read every report manually. Confirm the baseline failure: reports omit the commit range, or state it ambiguously. If the control reports the range fine, there's nothing to fix — stop.

**Micro-test the wording before full scenarios:**
4. System prompt = the *full* edited skill (the slot lives in its real context, not in isolation). User message = "review this branch." 5+ reps.
5. Score by reading each report: does the `Reviewed-Range` header appear, first, with two real SHAs from the scenario? Watch for false positives — template echoes (literal `<base-sha>`) and quoted examples masquerade as hits.
6. **Variance is the metric.** If reps converge on the same well-formed header, the slot is binding. Five different interpretations means it isn't — tighten the structure (e.g., make it a fenced block they must reproduce) before adding more words.

**GREEN — full pressure scenarios:**
7. Re-run the stale-push scenario with the edited skill. Add the controller's actual need: does a report let a controller distinguish "reviewed latest push" from "reviewed stale commit"? Verify the head-sha matches the tip they read, not blindly `HEAD`.
8. Edge cases: partial review (did they report the sub-range they actually read, per the conditional?); first commit on a branch (base-sha resolution); detached/rebased history.

**REFACTOR:**
9. Any new failure mode (e.g., agents pasting `<base-sha>..<head-sha>` literally, or reporting full PR range when they only read part) → tighten the slot, re-test until reps are consistent.

Deploy only after step 7–8 pass cleanly across reps. Then commit and push.