| name | code-change-review |
| description | Review AI-generated code changes for unintended consequences, logic errors, UI inconsistencies, and context-specific issues. Use when: code has just been modified, flag potential bugs, verify UI consistency, check implementation correctness against project patterns. |
| argument-hint | Describe the change or file(s) to review |
| user-invocable | true |
| disable-model-invocation | false |
Code Change Review
When to Use
- After AI agents make modifications to code
- Before committing changes to verify quality
- When suspicious about consistency or hidden impacts
- Testing cross-cutting effects (styling, state management, routing)
- UI/UX quality check for visual consistency
Philosophy
The best changes are the ones that appear invisible — they fit seamlessly into the existing codebase without standing out. This skill helps ensure changes follow project patterns, don't introduce unnecessary complexity, and don't break subtle invariants.
Step-by-Step Procedure
- Understand the request and scan the diff.
- Review logic paths, side effects, and edge cases.
- Review UI consistency if presentation changed.
- Check integrations, configuration impact, and documentation needs.
- Report concrete findings with severity and suggested fixes.
Use workflow.md for the full checklists and detailed review sequence.
Output
Produce a review report with:
- Findings ranked by severity
- Why each issue matters
- Suggested fix or mitigation
- Any remaining risks or testing gaps
Common Red Flags
Watch for these patterns when reviewing AI-generated changes:
| Red Flag | What It Means | Check |
|---|
| Overly defensive code | Too many null checks, type guards for things that shouldn't be null | Traces assumptions — are they valid? |
| New utility function doing work that exists elsewhere | Code duplication or missing abstraction | Search for similar logic in codebase |
| Magic numbers or strings | Hardcoded values that should be constants/config | Find where same values defined elsewhere |
| Nested ternaries or complex conditionals | Hard to reason about logic | Simplify to guard clauses or early returns |
| Inconsistent error handling | mix of try/catch, if-checks, silent failures | Standardize to project's error pattern |
| Unused variables after refactor | Leftover declarations | Search for actual usage |
| New dependency added without thought | Library bloat or version conflicts | Check if something similar exists in project |
| State mutation in pure function context | Unexpected side effects | Check whether function should be pure |
| CSS specificity arms race | !important, deeply nested selectors, inline styles | Migrate to design system utilities |
| Component too complex | Too many props, state, or nested children | Consider splitting or simplifying |
For concrete examples of negative patterns to avoid and positive patterns to follow, see Pattern Reference.
Example Usage Prompts
/code-change-review -> "Review this change for bugs or issues I might have missed"/code-change-review -> "Check if this implementation fits our codebase patterns"/code-change-review -> "Look for UI inconsistencies in this component"
Quick Reference
For quick reviews: Use the Common Red Flags table and spot-check 2-3 items.
For thorough reviews: Walk through workflow.md systematically.
For UI-heavy changes: Use the UI checklist in workflow.md.
For complex logic: Use the logic checklist in workflow.md and trace execution paths carefully.
References
