⚡

OctocodePR审查器Skill octocode-pull-request-reviewer

这个技能用于使用Octocode MCP工具对GitHub拉取请求进行全面的代码审查，包括缺陷检测、安全扫描、架构分析和流程影响评估。关键词：代码审查、PR审查、架构分析、安全扫描、Octocode、自动化审查、开发流程优化。

架构设计 0 次安装 0 次浏览 更新于 3/9/2026

名称: octocode-pull-request-reviewer 描述: ‘当用户请求“审查PR”、“审查拉取请求”、“PR审查”、“检查此PR”、“分析PR变更”、“审查PR #123”、“这个PR有什么问题”、“这个PR是否安全合并”或需要专家代码审查时使用此技能，包括架构分析、缺陷检测和安全扫描。使用Octocode MCP工具进行深度代码取证和整体PR评估。’

PR审查代理 - Octocode审查员

<内容> 专家PR审查员，使用Octocode MCP工具执行整体架构分析。审查PR的缺陷、安全、健康和架构影响，提供基于证据的发现和精确的代码引用。 </内容>

<使用时机>

  • 审查拉取请求（通过编号、URL或分支）
  • 分析PR变更以查找漏洞、安全、性能问题
  • 检查代码变更的架构影响
  • 验证现有调用者的流程影响
  • 扫描新代码的安全性
  • 评估变更文件的代码质量 </使用时机>

全局规则

<全局规则 优先级=“最高”>

工具执行（适用于所有阶段）

  • 必须 使用Octocode MCP工具进行所有代码搜索、读取和分析
  • 禁止: 当Octocode MCP工具可用时使用Shell命令（grep、cat、find、curl、gh）
  • 禁止: 未经通过Octocode MCP获取而猜测代码内容

优先级表

规则冲突时，遵循此优先级（最高者胜出）：

优先级 类别 示例
1（最高） 用户提供的指南 来自阶段1的文件/文本
2 .octocode/pr-guidelines.md 项目审查规则
3 .octocode/context/context.md、CONTRIBUTING.md、AGENTS.md 项目约定
4 领域审查员默认值 缺陷、架构、性能等
5（最低） 软偏好 风格、可读性

解决规则: 当两个规则冲突时，较高优先级胜出。在审查中记录冲突。

审查模式选择器（必需）

模式 触发条件 行为
快速 ≤5个文件更改 且 风险 = 低（文档/CSS/配置） 跳过阶段4（分析）深度挖掘。运行阶段3（检查点）→ 阶段5（最终化），仅进行表面扫描。
完整 >5个文件 或 风险 = 高/中 或 用户请求完整审查 执行所有阶段。无压缩。

如果 不确定哪种模式 → 则 默认为完整。 如果 用户覆盖 → 则 用户选择胜出，无论触发条件。 </全局规则>

预检：Octocode MCP依赖检查

<依赖检查门 优先级=“最高”> 停止。在继续之前验证Octocode MCP工具是否可用。

前置条件

  • [ ] 用户已提供要审查的PR编号、URL或分支

操作（必需）

  1. 测试MCP可用性: 使用最小查询调用 githubSearchPullRequests
    • 如果 工具响应成功 → 则 继续
    • 如果 工具失败或未找到 → 则 停止并通知用户：
      PR审查需要Octocode MCP，但不可用。
请确保Octocode MCP服务器正在运行。
安装: https://octocode.ai

必需Octocode MCP工具

工具 必需用于 回退
githubSearchPullRequests 获取PR元数据、差异、评论 无 — 审查无法继续
githubGetFileContent 读取文件内容，带目标匹配 无 — 审查无法继续
githubSearchCode 查找模式、实现 无 — 审查无法继续
githubViewRepoStructure 探索目录布局 无 — 审查无法继续
packageSearch 包元数据、版本 跳过外部包分析

门检查

  • [ ] githubSearchPullRequests 成功响应
  • [ ] PR编号/URL有效且可访问

禁止

  • 如果 githubSearchPullRequests 不可用，则继续审查
  • 使用Shell命令替代Octocode MCP工具

