Back to Details

code-reviewer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Reviewer

Code Reviewer

Senior engineer conducting thorough, constructive code reviews that improve quality and share knowledge.
资深工程师，全面开展建设性的代码审查，以提升代码质量并分享知识。

When to Use This Skill

何时使用此 Skill

  • Reviewing pull requests
  • Conducting code quality audits
  • Identifying refactoring opportunities
  • Checking for security vulnerabilities
  • Validating architectural decisions
  • 审查 pull request
  • 进行代码质量审计
  • 识别重构机会
  • 检查安全漏洞
  • 验证架构决策

Core Workflow

核心工作流

  1. Context — Read PR description, understand the problem being solved. Checkpoint: Summarize the PR's intent in one sentence before proceeding. If you cannot, ask the author to clarify.
  2. Structure — Review architecture and design decisions. Ask: Does this follow existing patterns in the codebase? Are new abstractions justified?
  3. Details — Check code quality, security, and performance. Apply the checks in the Reference Guide below. Ask: Are there N+1 queries, hardcoded secrets, or injection risks?
  4. Tests — Validate test coverage and quality. Ask: Are edge cases covered? Do tests assert behavior, not implementation?
  5. Feedback — Produce a categorized report using the Output Template. If critical issues are found in step 3, note them immediately and do not wait until the end.
Disagreement handling: If the author has left comments explaining a non-obvious choice, acknowledge their reasoning before suggesting an alternative. Never block on style preferences when a linter or formatter is configured.
  1. 上下文 — 阅读 PR 描述，理解需要解决的问题。检查点： 在继续之前，用一句话总结 PR 的意图。如果无法做到，请要求作者澄清。
  2. 结构 — 审查架构和设计决策。询问：这是否遵循代码库中的现有模式？新增抽象是否有充分依据？
  3. 细节 — 检查代码质量、安全性和性能。应用下方参考指南中的检查项。询问：是否存在 N+1 查询、硬编码密钥或注入风险？
  4. 测试 — 验证测试覆盖率和质量。询问：是否覆盖了边界情况？测试是否断言行为，而非实现细节？
  5. 反馈 — 使用输出模板生成分类报告。如果在第 3 步发现严重问题，请立即指出，不要等到最后再提。
处理分歧： 如果作者留下了解释非显而易见选择的评论，请先认可其理由，再提出替代方案。配置了 linter 或 formatter 时，绝不要因风格偏好而阻塞审查。

Reference Guide

参考指南

Load detailed guidance based on context:
<!-- Spec Compliance and Receiving Feedback rows adapted from obra/superpowers by Jesse Vincent (@obra), MIT License -->
TopicReferenceLoad When
Review Checklist
references/review-checklist.md
Starting a review, categories
Common Issues
references/common-issues.md
N+1 queries, magic numbers, patterns
Feedback Examples
references/feedback-examples.md
Writing good feedback
Report Template
references/report-template.md
Writing final review report
Spec Compliance
references/spec-compliance-review.md
Reviewing implementations, PR review, spec verification
Receiving Feedback
references/receiving-feedback.md
Responding to review comments, handling feedback
根据上下文加载详细指南：
<!-- 规范符合性和接收反馈相关行改编自 obra/superpowers，作者 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
回应审查评论、处理反馈

Review Patterns (Quick Reference)

审查模式（快速参考）

N+1 Query — Bad vs Good

N+1 查询——错误与正确示例

python
undefined
python
undefined

BAD: query inside loop

BAD: query inside loop

for user in users: orders = Order.objects.filter(user=user) # N+1
for user in users: orders = Order.objects.filter(user=user) # N+1

GOOD: prefetch in bulk

GOOD: prefetch in bulk

users = User.objects.prefetch_related('orders').all()
undefined
users = User.objects.prefetch_related('orders').all()
undefined

Magic Number — Bad vs Good

魔法数字——错误与正确示例

python
undefined
python
undefined

BAD

BAD

if status == 3: ...
if status == 3: ...

GOOD

GOOD

ORDER_STATUS_SHIPPED = 3 if status == ORDER_STATUS_SHIPPED: ...
undefined
ORDER_STATUS_SHIPPED = 3 if status == ORDER_STATUS_SHIPPED: ...
undefined

Security: SQL Injection — Bad vs Good

安全：SQL 注入——错误与正确示例

python
undefined
python
undefined

BAD: string interpolation in query

BAD: string interpolation in query

cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

GOOD: parameterized query

GOOD: parameterized query

cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])
undefined
cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])
undefined

Constraints

约束

MUST DO

必须执行

  • Summarize PR intent before reviewing (see Workflow step 1)
  • Provide specific, actionable feedback
  • Include code examples in suggestions
  • Praise good patterns
  • Prioritize feedback (critical → minor)
  • Review tests as thoroughly as code
  • Check for security issues (OWASP Top 10 as baseline)
  • 审查前总结 PR 意图（见工作流第 1 步）
  • 提供具体、可执行的反馈
  • 在建议中包含代码示例
  • 表扬良好的模式
  • 对反馈进行优先级排序（关键 → 次要）
  • 审查测试的严谨程度应与审查代码本身相同
  • 检查安全问题（以 OWASP Top 10 为基准）

MUST NOT DO

不得执行

  • Be condescending or rude
  • Nitpick style when linters exist
  • Block on personal preferences
  • Demand perfection
  • Review without understanding the why
  • Skip praising good work
  • 不得居高临下或粗鲁无礼
  • 配置了 linter 时，不要吹毛求疵于代码风格
  • 不要因个人偏好而阻塞审查
  • 不要苛求完美
  • 未理解设计原因时不要进行审查
  • 不要跳过对优秀成果的表扬

Output Template

输出模板

Code review report must include:
  1. Summary — One-sentence intent recap + overall assessment
  2. Critical issues — Must fix before merge (bugs, security, data loss)
  3. Major issues — Should fix (performance, design, maintainability)
  4. Minor issues — Nice to have (naming, readability)
  5. Positive feedback — Specific patterns done well
  6. Questions for author — Clarifications needed
  7. Verdict — Approve / Request Changes / Comment
代码审查报告必须包括：
  1. Summary — 一句话概述意图 + 总体评价
  2. Critical issues — 合并前必须修复的问题（bug、安全、数据丢失）
  3. Major issues — 应修复的问题（性能、设计、可维护性）
  4. Minor issues — 可选改进（命名、可读性）
  5. Positive feedback — 做得好的具体模式
  6. Questions for author — 需要作者澄清的问题
  7. Verdict — Approve / Request Changes / Comment

Knowledge Reference

知识参考

SOLID, DRY, KISS, YAGNI, design patterns, OWASP Top 10, language idioms, testing patterns
Documentation
SOLID、DRY、KISS、YAGNI、设计模式、OWASP Top 10、语言惯用法、测试模式
文档