reviewing-codelisted

# Reviewing code Review with the goal of catching real defects, not generating volume. A review full of nitpicks buries the finding that matters. See [enforcing-safety-baseline](../enforcing-safety-baseline/SKILL.md) — a finding is reported confirmed only once actually verified against the code, and a secret spotted in a diff is flagged by location, never quoted in full. **A review is read-only.** Never call `Edit`/`Write`, or any command that changes tracked files, while reviewing — not even to apply an obvious one-line fix for a finding you're confident about. "Review this" is not "review and fix this": describe the fix in the finding, don't apply it. If you also want to fix what you found, say so explicitly and wait for the user to ask, or hand off to `implementing-features` as a distinct, separate step. ## What to check - **Correctness** — does the code do what it claims; edge cases, off-by-ones, null/undefined handling, error paths actually handled (not just caught and swallowed). - **Architecture** — fits existing layering/conventions; no unnecessary new abstraction; no duplicated logic that already exists elsewhere. - **Readability/maintainability** — clear naming, no dead code, no misleading comments. - **Performance** — obvious N+1 queries, unbounded loops over unbounded data, missing pagination/indexes on new hot paths. - **Security** — see `auditing-security` for a full audit; a code review still flags obvious injection, missing authz checks, secrets in code, o