code-reviewlisted

# Code review Scoped review of a deliverable against its requirements to catch defects before it is marked done. ## When to use When a `plans/*.md` task or deliverable is reported complete and needs an independent check before its status flips to done — or whenever the workflow reaches a quality step. ## Method Read the deliverable and its acceptance criteria/spec first; review against them, not against personal preference. Following Google's "How to do a code review", walk each category and read every line the author expects reviewed: 1. **Correctness / Functionality** — does the code behave as the spec and the author intended; are edge cases and error paths handled. 2. **Tests** — does the change have correct, well-designed automated tests covering the new behavior (not just the happy path)? 3. **Readability / Naming / Comments** — clear names, comments that explain *why* not *what*, no dead code or leftover debug output. 4. **Design / Complexity** — is the change well-designed for the system it lands in; could it be simpler; would another developer understand and reuse it later? 5. **Security** — obvious injection, auth/authz, secrets, or input-validation issues on the touched surface (defer a full pass to the `security-review` skill when the change is security-sensitive). 6. **Consistency / Documentation** — matches existing style/conventions; docs updated if behavior or interface changed. Grade each finding by severity: **Critical** (breaks correct