智能群集PR评审Skill dyad:swarm-pr-review

---

名称：dyad:swarm-pr-review 描述：使用Claude Code群集进行团队化PR评审。产生三个专家队友（正确性专家、代码健康专家、UX向导），评审PR差异，相互讨论发现，并达成共识。发布总结评论和针对高/中问题的行内评论。

群集PR评审

此技能使用Claude Code的代理团队（群集）功能，执行协作式PR评审，由三个专业评审员讨论并达成共识。

概述

1. 获取PR差异和现有评论
2. 创建一个评审团队，包含3个专业队友
3. 每个队友从其专业视角评审差异
4. 队友讨论发现以达成共识
5. 团队领导编译最终评审和合并决定
6. 发布总结评论和行内评论到GitHub

团队成员

名称	角色	聚焦点
correctness-reviewer	正确性与调试专家	错误、边界情况、控制流、安全、错误处理
code-health-reviewer	代码健康专家	死代码、重复、复杂度、有意义的注释、抽象
ux-reviewer	UX向导	用户体验、一致性、可访问性、错误状态、愉悦度

工作流程

步骤1：确定PR编号和仓库

解析用户输入中的PR编号和仓库。如果未提供，尝试从当前git上下文中推断：

# 获取当前仓库
gh repo view --json nameWithOwner -q '.nameWithOwner'

# 如果用户提供PR URL，提取编号
# 如果用户只说“review this PR”，检查当前分支的PR
gh pr view --json number -q '.number'

步骤2：获取PR差异和上下文

重要： 始终保存文件到当前工作目录（例如 ./pr_diff.patch），不要保存到 /tmp/ 或仓库外的目录。在CI中，只有仓库工作目录可访问。

# 保存差异到当前工作目录（非 /tmp/ 或 $SCRATCHPAD）
gh pr diff <PR_NUMBER> --repo <OWNER/REPO> > ./pr_diff.patch

# 获取PR元数据
gh pr view <PR_NUMBER> --repo <OWNER/REPO> --json title,body,files,headRefOid

# 获取现有评论以避免重复
gh api repos/<OWNER/REPO>/pulls/<PR_NUMBER>/comments --paginate
gh api repos/<OWNER/REPO>/issues/<PR_NUMBER>/comments --paginate

保存差异内容和现有评论以供评审使用。

步骤3：创建评审团队

使用 TeamCreate 创建团队：

TeamCreate:
  team_name: "pr-review-<PR_NUMBER>"
  description: "PR #<PR_NUMBER> 的代码评审"

步骤4：创建评审任务

创建4个任务：

1. “评审PR以发现正确性问题” - 分配给正确性评审员
2. “评审PR以发现代码健康问题” - 分配给代码健康评审员
3. “评审PR以发现UX问题” - 分配给UX评审员
4. “讨论并达成共识” - 依赖任务1-3，无所有者（团队范围）

步骤5：生成队友

使用 Task 工具并设置 team_name，并行生成所有3个队友。每个队友应为 general-purpose 子代理。

重要： 每个队友的提示必须包括：

1. 角色描述（来自 references/ 的对应文件）
2. 完整的PR差异内容（内联，非文件路径 - 队友无法读取团队领导的暂存文件）
3. 现有PR评论列表（以便避免重复）
4. 以结构化消息发送发现的指令

队友提示模板

对于每个队友，提示应遵循此结构：

您是一个PR评审团队中的 [角色名称]。仔细阅读您的角色描述：

<role>
[references/<role>.md 的内容]
</role>

您正在评审仓库 <REPO> 中的 PR #<编号>：“<PR标题>”

<pr_description>
[PR主体/描述]
</pr_description>

以下是待评审的差异：

<diff>
[完整的差异内容]
</diff>

以下是现有PR评论（不要标记已评论的问题）：

<existing_comments>
[现有评论数据]
</existing_comments>

## 指令

1. 仔细阅读您的角色描述，并从您的专业视角评审差异。
2. 对于每个发现的问题，根据角色描述指南分类为高、中或低严重性。
3. 使用SendMessage发送您的发现给团队领导，格式如下：

