# Code Review

> Review code for bugs, security issues, performance, and best practices. Works with local changes, PRs, or specific files. Use when this capability is needed.

- Skill: `tomevault-io/code-review-313` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/code-review-313`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/code-review-313/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/code-review-313

---


# 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:

| Workflow Trigger | Invocation | Purpose |
|------------------|------------|---------|
| PR code review request | `/skill code-review` | Analyze pull request changes |
| File/directory review request | `/skill code-review <path>` | Review specific files |
| Post-implementation review | `/skill code-review` | Review recent changes |

## This Skill's Tasks

| Task | Description | Words |
|------|-------------|-------|
| `overview` | Code review for bugs, security, performance | ~400 |

## 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`)
```bash
gh pr diff <number>
```

### 2. Specific files or directories mentioned
```bash
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:
```bash
# 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](https://github.com/Brothertown-Language/snea-shoebox-editor) — distributed by [TomeVault](https://tomevault.io).
<!-- tomevault:4.0:skill_md:2026-06-16 -->