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