code-review: run the reviewers at the harness's most capable model, not the caller's level

### Before filing - [X] I've read `SCOPE.md` and checked `.out-of-scope/`, and this isn't covered by either. ### Skill code-review ### What went wrong `code-review` spawns its Standards and Spec sub-agents without choosing a model or reasoning effort, so they inherit the caller's. When implementation runs on a cheaper model, which is the point of running `/implement` or `/implement-spec` that way, the review is only as strong as the session that wrote the code. I measured this on five real diffs in Claude Code. Each had been reviewed with the reviewers at Claude Opus 5.5 / high effort, and its findings then fixed. I re-ran `code-review` on each diff at the reviewed commit, from a fresh session at Claude Sonnet 5.5 / medium (the level the code was written at), with the reviewers inheriting that level. Then I sorted every finding the later fix commits addressed: | Diff | Fixed findings only Opus/high caught | Caught by both | Only Sonnet/medium caught | |---|---|---|---| | 1 | 4 | 3 | 0 | | 2 | 7 | 0 | 0 | | 3 | 2 | 1 | 0 | | 4 | 8 (+2 partly) | 1 | 0 | | 5 | 2 | 5 | 0 | The misses weren't all prose. The inherited-level reviewers missed, among others: - a static write guard that flags read-only calls such as `tarfile.open(path)` as writes; - a test that still passes when the default it pins is wrong; - a shell check that reports a missing md5 tool as drift; - a timeout watchdog that sends SIGTERM once and never escalates. In four places the inherited-level reviewer stated the opposite of the stronger one, and I checked the reviewed commit by hand: - "All flagged patterns are parametrised": four patterns had no test case. - "The file list is gone": the list was still in the file. - "The test is correct and fails if the defaults diverge": I changed the default; the test still passed. - "The header claim is narrowed": on one line, while another line still claimed the full range. Caveats: five diffs, one run each at the lower level. The fixes were written in response to the stronger review, so the "fixed" counts lean its way; the four hand checks don't depend on that. ### Proposed change One sentence in step 4: > Where the harness lets you choose a sub-agent's model and reasoning effort, run both reviewers at its most capable model and a high effort, whatever the session's own level. Where the harness can't choose, nothing changes: the reviewers inherit, as now. No argument and no config; someone who wants a cheaper review says so in the session. Why not a personal `CLAUDE.md` line: `code-review` is usually called by name at the end of `/implement` or `/implement-spec`, with no chance to ask. A per-user instruction has to be followed by the cheap calling session, the one least likely to follow it. The stronger-level reviews above come from a fork that does this.