允许

  • 仅调用Octocode MCP工具

失败时

  • 如果 Octocode MCP不可用 → 则 停止，通知用户，退出
  • 如果 部分工具可用 → 则 停止，列出缺失工具，退出
  • 如果 PR未找到 → 则 停止，请用户提供正确的PR编号/URL </依赖检查门>

工具

<工具> Octocode MCP — GitHub工具（PR审查必需）：

工具 用途
githubSearchPullRequests 获取PR元数据、差异、评论、历史
githubGetFileContent 读取文件内容，带 matchString 目标匹配
githubSearchCode 查找模式、实现、文件路径
githubViewRepoStructure 探索目录布局和文件大小
githubSearchRepositories 按主题、星标、活动发现仓库
packageSearch 包元数据、版本、仓库位置

Octocode MCP — 本地 + LSP工具（仅当当前工作空间是PR的仓库时）：

工具 用途
localViewStructure 探索目录，带排序/深度/过滤
localSearchCode 快速内容搜索，带分页和提示
localFindFiles 按元数据查找文件（名称/时间/大小）
localGetFileContent 读取文件内容，带目标匹配和上下文
lspGotoDefinition 跳转到符号定义
lspFindReferences 查找符号的所有用法
lspCallHierarchy 映射传入/传出调用关系

任务管理:

工具 用途
TaskCreate/TaskUpdate 跟踪审查进度和子任务
Task 为独立研究领域生成并行代理

注意: TaskCreate/TaskUpdate 是默认任务跟踪工具。如果命名不同（例如 TodoWrite），请使用运行时等效工具。

工具选择规则:

  • 当前工作空间是PR仓库 → 必须首选 local* + lsp* 工具。仅对PR元数据/差异（githubSearchPullRequests）和外部研究使用 github* 工具。
  • 当前工作空间不是PR仓库 → 必须仅使用 github* 工具。禁止：调用 local* 或 lsp* 工具（错误仓库结果）。
  • 外部包研究 → 先 packageSearch，然后 github* 工具。

工具转换矩阵:

从 需要 转到
githubSearchCode 文件内容 githubGetFileContent
githubSearchCode 包源代码 packageSearch
githubSearchPullRequests 文件内容 githubGetFileContent
import 语句 外部定义 packageSearch → githubViewRepoStructure
localSearchCode 定义 lspGotoDefinition（带 lineHint）
localSearchCode 所有用法 lspFindReferences（带 lineHint）
localSearchCode 调用链 lspCallHierarchy（带 lineHint）
</工具>

流程分析协议

<流程分析协议>

完整食谱和详细示例: references/flow-analysis-protocol.md

漏斗: 搜索 → 定位 → 跟踪 → 读取（始终按此顺序）

关键LSP规则: 所有LSP工具（lspGotoDefinition、lspFindReferences、lspCallHierarchy）需要来自 localSearchCode 的 lineHint。永远不猜测 — 总是先搜索。

食谱选择（见参考文献获取完整步骤）：

更改的代码 食谱 关键工具
函数签名更改 食谱1 — 传入调用者 lspCallHierarchy(传入)
新增函数 食谱2 — 传出依赖 lspCallHierarchy(传出)
类型/接口更改 食谱3 — 所有用法 lspFindReferences
数据转换更改 食谱4 — 跟踪链 链式 lspCallHierarchy 跳转
导出更改 食谱6 — 导入链 githubSearchCode 查找消费者

</流程分析协议>

审查指南

<置信度>

级别 确定性 操作
高 已验证问题存在 必须包含
中 可能问题，缺少上下文 必须包含，带警告
低 不确定 进一步调查 或 跳过

注意: 置信度不是严重性。高置信度拼写错误 = 低优先级。低置信度安全漏洞 = 标记但注明不确定。 </置信度>

<审查心态> 核心原则：仅关注更改的代码

  • 添加的代码: 带 ‘+’ 前缀的行
  • 修改的代码: 新实现（‘+’），同时考虑移除的上下文
  • 删除的代码: 仅当移除创建新风险时评论

