Back to Details

pr-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PR Review Workflow

PR评审工作流

Review pull requests with correct AQE scope boundaries, clear communication, and actionable feedback.
按照正确的AQE范围边界、清晰沟通方式和可执行反馈来评审拉取请求（PR）。

Arguments

参数

  • <pr-number>
    — GitHub PR number to review. If omitted, prompt the user.
  • <pr-number>
    — 要评审的GitHub PR编号。如果省略，请提示用户。

Steps

步骤

1. Read the Full Diff

1. 阅读完整差异

bash
gh pr diff <pr-number>
gh pr view <pr-number>
Read the complete diff and PR description. Do not skim — read every changed file.
bash
gh pr diff <pr-number>
gh pr view <pr-number>
阅读完整的差异内容和PR描述。不要略读——查看每一个被修改的文件。

2. Scope Check

2. 范围检查

  • Only analyze AQE/QE skills (NOT Claude Flow platform skills)
  • Platform skills to EXCLUDE: v3-, flow-nexus-, agentdb-, reasoningbank-, swarm-, github-, hive-mind-advanced, hooks-automation, iterative-loop, stream-chain, skill-builder, sparc-methodology, pair-programming, release, debug-loop, aqe-v2-v3-migration
  • If the PR touches skills, verify the count/scope matches expectations (~78 AQE skills)
  • Flag any platform skill changes that may have leaked into an AQE-focused PR
  • 仅分析AQE/QE技能（不包括Claude Flow平台技能）
  • 需要排除的平台技能：v3-, flow-nexus-, agentdb-, reasoningbank-, swarm-, github-, hive-mind-advanced, hooks-automation, iterative-loop, stream-chain, skill-builder, sparc-methodology, pair-programming, release, debug-loop, aqe-v2-v3-migration
  • 如果PR涉及技能修改，验证技能数量/范围是否符合预期（约78个AQE技能）
  • 标记任何可能混入AQE专项PR中的平台技能变更

3. Summarize Changes

3. 变更总结

Write a user-friendly summary of what changed and why:
  • Focus on outcomes, not implementation details
  • Avoid overly technical jargon
  • Keep it to 3-5 bullet points
用用户友好的风格总结变更内容及原因：
  • 聚焦成果，而非实现细节
  • 避免过于技术化的术语
  • 控制在3-5个要点以内

4. Trust Tier Validation

4. 信任层级验证

For any skill changes, validate trust_tier assignments:
  • tier 3 = has eval infrastructure (evals/, schemas/, scripts/)
  • tier 2 = tested but no eval framework
  • tier 1 = untested
  • Flag inconsistencies (e.g., a skill with evals at tier 2 should be tier 3)
对于任何技能变更，验证trust_tier的分配：
  • tier 3 = 具备评估基础设施（evals/、schemas/、scripts/）
  • tier 2 = 已测试但无评估框架
  • tier 1 = 未测试
  • 标记不一致情况（例如，带有评估模块的技能被标记为tier 2，应调整为tier 3）

5. Code Quality Review

5. 代码质量评审

Check for:
  • Hardcoded version strings
  • Production safety concerns (adapter changes, breaking changes)
  • Missing test coverage for new code
  • Security issues (exposed secrets, injection risks)
检查以下内容：
  • 硬编码的版本字符串
  • 生产环境安全问题（适配器变更、破坏性变更）
  • 新代码缺失测试覆盖
  • 安全问题（暴露的密钥、注入风险）

6. Post Review

6. 提交评审

bash
gh pr review <pr-number> --body "review comments"
bash
gh pr review <pr-number> --body "review comments"

Communication Rules

沟通规则

  • Keep tone constructive and actionable
  • Be outcome-focused: what should the author do, not what's wrong
  • Group related comments together instead of posting many small ones
  • If approving with minor suggestions, use APPROVE with comments, not REQUEST_CHANGES
  • 保持语气建设性且具备可执行性
  • 聚焦成果：告知作者应做什么，而非单纯指出问题
  • 将相关评论分组，而非发布大量零散评论
  • 如果仅需提出微小建议即可批准，使用APPROVE并附带评论，而非REQUEST_CHANGES