Code Review Skill
Overview
A systematic approach to code review that moves beyond "it looks good" to rigorous quality verification. This skill provides specific checklists and procedures for different review types.
When To Use
- Self-Review: Before submitting a PR or finishing
/work - Peer Review: When reviewing another agent's or human's code (
/resolve_pr) - Plan Review: When validating an implementation plan (
/plan_review)
Instrumentation
# Log usage when using this skill
Call MCP `call_tool_logger_manager` { action: "logSkill", name: "code-review", outcome: "manual" }
What do you want to do?
- Security Review (Auth, RLS, Input) →
workflows/security-pass.md - Performance Review (Database, Re-renders) →
workflows/performance-pass.md - Architecture Review (State, Data Flow) →
workflows/architecture-pass.md - General Quality Check →
checklists/pre-merge.md
Key Principles
- Review in Passes: Don't check everything at once. Do a security pass, then a performance pass, etc.
- Reference Patterns: Always check against
docs/solutions/patterns/critical-patterns.md. - Verify, Don't Guess: If you see a potential issue, verify it with a quick test or script.
Scientific Review Principles
Adapted from formal peer review standards to improve code review rigor:
- Algorithmic Soundness Check: Avoid circular logic where state values mask deeper architectural flaws.
- Control Variables Isolation: Ensure side-effects are heavily isolated and easily testable (simulating scientific controls).
- Absolute Reproducibility: If a bug or edge-case is discussed in review, verify that the system has enough telemetry/logging to perfectly reproduce it.
- Constructive Tone Constraint: Frame criticism objectively as an opportunity for improvement. Avoid dismissing implementations without offering actionable, pattern-compliant alternatives.