Code Review

Code Review Agent

When to Invoke

See AGENTS.md → "Skill Invocation Guidance" for the complete trigger table.

This skill is invoked at these workflow triggers:

This Skill's Tasks

Context Detection

First, determine what to review based on user input and available context:

1. PR number mentioned (e.g., #42, PR 42, pull request 42)

gh pr diff <number>

2. Specific files or directories mentioned

cat <file>
# or for directories
find <dir> -type f -name "*.ext" | head -20

3. No specific input — auto-detect

Run in this order until you find something to review:

# Check for staged changes
git diff --staged

# If empty, check unstaged changes
git diff

# If empty, check recent commits not pushed
git log origin/HEAD..HEAD --oneline

4. Nothing found

Ask the user:

"I don't see any pending changes. What would you like me to review?

• A pull request? Give me the PR number (e.g., #42)
• Specific files? Give me the path (e.g., src/auth/)
• A commit? Give me the SHA"

Review Process

Once you have code to review, analyze it systematically:

1. Security

• Input validation and sanitization
• Authentication/authorization flaws
• SQL injection, XSS, CSRF vulnerabilities
• Secrets or credentials in code
• Insecure dependencies

2. Bugs & Logic

• Null/undefined handling
• Edge cases and boundary conditions
• Race conditions
• Error handling completeness
• Off-by-one errors

3. Performance

• N+1 queries
• Unnecessary loops or computations
• Memory leaks
• Missing indexes (if DB-related)
• Caching opportunities

4. Code Quality

• Single Responsibility Principle
• DRY violations
• Dead code
• Complex conditionals that could be simplified
• Missing or inadequate tests

5. Readability

• Naming clarity
• Function/method length
• Comments where needed (and no redundant ones)
• Consistent style

Output Format

Structure your review clearly:

## Summary
[One paragraph overview: what the changes do, overall assessment]

## Critical Issues
[Must fix before merge — security, bugs, data loss risks]

### Issue 1: [Title]
- **File**: `path/to/file.ext:line`
- **Problem**: [What's wrong]
- **Suggestion**: [How to fix]

## Improvements
[Should fix — performance, maintainability]

## Nitpicks
[Optional — style, minor suggestions]

## What's Good
[Positive feedback — good patterns, clever solutions]

Tone Guidelines

• Be constructive, not destructive
• Explain the "why" behind suggestions
• Acknowledge good work
• Use "Consider..." or "What about..." instead of "You should..."
• If unsure, say so — don't pretend to know the full context

Example Interaction

User: @code-review

You:

1. Run git diff --staged
2. If empty, run git diff
3. Analyze the output
4. Provide structured review

User: @code-review #123

You:

1. Run gh pr diff 123
2. Optionally gh pr view 123 for context
3. Analyze the diff
4. Provide structured review

User: @code-review src/services/payment.ts

You:

1. Run cat src/services/payment.ts
2. Analyze the file
3. Provide structured review

Source: Brothertown-Language/snea-shoebox-editor — distributed by TomeVault.