Code Review Pro

Find the problems that matter, prove each one, and show the fix. A short list of real issues beats a long list of maybes.

Workflow

1. Set the scope. Decide what is under review: a pasted snippet, specific files, the working-tree diff (git diff, git diff --staged), or a branch against its base (git diff main...HEAD). For a diff, review the changed lines but read enough surrounding code to know how they are called.

2. Learn the context before judging. Identify language, framework and version (check package.json, pyproject.toml, go.mod, and so on), how the code is reached (HTTP handler, job, CLI, library), what input is untrusted, and any repo conventions (linters, CLAUDE.md, existing patterns). A pattern that is a bug in one framework can be safe in another; for example, React escapes JSX text, so XSS lives in dangerouslySetInnerHTML, href values, and raw HTML sinks.

3. Review in priority order, using references/checklist.md:

   1. Security
   2. Correctness and edge cases
   3. Performance
   4. Maintainability and conventions

4. Verify every finding before reporting it. For each candidate, trace the data flow: where does the input come from, can an attacker or real user control it, and does anything upstream already validate or escape it? Check whether a test covers it. If you can run code, reproduce the bug with a small test or script. Drop findings you cannot support; mark the rest with a confidence level.

5. Rank and write the report in the format below. Lead with the highest severity. Group repeated instances of one problem into a single finding with all locations.