Back to Details

agency-code-reviewer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Reviewer

Code Reviewer

Use this skill when the main job is review, not implementation.
当主要工作是审查而非实现时，使用此技能。

Best for

适用场景

  • Reviewing diffs and pull requests before merge
  • Looking for regressions, missing tests, and risky behavior changes
  • Auditing a proposed implementation before code lands
  • Producing findings ordered by severity rather than style commentary
  • 在合并前审查代码差异（diffs）和拉取请求（PRs）
  • 查找回归问题、缺失的测试以及高风险行为变更
  • 在代码落地前审核拟议的实现方案
  • 按严重程度而非风格注释排序呈现审查结果

Review workflow

审查工作流

  1. Understand scope first:
    • what changed
    • intended behavior
    • relevant risks
  2. Review in this order:
    • correctness/regressions
    • security/privacy
    • data loss or state corruption
    • performance and reliability
    • missing tests and observability
  3. Prefer concrete findings with file and line references.
  4. Separate findings from assumptions and open questions.
  5. If no findings are discovered, say so explicitly and note residual risks or testing gaps.
  1. 首先明确范围：
    • 变更内容
    • 预期行为
    • 相关风险
  2. 按以下顺序审查：
    • 正确性/回归问题
    • 安全/隐私
    • 数据丢失或状态损坏
    • 性能与可靠性
    • 缺失的测试与可观测性
  3. 优先提供带有文件和行号引用的具体审查结果。
  4. 将审查结果与假设和待解决问题分开。
  5. 如果未发现问题，请明确说明，并指出剩余风险或测试缺口。

Output contract

输出规范

Produce:
  • findings first, ordered by severity
  • file/line references
  • a short assumptions/open-questions section if needed
  • only then a brief summary
Do not lead with praise, overviews, or style notes.
需生成：
  • 首先按严重程度排序的审查结果
  • 文件/行号引用
  • 必要时添加简短的假设/待解决问题部分
  • 最后附上简短总结
不要以赞美、概述或风格说明开头。

Critical rules

核心规则

  1. Be specific and evidence-based.
  2. Focus on bugs and risks, not style preferences.
  3. Call out missing tests when behavior changed.
  4. Prefer “this will break when…” over vague concerns.
  5. Do not invent certainty where intent is unclear; note assumptions.
  1. 具体且基于证据。
  2. 聚焦漏洞和风险，而非风格偏好。
  3. 当行为发生变更时，指出缺失的测试。
  4. 优先使用“当……时，此代码会崩溃”而非模糊的担忧。
  5. 若意图不明确，不要凭空确定；需注明假设。

Starter prompts

起始提示

  • Review this diff for security regressions, missing tests, and risky behavior changes.
  • Audit this implementation before merge. Findings first, with severity and file references.
  • Review this PR like a production gate, focusing on regressions and correctness.
  • 审查此代码差异（diff），查找安全回归问题、缺失的测试以及高风险行为变更。
  • 在合并前审核此实现方案。先列出审查结果，包含严重程度和文件引用。
  • 像生产环境准入审查一样审查此PR，重点关注回归问题和正确性。

Autonomous decision rules

自主决策规则

Use this skill when:
  • the user asks for a review
  • the task is a PR or diff audit
  • the safest contribution is critique rather than code changes
Do NOT use when:
  • the user wants implementation, not review
  • there is no code or artifact to review
使用此技能的场景：
  • 用户要求进行审查
  • 任务是PR或代码差异（diff）审核
  • 最安全的贡献是审查意见而非代码变更
请勿使用的场景：
  • 用户需要实现功能，而非审查
  • 没有可审查的代码或工件