review

The reviewer reads both the diff and the surrounding source files to understand intent and catch issues that only appear in context.

<core_principle> FIND REAL ISSUES, NOT STYLE NITS. Focus on problems that cause bugs, security vulnerabilities, performance degradation, or maintainability pain. Avoid nitpicking formatting or subjective style preferences unless they harm readability. </core_principle>

<analysis_only_rule> THIS SKILL IS READ-ONLY. DO NOT MODIFY CODE.

The purpose is to review and report findings. Making changes during review conflates the reviewer and author roles. Present findings and let the user decide what to act on. </analysis_only_rule>

<working_directory_awareness> Before running any git command: check whether your dispatch context specifies a working directory (look for "Working directory:" in your initial prompt). If it does and pwd does not match it, prefix every git invocation with -C <that path> (e.g. git -C /path/to/worktree diff --cached). Reviewing the wrong directory's diff is a silent failure mode — the review will look correct but cover the wrong code. </working_directory_awareness>

<quick_start>

<determine_review_scope>

Parse the user's input to determine what to review:

1. No arguments - Review staged changes first. If nothing is staged, review unstaged changes.

   • Staged: git diff --cached
   • Unstaged: git diff
   • If both are empty, review the most recent commit: git show HEAD

2. Commit hash argument (e.g., /review abc1234) - Review that specific commit.

   • git show <hash>

3. File path argument (e.g., /review src/foo.ts) - Review unstaged changes in that file.

   • git diff -- <path> then fall back to git diff --cached -- <path>

4. "pr" argument (e.g., /review pr) - Review all changes since branching from main.

   • git diff main...HEAD
   • If on main, review git diff HEAD~1

After obtaining the diff, if it is empty, inform the user that there are no changes to review and stop.

</determine_review_scope>

<gather_context>

Before analyzing the diff:

1. Read changed files in full - Do not review a diff in isolation. Read each modified file to understand the surrounding code, imports, types, and control flow.
2. Identify the tech stack - Note languages, frameworks, and libraries in use. This affects what patterns are risky.
3. Check for related test files - For each changed source file, look for corresponding test files. Note whether tests were updated alongside the changes.
4. Check for configuration changes - If config files changed (env, CI, package.json, tsconfig, etc.), pay extra attention to side effects.

</gather_context>

<review_categories>

Analyze the changes against each category below. Only report findings that are actually present. Skip categories with no issues.

A. Security Issues (Severity: CRITICAL or HIGH)

• Injection vulnerabilities (SQL injection, command injection, template injection)
• Cross-site scripting (XSS) - unsanitized user input rendered in HTML
• Authentication and authorization flaws (missing auth checks, privilege escalation)
• Secrets or credentials hardcoded or logged
• Insecure deserialization or unsafe eval usage
• Path traversal or file access vulnerabilities
• Missing input validation on external data

B. Performance Concerns (Severity: HIGH or MEDIUM)

• N+1 query patterns in database access
• Unnecessary memory allocations in hot paths or loops
• Blocking operations on the main thread or in async contexts
• Missing pagination on unbounded queries
• Redundant computation that could be cached or memoized
• Large payloads without streaming or chunking