code-reviewlisted

Review recently changed code for correctness, safety, and clarity. Not a style pass — a technical read that flags what could break, what's missing, and what's over-engineered. ## Example prompts - "Code review the changes on this branch" - "Review the new backend code" - "Check my PR before I open it" - "Look for bugs in what I just wrote" ## Scope Reviews **changed code only** by default (uncommitted + last-N commits since branch diverged from main). If the user asks for a "full review" of a file or folder, review everything they name — but flag if the review is going to run long and offer to focus on the diff instead. ## Process 1. **Find the diff.** In order of preference: - Uncommitted changes: `git status --short` + `git diff` + `git diff --cached` - Branch diff: `git diff <main-or-master>...HEAD` - Specific files/folder: whatever the user named If there are no changes and no target, ask what to review. 2. **Read the changed files in full** (not just the diff hunks). Context matters — a 3-line change in a security-sensitive function needs the whole function. 3. **Run the checklist** (skip categories that don't apply): **Correctness** - Edge cases: empty input, null, undefined, zero, negative, huge input, unicode - Off-by-one, boundary conditions - Async: unhandled promise rejections, missing `await`, race conditions - State mutation that leaks across requests / callers - Wrong return types vs. what callers expect **Security*