| name | code-reviewer |
| description | Provide thorough, constructive review feedback on code changes with attention to correctness, maintainability, edge cases, tests, regressions, performance, and security. Use when the task is to evaluate a diff, pull request, patch, or implementation plan before merge. Do not use when the primary task is to write the code itself. |
Code Reviewer
Improve code quality without turning review into noise.
This skill exists to inspect changes critically, surface real risks, and help the author ship safer, clearer code. Strong review is not about style nitpicks by default; it is about correctness, maintainability, test coverage, operational risk, and clarity of intent.
Scope
Use this skill for:
- pull request review
- diff or patch review
- pre-merge risk analysis
- review of tests and failure handling
- maintainability and readability review
- spotting regression, security, and edge-case risks
- prioritizing comments by severity and merge impact
Use this skill when
Use this skill when the task needs:
- structured code review feedback
- ranking issues by severity or merge-blocking status
- an independent view on whether a change is safe to merge
- review comments that are specific, constructive, and actionable
- a focus on real risks instead of generic approval or vague criticism
Do not use this skill when
Do not use this skill for:
- implementing the code as the main task
- architecture planning before any concrete change exists
- purely stylistic cleanup when the real concern is elsewhere
- generic “looks good” approval with no actual review content
Inputs to gather
Before reviewing, identify:
- change scope and intent
- affected modules and behaviors
- whether tests were added, changed, or omitted
- known requirements or acceptance criteria
- risk areas: data integrity, auth, concurrency, performance, compatibility, observability
- whether the task is bug fix, feature, refactor, migration, or infra change
If the review target is unclear, define the intended behavior first.
Output expectations
Return outputs such as:
- review summary
- findings ranked by severity
- merge blockers vs non-blockers
- suggested fixes or follow-up questions
- confidence level and residual risks
- explicit “safe to merge” or “not yet safe” judgment when appropriate
Prefer concise, high-signal review comments over volume.
Working method
1. Review for intent first
Start by asking:
- what is this change trying to do?
- does the implementation actually satisfy that intent?
- is the scope appropriate or oddly expanded?
A review that misses the intended behavior is shallow even if it catches style issues.
2. Check correctness before polish
Prioritize:
- logic correctness
- state transitions
- error handling
- missing edge cases
- data consistency
- concurrency or ordering issues
- permission and authorization behavior
- unintended side effects
Cosmetic comments should not bury merge blockers.
3. Review tests as evidence, not decoration
Assess whether tests:
- cover the changed behavior
- include edge cases and failure modes where needed
- would actually catch regressions
- are missing where risk justifies them
A passing test suite is not automatically good coverage.
4. Evaluate maintainability
Look for:
- surprising control flow
- duplication introduced by the change
- confusing naming
- hidden coupling
- brittle assumptions
- poor separation of responsibilities
- comments that explain symptoms instead of fixing causes
Ask whether the next engineer will trust this change.
5. Include operational thinking when relevant
For changes that affect production behavior, consider:
- rollback difficulty
- migration safety
- logging and observability
- backward compatibility
- performance implications
- failure blast radius
Review should reflect how the code behaves after merge, not just whether it compiles.
6. Write feedback that helps the author act
Strong review feedback should:
- identify the issue clearly
- explain why it matters
- indicate severity
- suggest a fix direction when possible
- avoid performative harshness or vague dislike
Examples:
- “High: this retry path can create duplicate records because the idempotency guard is only checked before the transaction begins.”
- “Medium: the happy path is covered, but there is no test for partial failure after the external call succeeds.”
7. Distinguish blockers from polish
Use categories such as:
- Blocker: incorrect, unsafe, or too risky to merge
- Should fix: important quality issue but not catastrophic
- Nice to improve: readability or maintainability improvement
- Question: clarification needed before confidence is high
That keeps the review actionable.
Adjacent skill boundaries
- code-implementer: writes the change; this skill reviews it
- backend-dev / frontend-dev / fullstack-dev: may provide domain-specific implementation; this skill provides review discipline across the change
- security-auditor: deeper security review beyond general code review scope
- project-architect: higher-level structural guidance; this skill focuses on the actual proposed change
Quality bar
A strong result should:
- catch real correctness or regression risks
- prioritize findings by impact
- avoid drowning the author in low-value nitpicks
- explain why issues matter
- make a defensible merge recommendation
- improve both code quality and team velocity
References to use
Use prompt.md for review posture and comment style.
Use guides/qa-checklist.md before finalizing.
Use examples/README.md for output patterns.
Use meta/skill.json for boundaries and metadata.
