Review the current code changes for bugs, style issues, security concerns, and missed edge cases.
Scope
- If
$ARGUMENTS is empty: review all staged changes (git diff --cached) and unstaged changes (git diff).
- If
$ARGUMENTS is a file path: review only that file's changes.
- If
$ARGUMENTS is "branch": review all changes on the current branch vs. main (git diff main...HEAD).
Review Checklist
For each changed file, evaluate:
- Correctness — Does the logic do what it claims? Are there off-by-one errors, null checks, or missing edge cases?
- Security — SQL injection, command injection, XSS, path traversal, hardcoded secrets, OWASP top 10.
- Performance — Unnecessary loops, N+1 queries, missing indexes, large allocations in hot paths.
- Style — Naming conventions, code organization, consistency with existing patterns.
- Tests — Are new code paths covered? Are edge cases tested? Would a regression test catch this bug?
Output Format
Write findings to scratch/review_latest.md with this structure:
## Review: <branch or file>
### Critical (must fix)
- [file:line] description
### Warning (should fix)
- [file:line] description
### Nit (optional)
- [file:line] description
### Verdict: APPROVE / NEEDS CHANGES
Return a ≤5 line summary to the main context.
Four Questions Validation
After the review, verify the change against these evidence checks:
- Are tests passing? — Run relevant tests and show output. Never claim "tests pass" without proof.
- Are requirements met? — List each requirement from the task/ticket and confirm it's addressed.
- Are assumptions verified? — Cite docs, source code, or specs for any behavioral claims.
- Is there evidence? — Provide concrete results (test output, build logs, diff excerpts).
Flag any of these red flags in your review:
- Claims without evidence ("should work", "probably fine")
- References to APIs or behaviors that weren't verified against source
- Fabricated identifiers (invented function names, non-existent modules)
- "No side effects" claims without checking callers and shared state
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: review-163description: Review current code changes for bugs, style issues, and security concerns Use when this capability is needed.4---56Review the current code changes for bugs, style issues, security concerns, and missed edge cases.78## Scope910- If `$ARGUMENTS` is empty: review all staged changes (`git diff --cached`) and unstaged changes (`git diff`).11- If `$ARGUMENTS` is a file path: review only that file's changes.12- If `$ARGUMENTS` is "branch": review all changes on the current branch vs. main (`git diff main...HEAD`).1314## Review Checklist1516For each changed file, evaluate:17181. **Correctness** — Does the logic do what it claims? Are there off-by-one errors, null checks, or missing edge cases?192. **Security** — SQL injection, command injection, XSS, path traversal, hardcoded secrets, OWASP top 10.203. **Performance** — Unnecessary loops, N+1 queries, missing indexes, large allocations in hot paths.214. **Style** — Naming conventions, code organization, consistency with existing patterns.225. **Tests** — Are new code paths covered? Are edge cases tested? Would a regression test catch this bug?2324## Output Format2526Write findings to `scratch/review_latest.md` with this structure:2728```29## Review: <branch or file>3031### Critical (must fix)32- [file:line] description3334### Warning (should fix)35- [file:line] description3637### Nit (optional)38- [file:line] description3940### Verdict: APPROVE / NEEDS CHANGES41```4243Return a ≤5 line summary to the main context.4445## Four Questions Validation4647After the review, verify the change against these evidence checks:48491. **Are tests passing?** — Run relevant tests and show output. Never claim "tests pass" without proof.502. **Are requirements met?** — List each requirement from the task/ticket and confirm it's addressed.513. **Are assumptions verified?** — Cite docs, source code, or specs for any behavioral claims.524. **Is there evidence?** — Provide concrete results (test output, build logs, diff excerpts).5354Flag any of these red flags in your review:55- Claims without evidence ("should work", "probably fine")56- References to APIs or behaviors that weren't verified against source57- Fabricated identifiers (invented function names, non-existent modules)58- "No side effects" claims without checking callers and shared state5960---61> Converted and distributed by [TomeVault](https://tomevault.io/claim/sakebomb) — claim your Tome and manage your conversions.62<!-- tomevault:4.0:skill_md:2026-04-13 -->