菜单
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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. |