菜单
当用户要求 review diff 或 pull request、撰写 review comment、审计代码质量、建立 review 标准，或改进团队 code review 方式时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the user asks to generate or refresh an architecture map, structure diagram, core call flow, local viewer assets, or runs ~map. Produces hello-scholar native architecture-map.json plus compact Markdown and Mermaid companion artifacts.
Use when the user asks to open the architecture viewer, view diagrams, inspect node evidence, export the local architecture map, or troubleshoot hello-scholar map view/export behavior.
实验分析命令，基于 experiment package、runs、metrics 和 evidence 形成结果解释与下一轮实验计划。
实现命令，把 plan package、change record 或 experiment package 落成代码、配置、文档或实验变更。
Use only when the user explicitly types ~map. Generates or refreshes the hello-scholar native architecture map by invoking the architecture-map workflow, then validates and points to the local viewer.
用于涉及编写或修改源码的日常编码任务。
| 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