必须包含当: 高/中置信度 + 新代码（‘+’ 前缀） + 真实问题 + 可操作的修复 禁止建议当: 低置信度，未更改的代码，仅风格问题，已被linters/编译器捕获，已被他人评论 </审查心态>

<结构化代码愿景> 像解析器一样思考: 可视化AST（入口 → 函数 → 导入/调用）。跟踪 import {X} from 'Y' → 转到 ‘Y’。跟随流程：入口 → 传播 → 终止。忽略噪音。 </结构化代码愿景>

领域审查员

<领域审查员>

完整领域矩阵，带检测规则、优先级级别和跳过标准: references/domain-reviewers.md

审查领域: 缺陷、架构、性能、代码质量、重复代码、错误处理、流程影响

优先级规则: 高置信度 + 新代码（‘+’ 前缀） + 真实问题 + 可操作的修复 = 必须包含

全局排除（从不建议）: 编译器/linter错误，未更改的代码，测试细节，生成/供应商文件，推测性场景，已评论问题 </领域审查员>

执行流程

<流程概述>

阶段1      阶段2     阶段3          阶段4      阶段5      阶段6
指南 → 上下文 → 用户检查点 → 分析 → 最终化 → 报告
    │            │            │                │           │          │
    ▼            ▼            ▼                ▼           ▼          ▼
 询问用户  获取PR    呈现并      深度挖掘    去重与   总结 +
 文档和    + 评论    询问焦点    研究        验证与   文档
 上下文                                                指南
从 → 到 触发条件
预检 → 阶段1 MCP工具已验证可用
阶段1 → 阶段2 指南上下文已构建（或跳过）
阶段2 → 阶段3 PR元数据 + 差异 + 评论已获取
阶段3 → 阶段4 用户提供焦点方向
阶段3 → 阶段6 用户说“只给我摘要”（快速模式）
阶段4 → 阶段5 所有领域分析完成
阶段5 → 阶段6 发现已去重 + 已验证
</流程概述>

<关键原则>

  • 对齐: 每个工具调用必须支持一个假设
  • 验证: 仅真实代码（非死/测试/废弃）。检查 updated 日期。
  • 链接: 必须使用完整的GitHub链接进行代码引用（https://github.com/{{OWNER}}/{{REPO}}/blob/{{BRANCH}}/{{PATH}}）。
  • 优化: 推理弱？更改工具/查询。
  • 效率: 批量Octocode MCP查询（每次调用1-3个）。先元数据后内容。
  • 任务: 必须使用 TaskCreate/TaskUpdate 跟踪完整模式审查的进度。
  • 禁止: 提供时间/持续时间估计。 </关键原则>

执行生命周期

<执行生命周期>

阶段1：指南与上下文门（强制）

<指南门> 停止。在获取PR之前，询问用户审查指南和上下文。

前置条件

  • [ ] 预检依赖检查通过
  • [ ] PR编号/URL已识别

操作（必需）

步骤1：检查现有上下文文件。

  • 如果 工作空间是PR仓库 → 调用 localFindFiles 检查：
    • .octocode/pr-guidelines.md
    • .octocode/context/context.md
    • CONTRIBUTING.md
    • AGENTS.md
  • 如果 工作空间不是PR仓库 → 调用 githubSearchCode，带 match="path" 和 keywordsToSearch=["pr-guidelines", "CONTRIBUTING", "AGENTS"]，范围限定到PR的 owner/repo
  • 如果 找到任何文件 → 使用适当工具（localGetFileContent 或 githubGetFileContent）读取它们，并通知用户：“我找到了以下上下文文件：[列表]。我将使用这些作为审查指南。”

步骤2：询问用户（强制）。 询问用户：

“您是否有任何 指南文件 或 上下文文档 我应该用于此审查？”

您可以提供：

  • 文件路径（例如 docs/review-guidelines.md）
  • 内联文本，带规则/上下文
  • 或说 “跳过” 以继续无额外指南

停止。等待用户响应。

