メニュー
当用户要求 review diff 或 pull request、撰写 review comment、审计代码质量、建立 review 标准，或改进团队 code review 方式时使用。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | code-review-excellence |
| description | 当用户要求 review diff 或 pull request、撰写 review comment、审计代码质量、建立 review 标准，或改进团队 code review 方式时使用。 |
| version | 0.1.0 |
把 code review 从“卡门槛”转成知识共享过程，依靠建设性反馈、系统分析和协作改进来提升质量。
Code Review 的目标：
不是目标：
好的反馈应当：
❌ Bad: "This is wrong."
✅ Good: "This could cause a race condition when multiple users
access simultaneously. Consider using a mutex here."
❌ Bad: "Why didn't you use X pattern?"
✅ Good: "Have you considered the Repository pattern? It would
make this easier to test. Here's an example: [link]"
❌ Bad: "Rename this variable."
✅ Good: "[nit] Consider `userCount` instead of `uc` for
clarity. Not blocking if you prefer to keep it."
该 review 的内容：
不需要手工 review 的内容：
如果存在 plan package 或 contract.json，先读取其中的目标、非目标、reviewer 关注边界和验收标准。Review 结论必须覆盖这些边界，不要只从 diff 风格或测试状态推断完成度。
Architecture & Design
File Organization
Testing Strategy
按文件逐项检查：
Findings must come first and be ordered by severity. Each blocking finding should include a concrete file/line reference, the behavioral risk, and the smallest acceptable fix. Avoid presenting style-only comments as blockers unless they create maintainability or correctness risk.
## Security Checklist
- [ ] User input validated and sanitized
- [ ] SQL queries use parameterization
- [ ] Authentication/authorization checked
- [ ] Secrets not hardcoded
- [ ] Error messages don't leak info
## Performance Checklist
- [ ] No N+1 queries
- [ ] Database queries indexed
- [ ] Large lists paginated
- [ ] Expensive operations cached
- [ ] No blocking I/O in hot paths
## Testing Checklist
- [ ] Happy path tested
- [ ] Edge cases covered
- [ ] Error cases tested
- [ ] Test names are descriptive
- [ ] Tests are deterministic
与其直接判定，不如用问题引导作者思考：
❌ "This will fail if the list is empty."
✅ "What happens if `items` is an empty array?"
❌ "You need error handling here."
✅ "How should this behave if the API call fails?"
用协作语言，不用命令口吻。
建议在评论中标清优先级：
[blocking][important][nit][suggestion][learning][praise]重点关注：
except: 过宽super().__init__() 是否遗漏重点关注：
any 滥用对较大变更：
优先 review 行为而不是实现细节：
关注：
eval、secret、CSRF、rate limit）比传统 praise-sandwich 更自然，也更有效。
当作者不同意时：
## Summary
[Brief overview of what was reviewed]
## Strengths
- [What was done well]
## Required Changes
🔴 [Blocking issue 1]
## Suggestions
💡 [Improvement 1]
## Questions
❓ [Clarification needed on X]
## Verdict
✅ Approve after addressing required changes
references/code-review-best-practices.md：完整 review 指南references/common-bugs-checklist.md：各语言常见 bug 清单references/security-review-guide.md：安全 review 清单assets/pr-review-template.md：标准 review comment 模板assets/review-checklist.md：快速 checklistscripts/pr-analyzer.py：分析 PR 复杂度并建议 reviewer