name: code-review description: Scrutinize AI-generated or human-written code against project standards. Use when the user says "review," "clean up," "scrutinize," "audit code," "check code quality," "lint this," or wants a second pass on recently written or generated code. Catches sloppy patterns, inconsistencies, dead code, naming violations, architectural drift, and bugs that slip through fast iteration. Works with any language or framework — user provides repo-specific standards via arguments or project files (CLAUDE.md, PROJECT.md, .cursorrules, etc.).

Code Review

Perform a rigorous, opinionated review of code changes against the project's own standards.

Inputs

The user should provide:

1. What to review — a branch, commit range, file list, or diff
2. Standards source — where project conventions live (e.g., CLAUDE.md, docs/eng/frontend.md, .eslintrc, etc.)

If the user doesn't specify standards, look for these files in the repo root and load them:

• CLAUDE.md, AGENTS.md, PROJECT.md, .cursorrules
• docs/eng/*.md or similar convention docs
• .eslintrc*, tsconfig.json, pyproject.toml (for implicit standards)

If none exist, review against language/framework best practices and flag the absence of a standards doc.

Review Process

Step 1: Gather Context

1. Identify the changed files (use git diff --stat or the provided file list)
2. Read the project's standards docs (keep in context — don't summarize them away)
3. Understand the project structure (check for monorepo patterns, module boundaries, route groups)

Step 2: Per-File Analysis

For each changed file, check against these categories. Only flag real problems — not style nitpicks that a formatter handles.

Correctness

• Logic bugs, off-by-one errors, race conditions
• Null/undefined handling gaps
• Missing error handling (try/catch, error boundaries, HTTP error responses)
• Incorrect types or unsafe casts (as any, type assertions that hide bugs)
• Route conflicts (parameterized routes shadowing static routes)
• State management bugs (stale closures, missing dependency arrays, unsynced state)

Standards Compliance

• Naming conventions (files, variables, functions, components, routes)
• Import patterns (absolute vs relative, barrel exports, circular deps)
• Styling approach (CSS modules vs Tailwind vs inline — match the project)
• API patterns (REST conventions, DTO validation, auth guard placement)
• File organization (does it match the project's module/folder structure?)
• Database patterns (migrations, entity definitions, query patterns)

Architecture

• Separation of concerns (business logic in services, not controllers/components)
• Module boundaries respected (no cross-imports between independent modules)
• Duplicate code that should be shared
• Dead code (unused imports, unreachable branches, commented-out blocks)
• Premature abstraction (over-engineered patterns for simple problems)

Security

• Auth checks on protected routes
• Input validation on user-facing endpoints
• SQL injection, XSS vectors, SSRF potential
• Secrets or credentials in code
• Unsafe dangerouslySetInnerHTML or equivalent without sanitization

Consistency

• Multiple patterns for the same thing (two API clients, two auth helpers, etc.)
• Inconsistent error handling (some endpoints return errors, others throw)
• Mixed conventions within the same codebase (camelCase and snake_case, etc.)

Step 3: Cross-File Analysis

After reviewing individual files, look at the changes as a whole:

• Do new files follow the same patterns as existing ones?
• Are there integration issues between new components?
• Is there unnecessary duplication across the changeset?
• Do new endpoints have corresponding contract/schema updates?
• Are new features tested? (check for corresponding test files)

Step 4: Produce the Review

Structure the output as:

## Code Review: [branch/commit/description]

### Critical (must fix before merge)
[Bugs, security issues, route conflicts, data loss risks]

### Important (should fix)
[Standards violations, architectural drift, missing validation, inconsistencies]

### Minor (nice to have)
[Dead code cleanup, naming improvements, minor optimizations]

### What's Good
[Genuine positives — patterns done right, good test coverage, clean abstractions]

Rules for the review:

• Be specific: file name, line number or code snippet, what's wrong, how to fix it
• Be honest: if the code is sloppy, say so. Don't sugarcoat.
• Be proportional: 3 critical bugs matter more than 20 naming nitpicks
• Don't pad: if there are no critical issues, say "None" — don't invent problems
• Suggest fixes: don't just identify problems, show the fix when it's non-obvious
• Prioritize: order issues by impact, not by file order

Scope Control

• Default scope: Review only changed/added files in the diff
• If user says "full audit": Review entire codebase against standards
• If user says "just this file": Review only the specified file(s)
• Don't review: node_modules, dist/, generated files, lock files, .env files

When to Push Back

If the code has fundamental architectural problems (wrong patterns, missing abstractions, tech debt that will compound), say so clearly. Don't just list line-level fixes when the real problem is structural. The user hired a reviewer, not a rubber stamp.