The failure you're describing is a classic **omitted-element** problem, not a discipline problem—so let me match the form to the failure before touching anything.

## Classifying the failure

The subagents already produce review reports. They're not skipping the review or violating a rule under pressure. They're leaving out one required piece (the commit range) from something they already generate. 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** |

So the fix is structural, not a prohibition ("never omit the commit range") and not soft guidance ("remember to include..."). Both of those backfire or get ignored for omissions. I want a slot in the report template the agent literally cannot fill in without stating the range.

## (1) The exact change

But first — the Iron Law applies to **edits**, not just new skills. I will NOT write this change and deploy it. The change below is what I *intend* to make, contingent on baseline testing (see verification plan). If I write it and skip the test, I delete it and start over.

**Proposed edit to the code-review skill's report template section.** Wherever the skill shows the structure of the review report, make the commit range a required leading field:

```markdown
## Review Report Structure

Every review report MUST begin with this header, filled in from the
actual range you reviewed:

**Reviewed range:** `<base-sha>..<head-sha>` (`git log --oneline <base>..<head>`)
**HEAD at review time:** `<head-sha>` — `<commit subject>`

(If you cannot determine the range, the report is not ready. Run
`git rev-parse HEAD` and `git merge-base` to establish it before
writing any findings.)

### Findings
...
```

Key properties, by design:
- It's a **slot in the template they already fill in**, not a prose reminder elsewhere.
- It's keyed to **observable git state** (`git rev-parse HEAD`), so "covered latest vs. stale" becomes verifiable by the controller.
- The parenthetical handles the "I don't know the range" case by making the report explicitly *not ready*, rather than allowing a blank.

I'd also confirm there isn't an existing prose line like "include the commits you reviewed" — if there is, I'd remove it, since a redundant soft reminder competes with the structural slot.

## (2) Verification plan (before deploying)

**RED — baseline, the part I must not skip:**
1. Take the *current* code-review skill (unchanged) as the subagent's system prompt.
2. Give 5+ fresh subagents a realistic review task on a repo with recent commits — the actual context they run in, not a toy.
3. Confirm the reports **actually omit the commit range** (read each one manually). If they don't omit it in the control, there is nothing to fix and I stop — the problem is elsewhere (e.g., controller parsing).
4. Record verbatim what they produce: do they reference commits vaguely ("the latest changes"), name a branch, give no range at all?

**GREEN — with the change:**
5. Apply the template change. Run the same 5+ scenarios with fresh contexts.
6. Read every report manually. Success = a concrete `base..head` range with real SHAs at the top of each. Watch for template-echo (literally outputting `<base-sha>`) which would mean the slot isn't binding.

**Check variance (it's a metric):**
7. Across the 5 reps, the header should converge to the same shape. If reps diverge (some give branch names, some SHAs, some merge-base, some not), the slot isn't tight enough — I tighten the structural form before adding any words.

**REFACTOR:**
8. If a new gap appears (e.g., they state head but not base, or invent a range without running git), add the missing structural constraint or the explicit git command, and re-test.

**Deploy only after** reports consistently and concretely carry the range under fresh contexts.

One note: this is wording/structure on output shape, so micro-tests (single fresh samples vs. the no-guidance control) are the fast iteration loop here — appropriate since this is an omission/shaping fix, not a discipline rule needing full pressure scenarios.