Back to Details

qe-pr-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

name: pr-review description: Scope-aware GitHub PR review with user-friendly tone and trust tier validation trust_tier: 3 domain: code-review

name: pr-review description: 具备范围感知能力的GitHub PR评审，采用友好语气并验证信任等级 trust_tier: 3 domain: code-review

PR Review Workflow

PR评审工作流

Review pull requests with correct AQE scope boundaries, clear communication, and actionable feedback.
按照正确的AQE范围边界评审拉取请求，沟通清晰，反馈切实可行。

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 (~75 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涉及技能修改，验证技能数量/范围是否符合预期（约75个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的分配是否正确：
  • 等级3 = 具备评估基础设施（evals/、schemas/、scripts/目录）
  • 等级2 = 已测试但无评估框架
  • 等级1 = 未测试
  • 标记不一致的情况（例如，具备评估目录的技能却被标记为等级2，应改为等级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