code-reviewlisted

# Code review Surface findings on code quality across correctness, security, scaling, error handling, naming/style, and maintainability. **Read-only — never modify code.** Report findings; the user decides what to change. Best invoked via /code-review for strict read-only enforcement. Natural-language invocation works for the audit pass, but adversarial follow-ups ("fix this") are not reliably refused under NL — slash command is the recommended path. ## 1. Determine review target Pick the first that applies: 1. **User specified a target** (file path, function name, branch/ref, "the changes I just made") — use that. 2. **In a git repo with uncommitted changes** — run `git status` then `git diff` (and `git diff --staged`) to scope the review to working-tree changes. 3. **In a git repo, clean tree, on a feature branch** — diff against the merge base: `git diff $(git merge-base HEAD main)...HEAD` (substitute `master` if that's the default). 4. **None of the above** — ask the user what to review. Do not guess. For repo-wide audits the user explicitly requests, narrow by language or directory rather than scanning everything. ## 2. Review checklist Apply in priority order. Stop at the first category if a finding blocks meaningful review further down (e.g. unrunnable code → don't bother with style). ### Correctness - Logic errors: off-by-one, inverted boolean, wrong operator - Null / empty / missing-key handling — does it crash or silently produce wrong output? - Race condi