| name | ctx-code-review |
| description | Review code changes for correctness, edge cases, and convention adherence. Use when the user asks to review code, a diff, a PR, or says 'review this'. |
| allowed-tools | Read, Grep, Glob, Bash(git:*) |
Review the specified code change focusing on substance over style.
When to Use
- User says "review this code", "review this change", "code review"
- User asks for feedback on a diff, PR, or set of changes
- User says "what do you think of this?"
When NOT to Use
- User wants a full PR review with GitHub integration — if
you have an external PR-review skill (the GitNexus suite
ships
/gitnexus-pr-review), invoke it instead
- User wants an architecture-level review (use
/ctx-architecture)
Review Checklist
Work through each dimension. Flag issues, don't fix them unless asked.
- Correctness: Does the logic do what it claims? Off-by-one
errors, nil dereferences, race conditions?
- Edge cases: What happens with empty input, max values,
concurrent access, or partial failures?
- Naming clarity: Do function, variable, and type names
communicate intent without needing comments?
- Test coverage gaps: What behavior is untested? What inputs
would exercise uncovered paths?
- Convention adherence: Does this follow the project patterns
documented in
.context/CONVENTIONS.md?
Execution
- Read
.context/CONVENTIONS.md to load project patterns
- Identify the scope: file(s), diff, or recent changes
- If no specific target, check
git diff for unstaged changes
- Work through each checklist dimension
- Present findings grouped by severity: bugs > logic gaps >
conventions > style observations
Output Format
Lead with the most important finding. Use this structure:
## Review: <scope>
### Issues
- **[severity]** file:line - description
### Observations
- Note anything non-obvious but not necessarily wrong
### Verdict
One sentence: ship it, fix N issues first, or needs rethink.
Flag but don't fix style issues. Focus review on substance over
formatting.
