branch-review-before-pr

此技能以审查为先，只有在用户明确批准后才会进行修改。

不可妥协的规则：

1. 报告任何问题前，先阅读完整差异。
2. 加载并遵循 checklist.md，包括其中的抑制规则。
3. 审查范围仅限于相对于审查基准的差异。
4. 除非用户明确选择对阻塞问题“立即修复”，否则保持只读。
5. 发现必须简洁、有依据且具体。

PR 前分支审查

输入

• $request：可选的关注领域、分支风险提示或审查范围说明

目标

针对默认基准审查当前分支，并：

• 找出通过上下文检查后仍存在的结构性缺陷
• 区分阻塞问题和非阻塞问题
• 询问用户如何处理每个阻塞问题
• 仅在用户明确批准后，选择性地应用修复

步骤 0：确定审查基准

确定：

• 当前分支
• 默认审查基准，通常是 origin/main 或 origin/master
• 用户希望审查整个分支，还是更窄的范围

如果当前分支已经是基准分支，或者没有差异，则停止并明确说明。

成功标准：明确了差异基准，并且存在实际的分支差异。

步骤 1：加载检查清单和差异范围

阅读：

• checklist.md
• 相对于基准分支的完整差异
• 差异较大时的变更文件列表

规则：

• 不得仅依据 --stat 进行审查
• 不得报告检查清单中已被抑制的项目
• 差异较大时，逐一阅读变更文件，并查看足够的上下文以核实问题

成功标准：已加载检查清单，并阅读了所有相关的变更文件。

步骤 2：分两轮审查

第一轮仅检查阻塞问题：

• 查询和数据安全
• 竞态条件和并发
• 身份验证和信任边界

第二轮检查非阻塞问题：

• 检查清单中的所有其他类别

对于每个候选问题，核实：

• 问题确实属于审查范围
• 差异中的其他位置尚未修复该问题
• 周边代码尚未缓解该问题

成功标准：已评估检查清单中所有有意义的类别，并过滤掉误报。

步骤 3：报告所有发现

始终报告完整结果：

• 先列出阻塞问题
• 再列出非阻塞问题
• 如果没有发现问题，则明确说明审查结果良好

使用以下结构：

Branch Review: N issues (X critical, Y informational)

CRITICAL (blocking):
- [file:line] Problem description
  Fix: suggested fix

Issues (non-blocking):
- [file:line] Problem description
  Fix: suggested fix

成功标准：用户能立即判断分支是否受阻，以及原因。

步骤 4：逐一处理阻塞问题

针对每个阻塞问题，单独使用 AskUserQuestion，并提供：

• 问题及其位置
• 建议的修复方案
• 以下选项：
  • 立即修复
  • 接受
  • 误报

如果用户选择：

• 立即修复：仅应用已批准的修复
• 接受：保持代码不变并记录接受决定
• 误报：保持代码不变并注明已驳回该问题

不得将多个阻塞问题合并到同一个问题中。

成功标准：每个阻塞问题都有明确的用户决定。

步骤 5：仅应用已批准的修复

用户选择 立即修复 时：

• 进行最小且正确的代码修改
• 修改范围仅限于已批准的问题
• 不得提交、推送或创建 PR
• 修复完成后总结所做的更改

如果用户仅接受或驳回问题，则不得进行任何编辑。

成功标准：仅应用了用户明确批准的修复。

何时加载参考资料

• checklist.md 用于查看详细的审查矩阵、抑制规则和问题类别。

防护措施

• 不得添加 disable-model-invocation；此技能必须继续可用于 PR/发布工作流。
• 除非需要核实上下文，否则不得审查未变更的文件。
• 不得将风格偏好报告为问题。
• 除非用户明确批准相关问题，否则不得进行任何修复。
• 不得通过此技能提交、推送或创建 PR。

输出约定

报告：

1. 审查基准和分支范围
2. 阻塞性问题
3. 非阻塞性问题
4. 针对每个阻塞性问题，报告用户的决定（如有提问）
5. 实际应用的修复