Pattern — code review

A useful review isn't "look for problems." It's a workflow with a standard, a threshold, and a verification step — otherwise you get a wall of style nits and the occasional confidently wrong "bug."

The workflow

1. Set the standard (role + constraints). State what you review for and what you deliberately ignore. Without a threshold, an agent surfaces everything; the noise buries the one finding that matters.
2. Score with a severity rubric. Each finding gets a level — say, blocking / should-fix / nit — with an explicit definition. This is a rubric-based judgment, and it makes results comparable across runs.
3. Verify each finding before reporting. For every claimed bug, require a concrete failure scenario: the inputs and the wrong result. A finding that can't be made concrete is a false positive — verify adversarially and drop it.
4. Report in a fixed shape. One structured entry per finding: location, severity, scenario, fix. Predictable output shape makes the review actionable.

Why package it

You want the same standard and threshold every time, not whatever the agent improvises today. That consistency is the whole case for turning this into a skill — it's what the production-code-review skill encodes, evals included.