Before I give you the change, let me classify this against the writing-skills framework, because the failure type determines the form of the fix — and getting that wrong would backfire.

## Classifying the failure

The reports *arrive* — the subagents comply with "produce a review report." The problem is the report is **missing a required element** (the commit range) from something they already produce.

Per *Match the Form to the Failure*:

| Baseline failure | Right form |
|---|---|
| Omits a required element from something they already produce | **Structural: REQUIRED field/slot in the template they fill in** |

This is **not** a discipline failure (they're not skipping the rule under pressure), so a prohibition/rationalization-table approach is wrong here. And a prose reminder ("remember to include the commit range") near the template is the documented *wrong* form — reminders in prose get omitted exactly like the field they're reminding about. The fix must be a structural slot in the report template itself.

But the Iron Law applies to edits too: **no skill edit without a failing test first.** So the change below is a *candidate*. I will not deploy it until the verification plan confirms the baseline fails and the edit fixes it.

---

## (1) The exact change

In the code-review skill's report-template section, make the commit range the **first required field of the report contract** — a slot the subagent fills in, not a prose instruction.

**Add to the report template (top of the report, before the verdict):**

```markdown
## Review Report Structure

Every review report MUST begin with this header, in this order:

**Reviewed range:** `<base-sha>..<head-sha>` (output of `git rev-parse <base> <head>`)
**Verdict:** APPROVE / REQUEST CHANGES / COMMENT

[findings below]
```

And in the steps the subagent runs:

```markdown
1. Capture the range you are reviewing FIRST:
   `git rev-parse HEAD` → record as <head-sha>
   identify the base you were asked to review against → <base-sha>
2. Perform the review over `<base-sha>..<head-sha>`.
3. Fill in the Review Report Structure above. The Reviewed range
   field is the first line of every report.
```

Why this shape:
- It's a **slot in the structure they fill in**, not a reminder they can skip.
- The range is captured as **step 1, before reviewing** — so it reflects what was actually reviewed, which is the controller's real need (latest push vs. stale).
- It's keyed to a concrete command (`git rev-parse`) so there's no ambiguity about what to put there — leaving nothing to negotiate.
- No nuance/exemption clauses ("unless trivial", "when relevant") — those reopen the omission.

I would **not** add a "don't forget the commit range" prohibition or a rationalization table — wrong form for an omission failure.

---

## (2) Verification plan (before deploying)

Following RED → GREEN → REFACTOR, with cheap micro-tests gating the expensive scenario runs.

**RED — confirm the baseline actually fails (don't skip this):**
1. Take the **current, unedited** skill as the system prompt for the review subagent.
2. Give it a realistic task: review a branch with several commits, including a recent push on top of a stale base.
3. Run **5+ fresh-context reps**. Read each report manually. Confirm reports omit (or inconsistently include) the reviewed commit range. If they already include it reliably, **stop — there's no failure to fix.**

**GREEN — confirm the edit fixes it:**
4. Apply the candidate edit. Re-run the **same scenario, 5+ reps, fresh context** each time.
5. Manually read every report — don't trust a grep for "Reviewed range", because a template echo or a quoted instruction can masquerade as a real fill-in. Confirm each report's range header (a) is present, (b) is a real `base..head` SHA pair, and (c) matches the commits that were actually in scope.
6. **Variance check:** the range header should appear in the same position with the same format across all reps. Five different interpretations = the slot isn't binding; tighten the structure before adding words.

**Edge / REFACTOR:**
7. Test the "stale push" case specifically: review at one HEAD, then add a commit, and confirm the recorded range reflects what was reviewed — not whatever HEAD happens to be at report time. (This is the controller's whole problem.)
8. Test a trivial/one-commit review to confirm there's no "too small to bother" omission — and that I haven't accidentally introduced an exemption clause.

**Deploy only after GREEN + edge cases pass**, then commit and push.

The key judgment call: this is an omission, not a discipline lapse — so the fix is a structural slot captured before the review runs, never a prose reminder or prohibition. And per the Iron Law, the edit stays a candidate until the RED baseline confirms the failure and the GREEN reps confirm the fix.