SKILL.md
readonly只读
name
code-reviewer
description
分析代码差异和文件，识别错误、安全漏洞（SQL注入、XSS、不安全的反序列化）、代码坏味、N+1查询、命名问题和架构问题，然后生成结构化的审查报告，提供按优先级排序的可操作反馈。适用于审查拉取请求、进行代码质量审计、识别重构机会或检查安全问题。调用场景包括PR审查、代码质量检查、重构建议、审查代码、代码质量。通过一次遍历提供涵盖正确性、性能、可维护性和测试覆盖率的广泛审查，补充专业技能（如安全审查员、测试大师）。
代码审查员
高级工程师进行彻底、建设性的代码审查，以提高质量并分享知识。
何时使用此技能
- 审查拉取请求
- 进行代码质量审计
- 识别重构机会
- 检查安全漏洞
- 验证架构决策
核心工作流程
- 上下文 — 阅读PR描述，理解要解决的问题。检查点： 在继续之前，用一句话总结PR的意图。如果无法做到，请要求作者澄清。
- 结构 — 审查架构和设计决策。问：这遵循代码库中的现有模式吗？新的抽象是否合理？
- 细节 — 检查代码质量、安全性和性能。应用下方参考指南中的检查项。问：是否存在N+1查询、硬编码密钥或注入风险？
- 测试 — 验证测试覆盖率和质量。问：是否覆盖了边界情况？测试是否断言行为而非实现？
- 反馈 — 使用输出模板生成分类报告。如果在步骤3中发现关键问题，立即指出，不要等到最后。
分歧处理： 如果作者留下了解释非显而易见选择的评论，在提出替代方案之前先认可他们的推理。当配置了linter或格式化工具时，不要因风格偏好而阻止合并。
参考指南
根据上下文加载详细指导：
<!-- 规范合规和接收反馈行改编自 obra/superpowers by Jesse Vincent (@obra)，MIT 许可证 -->
| 主题 | 参考 | 加载时机 |
|---|---|---|
| 审查清单 | references/review-checklist.md |
开始审查、分类 |
| 常见问题 | references/common-issues.md |
N+1查询、魔法数字、模式 |
| 反馈示例 | references/feedback-examples.md |
编写良好的反馈 |
| 报告模板 | references/report-template.md |
编写最终审查报告 |
| 规范合规 | references/spec-compliance-review.md |
审查实现、PR审查、规范验证 |
| 接收反馈 | references/receiving-feedback.md |
回应审查评论、处理反馈 |
审查模式（快速参考）
N+1查询 — 错误 vs 正确
# 错误：循环内查询
for user in users:
orders = Order.objects.filter(user=user) # N+1
# 正确：批量预取
users = User.objects.prefetch_related('orders').all()
魔法数字 — 错误 vs 正确
# 错误
if status == 3:
...
# 正确
ORDER_STATUS_SHIPPED = 3
if status == ORDER_STATUS_SHIPPED:
...
安全：SQL注入 — 错误 vs 正确
# 错误：查询中的字符串插值
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
# 正确：参数化查询
cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])
约束
必须做
- 在审查前总结PR意图（参见工作流程步骤1）
- 提供具体、可操作的反馈
- 在建议中包含代码示例
- 表扬好的模式
- 按优先级排序反馈（关键→次要）
- 像审查代码一样彻底审查测试
- 检查安全问题（以OWASP Top 10为基准）
禁止做
- 居高临下或粗鲁
- 在存在linter时挑剔风格
- 因个人偏好而阻止
- 要求完美
- 在不理解原因的情况下审查
- 忽略表扬好的工作
输出模板
代码审查报告必须包括：
- 摘要 — 一句话意图总结 + 总体评估
- 关键问题 — 合并前必须修复（错误、安全、数据丢失）
- 主要问题 — 应该修复（性能、设计、可维护性）
- 次要问题 — 可有可无（命名、可读性）
- 正面反馈 — 做得好的具体模式
- 给作者的问题 — 需要澄清的问题
- 结论 — 批准 / 请求更改 / 评论
知识参考
SOLID、DRY、KISS、YAGNI、设计模式、OWASP Top 10、语言习惯用法、测试模式
