review-gang

用途

Review Gang 用于对现有代码进行独立审查。它接受的目标范围包括：diff、分支、拉取请求（PR）或整个代码库。其核心目的是通过多个关注不同问题的审查者子代理，从相互独立的视角审计同一份代码，从而避免单次自审可能带来的盲区，最终合成一个有明确证据支持、按严重程度排序的发布决策。

主要能力

• 独立多代理审查：每次运行至少生成两个审查者角色作为独立的子代理。每个子代理关注不同的风险维度，并且相互独立，不会 collapses 成一个混合的自审过程。
• 按风险扩展审查者集合：根据变更的风险等级自动调整审查者数量与类型。微小低风险变更为“通用 + 一个相关专家”；普通变更使用“通用、测试、静默失败、代码形态”四个角色；高风险变更仅额外添加不同的专家角色，避免重复关注点。
• 证据驱动与严重程度排序：发现的问题必须包含文件/行号证据、严重程度、置信度，以及会改变裁定结果的证明材料或缺失证明。低价值的挑剔被排除在外。
• 裁定与阻塞机制：在缺少上下文或证据导致无法给出诚实裁定时，会阻塞并说明未验证的表面；否则会指出未验证的部分并相应调整裁定。
• 明确的使用边界：不能用于自检刚刚编写的变更。

使用方式

1. 开始前：定义审查范围（文件、diff、分支、提交范围或 PR）；加载目标仓库的指导文件（如 AGENTS.md、CLAUDE.md 或仓库规则）；确认审查的基准/头部或当前工件是最新的；根据 references/reviewer-selection.md 选择风险等级和审查者集合；加载每个选中的角色文件，并在生成子代理时将角色说明嵌入其任务中。仅在能增加独立关注点时才添加条件角色。

2. 工作流：

   • 界定附近风险：审查请求的代码，但当风险溢出到指定 diff 之外时，检查相邻行为。对分支或 PR 进行判断前，刷新事实来源：基准分支、头部 SHA、diff、检查项，以及关联的 issue 或规范（如有）。
   • 生成审查者子代理：为每个选中的角色生成一个子代理，环境支持时并行运行，保持每个角色独立且聚焦。生成前，加载相对于本技能包的 references/reviewers/<persona>.md，并将其内容嵌入任务中。绝不能要求子代理从目标仓库解析源仓库路径。每个子代理使用如下提示模板：

     You are the <persona> reviewer. Read the target repo guidance, then review only <scope>.
     
     Persona instructions:
     <contents loaded from references/reviewers/<persona>.md>
     
     Return only material findings with file/line evidence, severity, confidence, and the proof or missing proof that changes the verdict. If you find nothing material, say "none" and name any residual unverified surface.
     

     具体起点命令包括：git diff --stat <base>...HEAD 用于评估变更规模；git diff <base>...HEAD -- <path> 用于检查高风险文件；需要行为证明时运行针对性测试，如 pnpm test path/to/spec。
   • 收集证据：对静态发现引用确切的文件位置；在仓库支持时，运行最小化的运行时检查以改变裁定；如未验证，明确说明；将过期的 CI、过期的审查工件或已移动的分支头部视为未验证，直到刷新；若遗留或死代码仍存在，说明是否应删除或为何必须保留；若测试 mock 了主要集成或边界，说明该行为在真实表面上仍未验证。
   • 综合裁定：按严重程度排序发现。若未发现任何问题，明确说明并指出残余风险或测试缺口。裁定必须从以下三个中选择一个：ship it、needs review 或 blocked。

3. 输出格式：审查后以紧凑的项目符号形式报告：

   - findings: 首先，仅在存在时；否则 - findings: none
   - verdict: 恰好为 ship it、needs review 或 blocked 之一
   - evidence: 简洁解释哪些检查证明了什么，而非完整命令
   - unverified: 残余风险、就绪缺口，或 none
   - next: implementation、runtime verification、readiness setup、documentation cleanup 或 none 之一
   - notes: 仅用于用户必须处理的范围外仓库状态
   

   优先使用当前执行环境的最佳原生审查表示，而非大段文字。详细问题文本保留在原生发现或回退发现的项目符号中。发现之后，其余标签保持在四行或更少。省略开场白、结束语、道歉、状态前言和对话式回顾。

示例

- finding: high — src/auth/session.ts:42 fallback returns an anonymous session when token parsing fails
- verdict: needs review
- evidence: session tests exercised token parsing failures
- unverified: malformed OAuth callback runtime behavior
- next: implementation

适用场景

• 需要对现有代码进行独立、多视角审查时。
• 需要在合并或发布前获得有证据支持的发布决策时。
• 处理普通变更或高风险变更，希望审查者集合能根据风险自动扩展时。

限制

• 不能用于自检刚刚由自己编写的变更。
• 如果审查者子代理的工具不可见，需要先发现或加载一次；若仍不可用，则报告阻塞，除非用户明确允许顺序回退方案。
• 缺少上下文或证据导致无法给出诚实的裁定时，会被阻塞。
• 过期的 CI、过期的审查工件或已移动的分支头部被视为未验证，直到刷新。
• 若测试 mock 了主要集成或边界，相关行为在真实表面上仍视为未验证。
• 具体的角色文件内容、审查者选择的具体标准等细节需要参考技能包内的 references/reviewer-selection.md 和 references/reviewers/<persona>.md，这些内容在提供的资料中未完整展开。