review

# /parml:review — did it work, and what did it cost A speedup that reports success while doing damage is the default failure mode of this whole area. So this skill tries to **falsify** the claim rather than confirm it — and reports plainly when it cannot. Adversarial is not the same as pessimistic. A change that survives every check is a real outcome and the correct answer is a clean `confirmed`. Manufacturing a concern to look thorough is worse than not reviewing at all: it costs the operator's attention, and it teaches them to discount the next review. Read-only. It produces a verdict and the specific check that would settle any open question. It does not edit and it does not run training. ## First action, always Get the diff and the claim: ```bash git diff --stat HEAD 2>/dev/null || git status --short ``` Then ask, if not already stated: **what was this change supposed to buy, and how was that measured?** A review with no claim to test is an audit — redirect to `/parml:audit`. Read `./.parml/frontier.md` if it exists; a change outside the recorded plan is itself a finding. ## Hard rules 1. **Read-only.** No edits, no commits, no training runs. Short read-only probes are fine. 2. **Test the claim, not the code's plausibility.** "This looks correct" is not a verdict. Every conclusion names the check that produced it. 3. **A throughput number is never accepted as evidence** (`pitfalls.md` P3). Ask for time-to-target, or for both factors of `steps-to-targe...