ctx-code-review

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 (use /gitnexus-pr-review instead)
• User wants an architecture-level review (use /ctx-architecture)

Review Checklist

Work through each dimension. Flag issues, don't fix them unless asked.

1. Correctness: Does the logic do what it claims? Off-by-one errors, nil dereferences, race conditions?
2. Edge cases: What happens with empty input, max values, concurrent access, or partial failures?
3. Naming clarity: Do function, variable, and type names communicate intent without needing comments?
4. Test coverage gaps: What behavior is untested? What inputs would exercise uncovered paths?
5. Convention adherence: Does this follow the project patterns documented in .context/CONVENTIONS.md?

Execution

1. Read .context/CONVENTIONS.md to load project patterns
2. Identify the scope: file(s), diff, or recent changes
3. If no specific target, check git diff for unstaged changes
4. Work through each checklist dimension
5. 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.