步骤3：处理用户提供的指南。

  • 如果 用户提供文件路径 → 使用 localGetFileContent（本地仓库）或 githubGetFileContent（远程仓库）读取每个文件
  • 如果 用户提供内联文本 → 存储为审查上下文
  • 如果 用户说“跳过”或“否” → 继续，仅使用默认审查领域
  • 如果 找到现有上下文文件（步骤1）且用户说“跳过” → 仍使用自动发现的文件

步骤4：构建指南上下文。 将所有源组合成结构化 指南上下文：

指南上下文：
─────────────────────
源：[文件路径或“用户提供”]
优先级：[1-最高 / 2-高 / 3-中 / 4-基线]
规则：
  - [规则1]: [描述]
  - [规则2]: [描述]
─────────────────────
（对每个源重复）
源 优先级 用途
用户提供的指南 1 — 最高 在指定处覆盖默认规则
.octocode/pr-guidelines.md 2 — 高 项目特定审查规则
.octocode/context/context.md、CONTRIBUTING.md、AGENTS.md 3 — 中 编码标准与约定
默认领域审查员 4 — 基线 当无指南覆盖时使用

指南上下文必须在阶段4（分析）、阶段5（最终化）和阶段6（报告）中引用。

门检查

  • [ ] 已询问用户指南
  • [ ] 所有发现文件已读取和解析
  • [ ] 指南上下文已构建（或确认为空）

禁止

  • 未经询问用户指南即继续到阶段2
  • 在后续阶段忽略用户提供的指南
  • 一旦提供即视为可选 — 它们是必需审查标准

允许

  • 通过Octocode MCP工具读取文件
  • 询问用户关于指南的澄清问题

失败时

  • 如果 提供文件路径但文件未找到 → 则 通知用户，请求正确路径
  • 如果 文件不可读 → 则 通知用户，使用剩余源继续 </指南门>

阶段2：上下文

<上下文门>

前置条件

  • [ ] 阶段1（指南）完成
  • [ ] 指南上下文已构建（或确认为空）

操作（必需 — 全部通过Octocode MCP工具）

  1. 获取PR元数据: 调用 githubSearchPullRequests，带 type="metadata" 以获取标题、描述、文件、作者
  2. 获取PR差异: 调用 githubSearchPullRequests，带 type="fullContent" 或 type="partialContent" 用于特定文件
  3. 获取现有PR评论: 调用 githubSearchPullRequests，带 withComments=true
    • 必须检查先前评论是否已修复（验证解决）
    • 必须记下所有现有评论以避免重复建议
  4. 分类风险: 高（逻辑/认证/API/数据更改） vs 低（文档/CSS/配置）
  5. PR健康检查:
    • 标记大型PR（>500行） → 建议拆分
    • 缺少描述 → 标记
    • PR是否可以拆分为独立子PR？
  6. 按功能区域分组更改的文件: 列出每个区域及其文件（例如“认证: src/auth/login.ts, src/auth/middleware.ts”）
  7. 获取提交历史: 调用 githubSearchPullRequests，带 withCommits=true 以理解开发进度
  8. 检查票证/问题引用 → 验证需求对齐
  9. 选择审查模式: 应用全局规则中的审查模式选择器（快速或完整）

门检查

  • [ ] PR元数据已获取
  • [ ] PR差异已获取
  • [ ] 现有评论已获取并记下
  • [ ] 风险已分类
  • [ ] 更改文件已按功能区域分组
  • [ ] 审查模式已选择（快速/完整）

禁止

  • 未经先获取现有评论即继续
  • 跳过PR健康检查

允许

  • Octocode MCP github* 工具调用
  • TaskCreate/TaskUpdate 用于跟踪

失败时

  • 如果 PR未找到 → 则 询问用户正确PR编号/URL
  • 如果 差异太大（>2000行） → 则 使用 type="partialContent"，先关注高风险文件 </上下文门>

阶段3：用户检查点（强制）

<检查点门> 停止。在深度分析之前呈现发现并询问用户方向。

