Code Review
Review the current changes the way a careful reviewer would, and report findings ranked by severity.
When to use
Before opening a pull request, or when the user asks for a review of recent changes.
Procedure
- Run
git diff (or git diff main...HEAD) to see what changed. Read the full changed files, not just the diff hunks, so you have context.
- Check each of these and note any issue with a file and line reference:
- Correctness: logic errors, off-by-one mistakes, wrong conditionals, unhandled null or empty cases.
- Edge cases: empty input, very large input, concurrent calls, failure of an external call.
- Security: unvalidated input, secrets committed in code, injection risks, missing authorization checks.
- Conventions: does the change match the existing patterns and style of the surrounding code?
- Tests: is the new behavior covered? Are existing tests still valid?
- Clarity: misleading names, dead code, comments that no longer match the code.
- Rank findings as blocking, should-fix, or nit. Lead with blocking.
- For each finding give a one-line fix suggestion, not just the problem.
- If you find nothing significant, say so plainly rather than inventing issues.
Output
A short summary line, then the findings grouped by severity, each as file:line plus the issue and the suggested fix.
1---2name: code-review3description: Run a structured self-review pass on changed files before opening a pull request4---56# Code Review78Review the current changes the way a careful reviewer would, and report findings ranked by severity.910## When to use11Before opening a pull request, or when the user asks for a review of recent changes.1213## Procedure141. Run `git diff` (or `git diff main...HEAD`) to see what changed. Read the full changed files, not just the diff hunks, so you have context.152. Check each of these and note any issue with a file and line reference:16 - **Correctness:** logic errors, off-by-one mistakes, wrong conditionals, unhandled null or empty cases.17 - **Edge cases:** empty input, very large input, concurrent calls, failure of an external call.18 - **Security:** unvalidated input, secrets committed in code, injection risks, missing authorization checks.19 - **Conventions:** does the change match the existing patterns and style of the surrounding code?20 - **Tests:** is the new behavior covered? Are existing tests still valid?21 - **Clarity:** misleading names, dead code, comments that no longer match the code.223. Rank findings as blocking, should-fix, or nit. Lead with blocking.234. For each finding give a one-line fix suggestion, not just the problem.245. If you find nothing significant, say so plainly rather than inventing issues.2526## Output27A short summary line, then the findings grouped by severity, each as `file:line` plus the issue and the suggested fix.
claudifytech