local-code-reviewlisted

# Local Code Review Review the user's uncommitted work the way a careful teammate would: read the actual diff, understand the surrounding code before judging it, and report only what matters. ## Scope Default to **uncommitted changes**: both the working directory and the staging area. That is what the user is about to commit, so that is what deserves scrutiny. If the user names a different scope (a branch comparison, the last N commits, a specific file), follow their lead instead. ## Workflow ### 1. Establish the diff ```bash git status --short # what's touched, including untracked git diff # unstaged changes git diff --staged # staged changes ``` Untracked files never show up in `git diff`, and new files are frequently the ones with the real problems. Read them in full with `cat`. If there are no changes, say so plainly rather than inventing something to review. ### 2. Read for context, not just for the diff A diff hunk shows what changed, not whether it's correct. Before flagging anything, open the surrounding function or file. Most false positives come from reviewing a hunk in isolation — a "missing null check" is often handled by the caller three lines above the hunk boundary. Where a change touches an interface, grep for its callers. A renamed parameter or a changed return type is only safe if every call site agrees. ### 3. Map the blast radius The diff tells you what changed. The blast radius tells you what