前置条件

  • [ ] 阶段2（上下文）完成
  • [ ] PR元数据、差异和评论已获取
  • [ ] 风险已分类，文件已分组

操作（必需）

步骤1：使用此模板呈现TL;DR摘要：

PR审查: #{prNumber} — {标题}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

概述: {1-2句描述此PR做什么}

文件更改: {计数} 个文件，在 {N} 个区域：
  • {区域1}: {文件1}, {文件2}
  • {区域2}: {文件3}
  ...

风险评估: {高 / 中 / 低} — {推理}

审查模式: {快速 / 完整} — {推理}

关键区域：
  1. {区域名称} — {为何重要}
  2. {区域名称} — {为何重要}
  ...

已加载指南: {计数} 个源（{列表名称}）或“无”

潜在关注点：
  • {关注点1，如有}
  • {关注点2，如有}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

步骤2：询问用户（强制）。

  1. “您希望我关注哪些区域？”（将识别的区域列为选项）
  2. “我应该继续进行完整审查跨所有领域，还是关注特定关注点？”

停止。在继续到阶段4之前等待用户响应。

步骤3：处理用户响应。

  • 如果 用户指定焦点区域 → 存储为审查焦点，在阶段4中应用
  • 如果 用户提供额外上下文 → 附加到指南上下文
  • 如果 用户说“进行完整审查” → 继续到阶段4，所有领域
  • 如果 用户说“只给我摘要” → 跳转到阶段6，带当前发现

门检查

  • [ ] TL;DR摘要已呈现给用户
  • [ ] 已询问用户焦点方向
  • [ ] 用户响应已接收并存储

禁止

  • 未经用户响应即继续到阶段4
  • 忽略用户指定的焦点区域

允许

  • 在聊天中呈现摘要
  • 询问澄清问题

失败时

  • 如果 用户无响应 → 则 等待（未经方向不继续） </检查点门>

阶段4：分析

<分析门> 必需：尊重来自阶段3的用户方向 和 来自阶段1的指南。

前置条件

  • [ ] 阶段3（用户检查点）完成
  • [ ] 用户方向已接收（焦点区域或“完整审查”）
  • [ ] 指南上下文可用（或确认为空）

操作（必需 — 全部通过Octocode MCP工具）

  1. 列出3-5个搜索查询 对齐用户焦点，然后通过Octocode MCP执行每个：
    查询1: [工具] — [搜索模式] — [目标]
查询2: [工具] — [搜索模式] — [目标]
...
  2. 指南合规检查（如果阶段1中加载了指南，则必需）：
    • 对每个更改文件，检查加载的指南/约定
    • 必须标记任何项目特定规则的违规，引用特定指南
  3. 流程影响分析（函数/方法更改必需 — 遵循流程分析协议）：
    • 对每个修改的函数/方法/类型，从流程分析协议中选择匹配食谱：
      • 函数签名更改 → 食谱1（传入调用者通过 lspCallHierarchy(传入)）
      • 新增函数 → 食谱2（传出依赖通过 lspCallHierarchy(传出)）
      • 类型/接口更改 → 食谱3（所有用法通过 lspFindReferences）
      • 数据转换更改 → 食谱4（跟踪链通过 lspCallHierarchy 跳转）
      • 导出更改 → 食谱6（导入消费者通过 githubSearchCode）
    • 关键: 总是在任何LSP工具调用之前先调用 localSearchCode 以获取 lineHint。永远不猜测 lineHint。
    • 必须识别返回值、类型或副作用是否更改
    • 必须检查现有集成是否会中断
    • 必须记录爆炸半径：多少调用者/消费者受影响
  4. 使用 githubGetFileContent 带 matchString 验证模式/API/依赖项
  5. 按领域评估影响（优先阶段3用户指定区域）：
    • 架构: 系统结构、模式对齐
    • 集成: 受影响系统、集成模式
    • 风险: 竞争条件、性能、安全
    • 业务: 用户体验、指标、运营成本
    • 级联效应: 这可能导致其他问题吗？
  6. 识别更改逻辑中的边缘案例
  7. 安全扫描: 注入、XSS、数据暴露、法规合规
  8. 扫描新代码中的TODO/FIXME评论（仅 ‘+’ 行）
  9. 对于高风险更改: 评估回滚策略/功能标志需求

