name: dyad:multi-pr-review description: 多代理代码审查系统，产生三个独立的Claude子代理来审查PR差异。每个代理以不同的随机顺序接收文件以减少顺序偏差。一个代理专门关注代码健康和可维护性。问题通过推理分析验证，而不是简单的投票计数。报告合并裁决（是/不确定/否）。自动去重现有PR评论。总是发布摘要（即使没有新问题），低优先级问题在可折叠部分。
多代理PR审查
此技能产生三个独立的子代理，从不同角度审查代码更改，然后通过推理分析验证和汇总它们的发现。
概述
- 获取PR差异和现有评论
- 使用Task工具并行产生3个子代理，具有专门角色
- 每个代理以不同的随机顺序接收文件以减少顺序偏差
- 正确性专家：错误、边缘情况、控制流、安全、错误处理
- 代码健康专家：死代码、重复、复杂性、有意义的注释、抽象
- UX向导：用户体验、一致性、可访问性、错误状态、愉悦感
- 每个代理审查并分类问题（高/中/低严重性）
- 使用推理分析验证问题（不仅仅是投票计数）
- 基于确认的问题确定合并裁决
- 过滤掉已评论的问题（去重）
- 发布发现：摘要与裁决 + 高/中问题的内联评论
工作流程
步骤1：确定PR编号和仓库
从用户输入解析PR编号和仓库。如果未提供，尝试从当前git上下文推断：
# 获取当前仓库
gh repo view --json nameWithOwner -q '.nameWithOwner'
# 如果用户提供PR URL，提取编号
# 如果用户只说“审查此PR”，检查当前分支PR
gh pr view --json number -q '.number'
步骤2：获取PR差异和上下文
重要：始终将文件保存到当前工作目录（例如./pr_diff.patch），而不是/tmp/或仓库外的其他目录。在CI中，只有仓库工作目录可访问。
# 将差异保存到当前工作目录（非/tmp/）
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：并行产生审查代理
使用Task工具并行产生3个子代理（在单个消息中通过多个Task工具调用）。每个代理应为general-purpose子代理。
文件排序：在产生之前，为更改的文件创建3种不同的排序（随机化/打乱顺序）。每个代理以不同顺序接收文件以减少顺序偏差（审查者倾向于更关注首先看到的文件）。
重要：每个代理的提示必须包括：
- 它们的角色描述（来自
references/中的相应文件） - 完整的PR差异内容（内联，非文件路径 - 代理无法从父上下文读取文件）
- 现有PR评论列表（以便避免标记已评论的问题）
- 输出发现为结构化JSON的指令
代理提示模板
对于每个代理，提示应遵循此结构：
您是具有此专业化的代码审查者：
<role>
[references/<role>.md的内容 - 例如，correctness-reviewer.md]
</role>
您正在审查<REPO>中的PR #<NUMBER>：“<PR TITLE>”
<pr_description>
[PR正文/描述]
</pr_description>
这是要审查的差异（为此审查以特定顺序呈现的文件）：
<diff>
[完整差异内容 - 以此代理的随机顺序]
</diff>
以下是现有PR评论（请勿标记已评论的问题）：
<existing_comments>
[以JSON形式的现有评论数据]
</existing_comments>
## 指令
1. 仔细阅读您的角色描述，并从您的专家角度审查差异。
2. 对于发现的每个问题，使用角色描述中的指南将其分类为高、中或低严重性。
3. 以JSON数组输出您的发现，模式如下：
```json
[
{
"file": "path/to/file.ts",
"line_start": 42,
"line_end": 45,
"severity": "MEDIUM",
"category": "category-name",
"title": "简要标题",
"description": "问题的清晰描述及其影响",
"suggestion": "如何修复（可选）"
}
]
```
严重性级别：
- 高：安全漏洞、数据丢失风险、崩溃、功能损坏、UX障碍
- 中：逻辑错误、边缘情况、性能问题、损害可维护性的草率代码、降低体验的UX问题
- 低：次要样式问题、挑剔、次要抛光改进
彻底但专注。仅标记真正的问题，而非伪装为更高严重性的挑剔。
重要：将基础设施更改（DB迁移、新表/列、API端点、配置条目）与差异中的实际使用进行交叉引用。如果迁移创建表但PR中没有代码读取或写入它，那是死基础设施，应标记。
仅输出JSON数组，无其他文本。
步骤4：收集和解析结果
等待所有3个代理完成。从每个代理的响应解析JSON数组。
步骤5：使用推理分析验证问题
不要使用简单共识投票（例如，“2+代理同意”）。 而是执行推理验证：
对于每个发现的问题（按文件 + 近似行范围分组相似问题）：
-
评估有效性：这是真正的问题还是误报？考虑：
- 代码是否确实有此问题？
- 审查者是否误解代码目的？
- 此问题是否已在代码库其他地方处理？
-
评估严重性：严重性评级是否正确？考虑：
- 实际用户/系统影响是什么？
- 是否被过高或过低评级？
-
做出决策：
- 已确认：问题有效且严重性适当
- 已确认（调整）：问题有效但严重性应更改
- 已丢弃：问题是误报，解释原因
跟踪已丢弃问题，摘要评论中提供推理。
步骤6：确定合并裁决
基于已确认的问题，确定裁决：
- :white_check_mark: 是 - 准备合并：无高问题，至多次要中问题，这些是判断调用
- :thinking: 不确定 - 潜在问题：有中问题，可能应解决，但无明确障碍
- :no_entry: 否 - 请勿合并：有高严重性问题或多个需要修复的严重中问题
步骤7：去重现有评论
发布前，过滤掉与现有PR评论匹配的问题：
- 相同文件路径
- 相同或附近行号（3行内）
- 问题标题中的相似关键词出现在现有评论正文中
步骤8：发布GitHub评论
摘要评论
使用gh pr comment在PR上发布摘要评论：
## :mag: Dyadbot代码审查摘要
**裁决: [裁决表情 + 文本]**
由3个独立代理审查：正确性专家、代码健康专家、UX向导。
### 问题摘要
| 严重性 | 文件 | 问题 |
| ---------------------- | --------------------- | ---------------------- |
| :red_circle: 高 | `src/auth.ts:45` | 登录中的SQL注入 |
| :yellow_circle: 中 | `src/ui/modal.tsx:12` | 缺失加载状态 |
<details>
<summary>:green_circle: 低优先级笔记 (X 项)</summary>
- **次要命名不一致** - `src/helpers.ts:23`
- **可添加悬停状态** - `src/button.tsx:15`
</details>
<details>
<summary>:no_entry_sign: 丢弃的误报 (X 项)</summary>
- **~~潜在竞态条件~~** - 丢弃：在此上下文中状态仅同步访问
- **~~缺失空检查~~** - 丢弃：值通过调用者的验证保证非空
</details>
---
_由Dyadbot多代理代码审查生成_
总是发布摘要，即使未发现问题。此时：
## :mag: Dyadbot代码审查摘要
**裁决: :white_check_mark: 是 - 准备合并**
:white_check_mark: 多代理审查未发现问题。
---
_由Dyadbot多代理代码审查生成_
内联评论
对于每个高和中问题，使用gh api在相关行发布内联审查评论：
# 发布带内联评论的审查
gh api repos/<OWNER/REPO>/pulls/<PR_NUMBER>/reviews \
-X POST \
--input payload.json
其中payload.json包含：
{
"commit_id": "<HEAD_SHA from PR metadata>",
"body": "多代理审查: X 个问题发现",
"event": "COMMENT",
"comments": [
{
"path": "src/auth.ts",
"line": 45,
"body": "**:red_circle: 高** | security
**登录中的SQL注入**
问题描述...
:bulb: **建议:** 使用参数化查询"
}
]
}
严重性指南
所有审查者：
- 高：安全漏洞、数据丢失风险、崩溃、功能损坏、竞态条件、UX障碍
- 中：逻辑错误、未处理的边缘情况、性能问题、损害可维护性的草率代码、错误消息差、缺失加载/空状态、可访问性差距
- 低：次要样式问题、命名挑剔、可选抛光改进
哲学：损害可维护性的草率代码是中，非低。我们关心代码健康。
文件结构
references/
correctness-reviewer.md - 正确性专家的角色描述
code-health-reviewer.md - 代码健康专家的角色描述
ux-reviewer.md - UX向导的角色描述
issue_schema.md - 问题输出的JSON模式
配置笔记
- 无需Python脚本：此技能完全通过Claude Code工具执行
- 无需ANTHROPIC_API_KEY：通过Task工具产生的子代理自动访问
- 需要GITHUB_TOKEN：用于PR访问和评论（通常已配置）