FINDINGS:
```json
[
  {
    "file": "路径/到/文件.ts",
    "line_start": 42,
    "line_end": 45,
    "severity": "MEDIUM",
    "category": "category-name",
    "title": "简要标题",
    "description": "问题及其影响的清晰描述",
    "suggestion": "修复建议（可选）"
  }
]

4. 发送初始发现后，等待团队领导共享其他评审员的发现。
5. 收到其他评审员的发现时，讨论它们：
   • 认可您同意的问题（即使您错过了）
   • 挑战您认为是误报或错误严重性的问题
   • 添加您的专业知识以增强或削弱问题
6. 发送您的讨论响应给团队领导。

彻底但专注。只标记真正的问题，而非伪装为问题的挑剔。

重要： 交叉引用基础设施变更（DB迁移、新表/列、API端点、配置项）与差异中的实际使用。如果迁移创建表但PR中没有代码读取或写入，则为死基础设施，应标记。

### 步骤6：收集初始评审

等待所有3个队友发送初始发现。解析每个队友消息中的JSON。

### 步骤7：促进讨论

所有初始评审就绪后：

1. 向每个队友发送包含所有评审员发现的消息（标记谁发现的）
2. 要求他们讨论：认可、挑战或添加上下文
3. 等待讨论响应

发给每个队友的消息应类似：

所有初始评审已就绪。以下是所有三个评审员的发现：

正确性评审员发现：

[问题列表]

代码健康评审员发现：

[问题列表]

UX评审员发现：

[问题列表]

请从您的专业视角评审其他评审员的发现：

• 认可您同意是真实问题的（说“认可：<标题> - <原因>”）
• 挑战您认为是误报或错误分类的（说“挑战：<标题> - <原因>”）
• 如果您有额外上下文改变严重性，解释原因

聚焦于您的专业知识增加价值的问题。您无需评论每个问题。

### 步骤8：编译共识

讨论后，编译最终问题列表：

**问题分类规则：**
- 如果原始报告者和至少1个其他评审员认可（或无人挑战），问题确认为**确认**
- 如果2个评审员以有效推理挑战，问题为**丢弃**
- 如果以良好推理挑战严重性，问题为**降级**
- 高/中问题获得单独的行内评论
- 低问题放在总结中的可折叠细节部分

### 步骤9：确定合并决定

基于确认的问题：

- **:white_check_mark: 是 - 准备合并**：无高问题，最多有判断性中问题
- **:thinking: 不确定 - 潜在问题**：有中问题可能应解决，但无明确阻塞
- **:no_entry: 否 - 不合并**：有高严重性问题或多个严重中问题需修复

### 步骤10：发布GitHub评论

#### 总结评论

在PR上发布总结评论使用 `gh pr comment`：

```markdown
## :mag: Dyadbot代码评审总结

**决定：[决定表情 + 文本]**

由3个专业代理评审：正确性专家、代码健康专家、UX向导。

### 问题总结

| # | 严重性 | 文件 | 问题 | 发现者 | 认可者 |
|---|----------|------|-------|----------|-------------|
| 1 | :red_circle: 高 | `src/auth.ts:45` | 登录中的SQL注入 | 正确性 | 代码健康 |
| 2 | :yellow_circle: 中 | `src/ui/modal.tsx:12` | 缺失加载状态 | UX | 正确性 |
| 3 | :yellow_circle: 中 | `src/utils.ts:89` | 重复验证逻辑 | 代码健康 | - |

<details>
<summary>:green_circle: 低优先级备注 (X项)</summary>

- **次要命名不一致** - `src/helpers.ts:23` (代码健康)
- **可添加悬停状态** - `src/button.tsx:15` (UX)

</details>

<details>
<summary>:no_entry_sign: 丢弃问题 (X项)</summary>

- **~~潜在竞态条件~~** - 被代码健康挑战：“在此上下文中状态仅同步访问”

</details>

---
*由Dyadbot代码评审生成*

行内评论

对于每个高和中问题，在相关行发布行内评论使用 gh api：

# 发布带有行内评论的评审
gh api repos/<OWNER/REPO>/pulls/<PR_NUMBER>/reviews \
  -X POST \
  --input payload.json

其中payload.json包含：

{
  "commit_id": "<HEAD_SHA>",
  "body": "群集评审：发现X问题",
  "event": "COMMENT",
  "comments": [
    {
      "path": "src/auth.ts",
      "line": 45,
      "body": "**:red_circle: 高** | 安全 | 发现者：正确性，认可者：代码健康

**登录中的SQL注入**

问题描述...

:bulb: **建议：** 使用参数化查询"
    }
  ]
}

步骤11：关闭团队

发布评论后：

1. 向所有队友发送关闭请求
2. 等待关闭确认
3. 使用TeamDelete删除团队

去重

发布前，过滤匹配现有PR评论的问题：

• 相同文件路径
• 相同或附近行号（3行内）
• 问题标题中的相似关键词出现在现有评论正文

错误处理

• 如果队友无响应，继续其他评审员的发现
• 如果无人发现问题，发布干净总结“:white_check_mark: 无问题发现”
• 如果讨论显示所有问题都是误报，仍发布总结注明评审干净
• 即使无问题，始终发布总结评论
• 完成后始终关闭团队，即使有错误

文件结构

references/
  correctness-reviewer.md  - 正确性专家的角色描述
  code-health-reviewer.md  - 代码健康专家的角色描述
  ux-reviewer.md           - UX向导的角色描述