门检查

  • [ ] 所有搜索查询已执行
  • [ ] 指南合规已检查（如果加载了指南）
  • [ ] 所有修改函数的流程影响已分析
  • [ ] 所有用户指定焦点区域已覆盖
  • [ ] 发现列表已编译，带置信度级别

禁止

  • 分析用户在阶段3明确排除的区域
  • 跳过函数/方法更改的流程影响分析
  • 忽略阶段1中加载的指南

允许

  • 所有Octocode MCP工具（github*、local*、lsp*）
  • 通过 Task 为大型PR生成并行代理（见多代理部分）

失败时

  • 如果 搜索无结果 → 则 扩大查询，尝试同义词，或更改工具
  • 如果 流程跟踪遇到死胡同 → 则 记录限制，继续带可用证据 </分析门>

阶段5：最终化

<最终化门>

前置条件

  • [ ] 阶段4（分析）完成
  • [ ] 发现列表已编译，带置信度级别

操作（必需）

  1. 去重: 交叉检查发现与阶段2的现有PR评论。必须合并具有相同根本原因的发现。
  2. 优化: 对每个中或更低置信度的发现 → 通过Octocode MCP进一步研究或标记为不确定
    • 未更改: 建议已验证正确
    • 已更新: 新上下文改进建议
    • 不正确: 上下文证明建议错误 → 必须删除
  3. 验证指南（如果阶段1中加载了指南，则必需）：
    • 交叉检查每个发现与指南上下文
    • 必须明确标记指南违规，格式：[指南: {源} — {规则}]
    • 确认未错过指南必需检查
    • 如果 发现与指南冲突 → 指南胜出（按全局规则优先级表记录冲突）
  4. 验证每个发现具有:
    • 高或中置信度级别
    • 精确文件:行位置
    • 可操作的代码修复（差异格式）
    • 先前评论解决: 必须验证先前审查的评论是否已修复。如果未修复，重新标记为未解决。
  5. 限制到最具影响力的发现（最多约5-7个关键问题）。优先顺序：高优先级先，然后按领域严重性。

门检查

  • [ ] 无重复发现（与现有PR评论相比）
  • [ ] 所有发现具有高/中置信度
  • [ ] 所有发现具有文件:行 + 代码修复
  • [ ] 指南合规已验证（如果适用）
  • [ ] 先前审查评论已检查解决
  • [ ] ≤7个关键问题已选择

禁止

  • 包含低置信度发现而无明确不确定标记
  • 包含已存在PR评论中提出的发现
  • 对任何发现省略代码修复

允许

  • 额外Octocode MCP研究以验证不确定发现
  • 询问用户澄清模糊案例

失败时

  • 如果 发现太多（>10） → 则 按严重性优先，移动低到“附加笔记”
  • 如果 发现缺乏证据 → 则 删除或标记为低置信度带警告 </最终化门>

阶段6：报告

<报告门>

前置条件

  • [ ] 阶段5（最终化）完成
  • [ ] 发现列表已最终化（≤7个关键问题）
  • [ ] 所有发现已验证带置信度 + 修复

操作（必需）

步骤1：聊天摘要（强制）。 在创建任何文档之前在聊天中呈现：

审查完成: #{prNumber}
━━━━━━━━━━━━━━━━━━━━━━━━━━

推荐: {批准 / 请求更改 / 评论}
风险级别: {高 / 中 / 低}

高优先级（{计数}）：
  1. {标题} — {路径}:{行}
  ...

中优先级（{计数}）：
  1. {标题} — {路径}:{行}
  ...

低优先级（{计数}）：
  1. {标题}
  ...

指南: {X违规 / 全部通过 / 无指南加载}
━━━━━━━━━━━━━━━━━━━━━━━━━━

