JulienLerosty/claude-code-team-kit

Review a pull request

1. Get the diff. For a PR number use gh pr diff <number>; otherwise git diff origin/main...HEAD. Also read the PR description if one exists (gh pr view <number>).
2. Read the changed files in full where the diff alone is unclear. Do not review code you have not read.
3. Check, in this order:
   • Correctness: wrong conditions, off-by-one, unhandled errors, race conditions, null/empty inputs.
   • Tests: is each behavior change covered? Would the tests fail without the change?
   • Security: untrusted input reaching shell, SQL, file paths or HTML; secrets in the diff.
   • Compatibility: changed public interfaces, migrations, config or environment variables.
   • Readability: only issues that would slow the next maintainer down. Skip pure style preferences the linter already covers.
4. Run npm test if tests exist and report the result honestly.

Output format

## Summary
One or two sentences on what the PR does and your overall verdict (approve / request changes / comment).

## Must fix
- `path/file.js:42` What is wrong, why it matters, suggested fix.

## Should consider
- `path/file.js:90` ...

## Nice to have
- ...

Leave a section out if it is empty. Cite file:line for every finding. Do not invent problems: if the change is fine, say so in the summary. Do not post comments to GitHub unless the user asks.