By name: code-review description: Review code changes for quality, security, performance, and correctness following project-specific standards. Use when reviewing pull requests, examining git diffs, or when the user asks for a code review. This skill should be used proactively — when the user asks for a review without specifying commits, automatically detect the current branch and diff against the main branch.
Code Review
Workflow
Step 1: Determine the diff
If the user provides explicit SHAs or a PR link, use those. Otherwise, auto-detect:
# Fetch latest remote state
git fetch origin main --quiet
# Detect current branch
CURRENT_BRANCH=$(git branch --show-current)
# Find the merge base with origin/main
MERGE_BASE=$(git merge-base origin/main HEAD)
# Show what changed
git diff --stat $MERGE_BASE..HEAD
git diff $MERGE_BASE..HEAD
If CURRENT_BRANCH is main, warn the user and ask which commits to review.
Step 2: Read project standards
Read custom-code-style.md for project-specific coding style.
Step 3: Review against the checklist
Correctness:
- Logic handles edge cases and boundary conditions
- Error handling is comprehensive (no silent failures)
- Type safety maintained (no unsafe casts, proper use of
std::optional) - Resource lifecycle correct (RAII, no leaks, proper cleanup order)
Architecture:
- Clean separation of concerns, no layer violations
- Dependencies flow in the correct direction
- Changes align with existing patterns in the codebase
- No unnecessary coupling introduced
Performance & Concurrency:
- No performance regressions on hot paths
- Thread safety: proper locking, no data races
- CUDA/NPU kernels: memory coalescing, occupancy, sync correctness
- No unnecessary copies of large objects (tensors, vectors)
Testing:
- Tests verify actual logic, not just mock wiring
- Edge cases and error paths covered
- Integration tests for cross-component changes
Production Readiness:
- Backward compatibility maintained (or breaking changes documented)
- Migration strategy for schema/config changes
- No hardcoded values that should be configurable
Step 4: Output findings
Use the format below.
Output Format
Strengths
[Specific things done well, with file:line references]
Issues
Critical (Must Fix)
[Bugs, security holes, data loss risks, broken functionality]
Important (Should Fix)
[Architecture problems, missing error handling, test gaps, performance issues]
Minor (Nice to Have)
[Style, optimization opportunities, documentation improvements]
Each issue must include:
- File:line reference
- What is wrong
- Why it matters
- How to fix (if not obvious)
Recommendations
[Broader improvements for code quality, architecture, or process]
Assessment
Ready to merge? [Yes / No / With fixes]
Reasoning: [1-2 sentence technical assessment]
Rules
DO:
- Apply project-specific style from custom-code-style.md
- Follow DDD (Domain Driven Design) principles, and keep the codebase clean and maintainable
- Categorize by actual severity (not everything is Critical)
- Be specific with file:line references
- Explain WHY issues matter
- Acknowledge strengths
- Give a clear verdict
DON'T:
- Approve without thorough review
- Mark nitpicks as Critical
- Give feedback on code not in the diff
- Be vague (e.g., "improve error handling" without specifics)