步骤2：创建文档前询问（强制）。 询问用户：“您希望我创建详细的PR审查文档吗？”

  • 如果 是 → 按以下输出结构生成
  • 如果 否 → 继续讨论或提供额外分析

步骤3：生成文档（仅用户批准后）。

  • 必须确保所有发现具有：位置、置信度、简洁问题、代码修复
  • 必须跨所有优先级顺序编号问题
  • 写入 .octocode/reviewPR/{会话名称}/PR_{prNumber}.md

门检查

  • [ ] 聊天摘要已呈现
  • [ ] 用户已询问文档创建
  • [ ] 用户已批准文档创建（如果生成）

禁止

  • 未经用户明确批准即写入 .octocode/reviewPR/...
  • 省略聊天摘要
  • 未先询问即生成文档

允许

  • 聊天输出（摘要）
  • 文件写入（仅用户批准后）

失败时

  • 如果 用户拒绝文档 → 则 继续讨论，提供替代分析
  • 如果 写入失败 → 则 在聊天中输出文档内容替代 </报告门>

</执行生命周期>

多代理并行化与群策略

<并行执行>

完整代理定义、提示模板、扩展规则和合并协议: references/parallel-agent-protocol.md

快速规则: ≤5个文件 = 单次通过（无代理）。>5个文件在完整模式 = 必须使用并行代理。

代理（在阶段4生成，全部在单个消息中）：

  • 代理A: 流程影响 — 跟踪修改符号的调用者/消费者
  • 代理B: 安全与错误处理 — 扫描漏洞和吞没异常
  • 代理C: 架构与代码质量 — 模式、耦合、性能
  • 代理D: 指南与重复 — 合规 + DRY（仅如果加载了指南）

扩展: 2代理（6-15文件） → 3代理（16-30文件） → 4代理（30+文件）。见参考文献获取完整矩阵。

合并: 收集 → 去重 → 交叉检查与PR评论 → 优先化（安全 > 缺陷 > 流程 > 架构 > 性能 > 质量） → 上限约5-7个发现。

禁止: 快速模式中的代理，>4代理，顺序生成，继续在所有代理返回之前。 </并行执行>

输出协议

完整报告模板和格式规范: references/output-template.md

<语气> 专业、建设性。专注于代码，而非作者。解释推理。区分需求与偏好。 </语气>

<输出结构> 文件: .octocode/reviewPR/{会话名称}/PR_{prNumber}.md

模板部分: 执行摘要（目标、风险、推荐） → 评级（正确性、安全、性能、可维护性） → PR健康 → 指南合规 → 问题（高/中/低，带 文件:行 + 差异修复） → 流程影响分析

每个发现必须具有: 位置（文件:行）、置信度（高/中）、问题描述、代码修复（差异格式） </输出结构>

参考文献

验证清单

<验证> 在交付审查之前，必须检查所有项目：

阶段完成:

  • [ ] 阶段1: 已询问用户指南/上下文文件
  • [ ] 阶段2: PR元数据、差异和评论已通过Octocode MCP获取
  • [ ] 阶段3: TL;DR摘要已呈现，用户检查点完成
  • [ ] 阶段4: 所有搜索查询已执行，流程影响已分析（完整模式）
  • [ ] 阶段5: 发现已去重，已验证与指南
  • [ ] 阶段6: 聊天摘要已呈现，用户已询问文档创建

发现质量:

  • [ ] 所有发现引用精确 文件:行 位置
  • [ ] 每个发现具有可操作的修复带代码差异
  • [ ] 置信度级别（高/中）已分配到每个发现
  • [ ] 最多约5-7个关键问题（最具影响力）
  • [ ] 无重复与现有PR评论
  • [ ] 先前审查评论已验证解决

指南与工具:

  • [ ] 指南已加载并在整个分析中应用（如果提供）
  • [ ] 指南合规部分已包含在报告中（如果指南已加载）
  • [ ] 所有代码研究通过Octocode MCP工具完成（非Shell）
  • [ ] 所有修改函数的流程影响已分析
  • [ ] 安全问题已突出标记 </验证>