code-review

name	code-review
description	Review code changes against project standards with structured feedback on security, performance, naming, error handling, and test coverage.

Code Review

Perform a structured code review on staged or recent changes, checking for security issues, performance problems, naming inconsistencies, and missing tests.

When to Use

Use this skill when:

• Reviewing a PR or set of changes before merge
• Self-reviewing your own code before pushing
• Auditing a specific file or module for quality

Instructions

1. Read the style guide at ../../_references/style-guide.md to understand the team's conventions.

2. Identify the changes to review:

   • If given a file path, review that file
   • If given a PR number, use gh pr diff <number> to get the diff
   • If no target specified, use git diff --staged for staged changes
   • If nothing is staged, use git diff HEAD~1 for the last commit

3. Review each changed file against these criteria:

Security (Critical)

• No hardcoded secrets, API keys, or credentials
• User input is validated and sanitized before use
• SQL queries use parameterized statements (no string concatenation)
• Authentication checks on protected routes/endpoints
• No eval(), Function(), or innerHTML with user data
• Sensitive data not logged or exposed in error messages
• CORS configuration is restrictive, not *

Performance

• No N+1 query patterns in database calls
• Large lists use pagination or virtual scrolling
• Expensive computations are memoized where appropriate
• No synchronous file I/O in request handlers
• Images and assets are optimized
• No memory leaks (event listeners cleaned up, subscriptions unsubscribed)

Code Quality

• Functions are under 40 lines — extract if longer
• No more than 3 levels of nesting — refactor if deeper
• Variable names describe intent, not type (users not arr)
• No commented-out code left behind
• Error handling is specific, not bare catch(e) {}
• Types are specific — no any unless explicitly justified
• Magic numbers are extracted to named constants

Testing

• New functions have corresponding tests
• Edge cases are covered (empty arrays, null, boundary values)
• Tests are independent and don't rely on execution order
• Mock boundaries are at I/O (network, filesystem, database)
• Test descriptions explain behavior, not implementation

4. Rate each category:

   • 🟢 Good — no issues found
   • 🟡 Acceptable — minor issues, non-blocking
   • 🔴 Needs Work — must fix before merge

5. Provide specific feedback:

   • Reference exact line numbers
   • Explain why something is a problem, not just what
   • Suggest a concrete fix for every issue raised
   • Distinguish between blocking issues and suggestions

6. Output format:

   ## Code Review: {file or PR}
   
   | Category    | Rating | Issues |
   |-------------|--------|--------|
   | Security    | 🟢     | 0      |
   | Performance | 🟡     | 2      |
   | Quality     | 🟢     | 0      |
   | Testing     | 🔴     | 3      |
   
   ### Blocking Issues
   ...
   
   ### Suggestions
   ...
   
   ### What's Good
   ...
   

Example Usage

Review the staged changes

Code review src/api/auth.ts focusing on security

Review PR #42