code-reviewlisted

# Code review Review a diff on two axes, in parallel sub-agents, and report them side by side. - **Standards** — does the code follow the rules this repo documents? - **Spec** — does the code do what the originating issue or plan asked for? The premise that makes this different from "find problems in this diff": **a review round has to be able to finish.** An open-ended hunt samples a diff, and every fresh round samples it differently, so three rounds turn up three disjoint sets of real defects and nobody can tell whether the fourth would turn up more. Each axis here enumerates a closed list from a source document first, then returns a verdict per item. Findings are the items that came back bad. The reader learns what was checked, not just what was noticed. Two rules follow from that, and they are the ones to keep if everything else is forgotten: 1. **Enumerate before you judge.** The list of things to check comes from a document (the repo's standards, the issue's acceptance criteria), so it is finite, and the same on every run. 2. **A finding carries a failure scenario.** Concrete input or state, traced in the code, and the wrong thing that results. No scenario means it goes in `unverified` or is dropped. A plausible-sounding finding nobody traced is how a fix gets written for a defect that was never there. ## Delegation authority Invoking this skill authorizes every sub-agent dispatch that this procedure marks mandatory, including a mandatory nested re