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. **The review is printed, not filed.** Findings carry `CR-n` ids so a fix pass can report against them and a PR can name what is still open. Nothing is written to the repo; the fix pass records what it did in the design file's `## Implementation` section. ## 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. **Load the conventions you are reviewing against.** Read `${CLAUDE_SKILL_DIR}/../errors/SKILL.md` and `${CLAUDE_SKILL_DIR}/../logging/SKI