code-reviewlisted

# Reviewing for claims the code does not honour Most review checklists ask one question: > Is this code correct? Nearly every defect that survives self-review came from a different one: > **Does this code do what its own documentation, config, comments and project > rules claim it does?** Correct-looking code passes the first question and fails the second. This is the class an author cannot see, and the reason is structural, not carelessness: the author read the claim and the code as a single intention. A reviewer with fresh context reads them as two artefacts that may disagree. Ask both questions on every review. This skill covers the second. **There is a third question, and it is not asked here.** *Is this the change, or just a change that works?* — duplication of something that already exists, redundant or derivable state, work repeated inside a loop, a fix applied at the wrong level. That is the **`quality-pass`** skill, and it is deliberately a separate pass: a reviewer hunting correctness and quality in one read does neither well. It runs **after** this one and it is **advisory** — it never blocks a merge. Everything in *this* file can and should. If a quality finding turns out to be a bug, it comes back here with a class name. ## How to use this 1. **Run the deterministic checks first**, whatever the project has — linters, `bash -n`, the test suite. They are free and never wrong. Prose review after, for the classes no machine catches. 2. **Load the proje