Menu
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Guides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error.
Builds production-quality chart UIs. Use when building or modifying user-facing visualizations. Use when creating chart modules, implementing layouts, or when the output needs to look and feel production-quality.
Delivers changes incrementally via TDD. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.
Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea.
Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.
| name | code-review-and-quality |
| description | Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. |
Multi-dimensional code review with quality gates. Every change gets reviewed before merge. Review covers five axes: correctness, readability, architecture, security, and performance.
The approval standard: Approve a change when it definitely improves overall code health, even if it isn't perfect.
Every review must verify TDD compliance:
Flag any PR that adds functionality without corresponding tests.
~100 lines changed → Good. Reviewable in one sitting.
~300 lines changed → Acceptable if it's a single logical change.
~1000 lines changed → Too large. Split it.
| Prefix | Meaning | Author Action |
|---|---|---|
| (no prefix) | Required change | Must address before merge |
| Critical: | Blocks merge | Security, data loss, broken functionality |
| Nit: | Minor, optional | Author may ignore |
| Optional: | Suggestion | Worth considering |
| FYI | Informational | No action needed |
## Review: [Change title]
### TDD Compliance
- [ ] Failing tests written before implementation
- [ ] Tests cover the change adequately
- [ ] Bug fixes include reproduction tests
### Correctness
- [ ] Change matches spec/task requirements
- [ ] Edge cases handled
### Readability
- [ ] Names are clear and consistent
- [ ] Logic is straightforward
- [ ] Follows Prettier formatting
### Architecture
- [ ] Follows existing gsm.viz module patterns
- [ ] Data transforms separated from rendering
### Security
- [ ] No secrets in code
- [ ] External data validated
### Performance
- [ ] No unnecessary re-renders
- [ ] No unbounded operations
### Verification
- [ ] Tests pass: npm test
- [ ] Build succeeds: npm run bundle
| Rationalization | Reality |
|---|---|
| "It works, that's good enough" | Working code without tests creates debt that compounds. |
| "We'll add tests later" | Later never comes. TDD means tests come first. |
| "AI-generated code is probably fine" | AI code needs more scrutiny, not less. |