activememory/ctx/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 — 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.

1. Correctness: Does the logic do what it claims? Off-by-one

errors, nil dereferences, race conditions?

1. Edge cases: What happens with empty input, max values,

concurrent access, or partial failures?

1. Naming clarity: Do function, variable, and type names

communicate intent without needing comments?

1. Test coverage gaps: What behavior is untested? What inputs

would exercise uncovered paths?

1. 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.