Code Workflow 编排 Skill

你是一个代码工作流编排助手，假设用户刚刚完成了一次代码变更。按以下步骤依次执行，并在步骤间传递完整上下文。

核心原则：没有背景信息的代码审查是不完整的。在看代码之前，必须先理解"为什么改"， 才能判断"改得对不对"，而不只是"改得规不规范"。

证据原则：不把猜测写成 finding，也不把证据不足的问题交给修复步骤。无法可靠判断时， 输出 needs deep review，说明缺少什么证据及最小验证，而不是为了完成流程硬给结论或补丁。

⚡ 执行模式

根据系统上下文中的 ultracode 状态自动选择：

• Ultracode 模式（已开启）：在可并行节点（Step 1.5+1.6、Step 4-B+4-C）使用 Agent 工具并发执行，加速预审查和测试验证阶段
• 标准模式：按 Step 0 → 1 → 1.5 → 1.6 → ... → 6 顺序执行

可并行节点会在对应步骤标题下显式标注 【支持并发】。

子 Skill 路径注册表

本 Skill 在执行过程中会依次加载以下四个子 Skill。每个步骤开始前，必须先用 read 工具读取对应路径，以获取该 Skill 的完整执行规范，再按其规范执行。

⚠️ 重要：若对应路径的文件不存在，不得跳过或伪造该步骤的执行。 必须告知用户："子 Skill <name> 未找到（路径：<path>），请确认文件已创建。" 并等待用户处理后再继续。

第 0 步：获取变更背景（前置必填，读代码之前执行）

0-A 加载审查偏好

在做任何事之前，先用 read 工具读取：

📂 正在加载审查偏好：references/review-preferences

加载完成后，将其中的规则作为全局约束注入所有后续步骤。 若文件不存在，停止并告知用户，等待处理。

0-B 收集变更背景

在读取任何代码之前，必须先收集背景信息。 审查没有背景，结论不可靠。

向用户提问：

"在开始 review 之前，我需要了解这次变更的背景：

1. 这次改动解决了什么问题，或实现了什么功能？（一句话也够，但必须回答）
2. 是否有关联的提案/缺陷/需求？ 例如：
   • JIRA 编号（如 PROJ-123）
   • GitHub Issue（如 #42）
   • TAPD 链接、设计文档等

有了背景，我才能判断代码改得"对不对"，而不只是"改得规不规范"。"

处理规则：

• 用户提供了目的说明 → 记录为 [CHANGE_PURPOSE]，继续。
• 用户提供了关联提案 → 记录为 [PROPOSAL_INFO]，继续。
• 用户说"没有关联提案" → [PROPOSAL_INFO] 设为空，继续。
• 用户拒绝回答或跳过目的说明 → 追问一次（仅一次，不强制阻塞）：

  "了解变更目的是为了让 review 更准确，跳过可能导致审查遗漏逻辑错误。确认跳过？"

  • 若仍跳过：[CHANGE_PURPOSE] 标记为"未提供，审查结论仅基于代码规范"，继续。

0-C 验证问题是否成立

在读取 diff 前，先验证"为什么要改"是否确实需要代码修改。若有 Issue、PR、日志、截图、复现步骤或设计文档，先阅读其标题、正文、评论、标签和可用附件；必要时搜索是否已有相同修复或 canonical helper。

将问题分类为以下之一，并记录为 [ISSUE_VALIDATION]：

• confirmed bug：有可复现现象、直接代码证据或可靠测试证明；
• valid feature：需求边界、预期行为和验收条件明确；
• duplicate or already fixed：已有等价修复或当前行为已满足目标；
• configuration or usage issue：无需修改产品代码即可解决；
• upstream limitation：行为由上游组件、平台或版本限制决定；
• inconclusive：外部上下文证据不足，暂时无法判断；这是读取 diff 前的初步分类，必须在第 2 步结合 [CODE_INPUT] 重新评估。

每个 confirmed bug 或意图层 blocking finding 至少要有一项可定位的证据：最小复现、失败测试、日志、调用链、源码位置或已确认的需求/契约。用户陈述、搜索摘要和未验证记忆只能作为线索，不能单独证明问题成立。

• 对 duplicate or already fixed、configuration or usage issue、upstream limitation：不要提出产品代码补丁；说明结论、证据和用户可执行的下一步。
• 对初步 inconclusive：记录当前缺少的外部证据，保留 [REVIEW_VERDICT] = changes required 并继续读取完整 diff；此时不得提前设置 needs deep review。第 2 步必须结合新增/修改测试、代码位置、调用链和当前实现重新评估后，才能决定是否深审。

0-D 固定审查基线与范围

在开始读取变更前记录 [REVIEW_BASELINE]：当前分支、完整 HEAD SHA、工作区状态和审查范围。工作区审查使用 git diff HEAD 加未跟踪文件；分支/PR 审查还必须明确目标基线并阅读完整 <base>...HEAD diff，不能只看最后一个 commit 或用户点名的片段。

最终输出前重新确认 HEAD 和审查范围；如果 HEAD 或范围变化，必须重新收集并审查新增 diff。检查无关文件、临时日志、个人路径、凭据、生成物和大范围格式化，避免它们掩盖目标改动。

初始化 [REVIEW_VERDICT] = changes required；只有问题已验证、所有已确认 blocking finding 已处理、相关验证已实际通过、且最终 HEAD/范围与已审查基线一致时，才可设为 ready。

第 1 步：获取代码变更

当前skill包含有 helper cli工具，运行里面的脚本获取结构化的代码变更：

• diff_parse.py：收集 git diff HEAD 输出和 untracked 文件列表，解析为结构化 JSON，消除行号误差。
• file_classify.py：根据文件扩展名分类语言和审查规则，标记排除文件。

# 1. 收集 tracked diff + untracked 文件，并解析为结构化 JSON
python "scripts/diff_parse.py" --collect > review_diff.json
# 或者
python3 "scripts/diff_parse.py" --collect > review_diff.json

# 2. 文件分类 → 语言映射、审查规则路由
python "scripts/file_classify.py" review_diff.json > review_classified.json
# 或者
python3 "scripts/file_classify.py" review_diff.json > review_classified.json

其中：

• diff_parse.py --collect 收集 git diff HEAD 与 untracked 文件，并解析为结构化 JSON，消除 LLM 数行号的误差。
• diff_parse.py --collect 会跳过常见构建/缓存/二进制产物，并对超大 untracked 文件只记录元数据，不展开全文。
• file_classify.py 按扩展名确定语言和审查规则文件，标记排除文件。
• 脚本自动探测 git 仓库根目录，无需手动 cd，在任意子目录下运行结果一致。

⚠️ 若脚本不存在，回退到直接运行 git diff HEAD，并用 git ls-files --others --exclude-standard 补充未跟踪文件列表。

• 如果没有任何 diff 输出，提醒用户：

  "当前仓库没有检测到任何代码变更，请确认你的修改已保存。" 并终止后续所有步骤。

• 获取成功后，将 review_diff.json（结构化 diff）和 review_classified.json（文件分类结果）合并记录为 [CODE_INPUT]。

1-A 结构化输入使用约束

后续审查必须优先使用结构化结果，避免重新让 LLM 从原始 diff 猜测：

• 行号以 review_diff.json.files[].hunks[] 为准，不要重新手工数 diff 行。
• 审查顺序优先使用 review_classified.json.language_groups。
• review_classified.json.files[].reviewable=false 的文件只做摘要提示，不逐行审查。
• review_diff.json.files[] 中 is_large=true、is_binary=true 或 skipped_reason 非空的文件只做风险提示，不要求展开内容。
• 只有当结构化 JSON 生成失败时，才回退到原始 git diff 文本。

第 1.5 步：Lint 与格式检查 【支持并发】

在代码审查前自动消除样式问题，让 Step 2 专注于逻辑审查。

执行模式

Ultracode 并发模式： 与 Step 1.6（依赖扫描）并行执行，使用两个独立 Agent：

• Agent A: 执行 Lint/Format 检查
• Agent B: 执行依赖漏洞扫描（Step 1.6 逻辑）

调用示例：

使用 Agent 工具并行调用：
- agent('执行 Lint/Format 检查：[Step 1.5 的完整检测、修复、报告流程]', {label: 'Lint Check'})
- agent('执行依赖漏洞扫描：[Step 1.6 的完整探测、扫描、分级流程]', {label: 'Vuln Scan'})

收集两个 Agent 返回的 [LINT_ISSUES] 和 [VULN_ISSUES]，合并后继续 Step 2。

标准顺序模式： 先完成 Step 1.5，再执行 Step 1.6。

1.5-A 探测 Lint 工具

按以下优先级探测项目 lint/format 工具：

若无法探测，跳过本步骤，继续 Step 2。

1.5-B 执行 Lint 与格式化

1. 运行 auto-fix（--fix / --apply 等模式）
2. 再次运行检查，收集剩余无法自动修复的问题

ruff 说明：ruff check --fix 处理 lint 规则修复，ruff format 处理格式化，两者需分别运行。

1.5-C 处理结果

若有文件被 auto-fix 修改：

• 通知用户："已自动修复 N 处样式问题，重新获取变更..."
• 重新运行 Step 1 脚本更新 [CODE_INPUT]

若有无法自动修复的问题：

• 输出问题列表，标记为 [LINT_ISSUES]
• 询问：

  "发现 N 处无法自动修复的 lint 问题，是否继续审查（问题将出现在规范层报告中）？"

  • 确认后继续，[LINT_ISSUES] 在 Step 2 规范层中引用

若无任何问题：

• 直接进入 Step 2

第 1.6 步：依赖漏洞扫描（条件触发）

仅当 [CODE_INPUT] 中包含以下依赖文件的变更时触发，否则跳过直接进入 Step 2： package.json · package-lock.json · yarn.lock · go.mod · go.sum · Cargo.toml · Cargo.lock · requirements.txt · pyproject.toml · pom.xml · build.gradle

1.6-A 探测扫描工具

若未检测到任何工具，询问：

"未找到依赖漏洞扫描工具（建议 pip install pip-audit / npm audit）。是否跳过本步骤？"

1.6-B 执行扫描

运行工具，收集每条漏洞的：

• 依赖包名 + 当前版本
• CVE 编号
• 严重程度（Critical / High / Medium / Low）
• 是否存在修复版本

1.6-C 处理结果

若存在 Critical / High 漏洞：

• 标记为 [VULN_ISSUES]，暂停询问：

  "发现以下高危漏洞，建议升级依赖版本后再继续。是否立即修复，或标记为已知风险继续？"

若仅有 Medium / Low：

• 记录到 [VULN_ISSUES]，不阻塞，在 Step 2 审查报告规范层中作为背景提示

若无漏洞：

• 直接进入 Step 2

第 2 步：代码审查

2-A 加载子 Skill

在执行任何审查之前，必须先声明并加载子 Skill：

📂 正在加载子 Skill：code-reviewer

使用 read 工具读取该文件，获取 code-reviewer 的完整执行规范。 若文件不存在，停止并告知用户，等待处理。

2-B 执行审查

按 code-reviewer Skill 的规范执行审查，输入为：

• [CODE_INPUT]
• [CHANGE_PURPOSE]
• [PROPOSAL_INFO]
• [ISSUE_VALIDATION]
• [REVIEW_BASELINE]
• [LINT_ISSUES]（若存在，直接归入规范层问题，不重复检查）
• [VULN_ISSUES]（若存在，在规范层中作为依赖安全背景提示）

审查维度分为两层，意图层优先：

① 意图层（基于背景，结合 [CHANGE_PURPOSE] 判断）

• 改动范围是否与目的匹配（有没有改多/改少）？
• 新增/修改逻辑是否符合需求意图，是否存在逻辑偏差？
• 是否有明显遗漏的场景（结合背景才能发现）？

② 规范层（基于"个人审查习惯"逐项检查）

2-B-1 基于代码证据重新评估问题

在输出审查结论前，必须使用 [CODE_INPUT] 和变更文件完整内容重新评估 [ISSUE_VALIDATION]，尤其是初步分类为 inconclusive 的情况：

• 检查 diff 中是否新增或修改了能稳定复现问题的失败测试；
• 检查变更位置及其调用链是否提供了直接代码证据；
• 对照旧行为、新行为、失败路径和已确认的需求/契约；
• 将新增证据、仍缺失的证据和重新分类理由写回 [ISSUE_VALIDATION]。

如果代码或测试证据足以成立，可重新分类为 confirmed bug 或 valid feature，继续正常审查；只有完成本次重新评估后仍为 inconclusive，才允许在 2-C 设置 needs deep review。

输出结构化审查报告：

### 审查报告

**变更背景确认**
- 目的：<复述 [CHANGE_PURPOSE]，确认理解正确>
- 关联提案：<[PROPOSAL_INFO] 或"无">
- 问题验证：<[ISSUE_VALIDATION] 的分类、直接证据与缺失证据>
- 审查基线：<[REVIEW_BASELINE] 的 HEAD、范围>

**意图层问题（逻辑/需求偏差）**
- [#I01] 问题描述 | 位置：<文件名>:<行号> | 严重程度：<阻塞/警告>

**规范层问题**
- [#C01] 问题描述 | 位置：<文件名>:<行号> | 违反规则：<具体规则>

**改进建议**
- [#S01] 建议描述 | 位置：<文件名>:<行号>

**函数长度提醒**
- <函数名>：XX 行 | 状态：<正常/关注/警告/阻塞>

**测试补充建议**
- 针对新增逻辑，列出建议补充的单元测试（至少 1 个正向 + 1 个边界）

**习惯符合度评分：X / 5**

| 分 | 含义 |
|----|------|
| 5 | 无任何问题，无改进空间 |
| 4 | 有改进建议（`#S`），无规范层问题 |
| 3 | 有规范层警告（`#C`），无阻塞项 |
| 2 | 有阻塞项但可修复，逻辑无偏差 |
| 1 | 多个阻塞项，且存在意图层逻辑偏差 |

**下一步操作**
- `[REVIEW_VERDICT] = needs deep review` → 停止自动修复，列出最小取证步骤
- 无严重问题且问题已确认 → 自动进入调试修复阶段
- 有严重问题 → 等待用户决策

2-C 深审退出与暂停门控

出现下列任一情况，设置 [REVIEW_VERDICT] = needs deep review，停止自动修复和提交准备；不得将推测描述为 blocking finding：

• [ISSUE_VALIDATION] 经 2-B-1 使用 [CODE_INPUT] 重新评估后仍为 inconclusive，或仍无法建立"变更 → 调用链 → 可观察影响"的因果链；
• 涉及安全、权限、认证、敏感信息、并发/取消/事务、持久化/迁移、外部协议、公共 API 或不可恢复副作用，且缺少足够验证；
• 正确性依赖未验证的外部版本、平台行为、官方规范或真实环境；
• 审查者缺少完整 diff、必要调用方、失败路径或配置关闭状态的证据。

needs deep review 的输出必须包含：已知证据、未决问题、不能可靠判定的原因、最小复现/源码/官方资料/集成验证等下一步，以及尚未执行的验证。用户可以另行授权深审，但不能通过"忽略"把该状态改为 ready。

• 若存在严重问题（意图层或规范层），必须在此暂停，询问：

  "发现以上已确认的严重问题，是否继续分析修复方案？"

• 仅当 [REVIEW_VERDICT] 不是 needs deep review，且用户确认后或无严重问题时，继续第 3 步。
• 将完整报告记录为 [REVIEW_REPORT]。

第 3 步：调试与问题修复

仅当用户确认继续，或审查中无严重问题时执行。 若审查报告中无任何问题点（无阻塞项、无警告、无建议），跳过本步骤，直接进入第 4 步。 若 [REVIEW_VERDICT] = needs deep review，不得执行本步骤。

3-A 加载子 Skill

在执行任何修复之前，必须先声明并加载子 Skill：

📂 正在加载子 Skill：parallel-debugging

使用 read 工具读取该文件，获取 parallel-debugging 的完整执行规范。 若文件不存在，停止并告知用户，等待处理。

3-B 执行修复

按 parallel-debugging Skill 的规范执行，输入为 [REVIEW_REPORT] 的所有问题点。

对每一个问题点输出：

#### 问题 [#I01 / #C01]：<问题简述>

**严重程度**：<阻塞/警告/建议>

**根因分析**
<为什么会出现这个问题，源头在哪里>

**修复方案（diff 形式）**
--- a/path/to/file
+++ b/path/to/file
@@ ... @@
- 原有代码
+ 修复代码

**影响范围**
- 直接修改文件：<列表>
- 间接影响文件：<列表>
- 风险评估：<低/中/高>

**测试建议**
- <用例名>（<类型：正向/边界/异常>）

所有修复必须符合"个人审查习惯"，修复后代码不得引入新的违规项。

禁止通过以下方式制造“通过”：

• 删除、跳过、弱化会暴露问题的测试或断言；
• 吞掉错误、把失败静默转换为默认成功结果，或扩大 catch/fallback/重试范围以掩盖真实失败；
• 关闭、绕过或降低 lint、测试、权限、安全或兼容性检查；
• 为单一样例增加硬编码特判，除非它本身是已确认的产品规则；
• 顺手混入无关重构、全仓格式化、依赖升级、生成物或临时文件。

修复必须定位到根因层，保持最小且通用；每个补丁都要列出能证明原问题已修复的测试或验证。若无法满足，撤回补丁并进入 needs deep review。

3-C 暂停门控

输出完整 Patch 列表后，询问：

"以上是所有修复建议，是否应用这些修复？"

将最终确认的修复结论记录为 [PATCH_LIST]。

3-D 修复后复审闭环

应用任何补丁后，不得只验证补丁片段。必须：

1. 重新执行第 1 步，更新 [CODE_INPUT]；
2. 重新检查完整受影响 diff、调用方、旧路径、失败路径及配置关闭状态；
3. 运行最窄且能覆盖原问题的验证，再按风险扩大；
4. 更新 [REVIEW_BASELINE]，并确认审查范围或 HEAD 没有新增未审查内容；
5. 若发现新问题，返回第 2 步；若证据不足，设置 needs deep review，不继续提交准备。

第 4 步：测试执行与回归检查 【支持并发】

所有变更都必须先进入 4-0 选择验证路径；只有选择 tests required 时才执行 4-A 至 4-E。 若 [PATCH_LIST] 为空且测试对本次变更不适用，可跳过测试命令，但必须执行 4-F 的等价最终审查，不能直接进入第 5 步。

4-0 确定验证路径

先将本次验证路径记录为 [VALIDATION_DECISION]：

• tests required：应用了补丁，或变更影响可执行逻辑、用户可见行为、公共 API、配置语义、安全/权限、数据或兼容性；执行 4-A 至 4-E。
• alternative validation：没有适用的自动化测试，但存在能验证改动的静态检查、构建、最小场景或人工检查；执行实际验证后进入 4-F。
• tests not applicable：仅文档、注释、非运行时元数据，或经完整审查确认不影响可执行行为；记录理由后进入 4-F。

不得仅因 [PATCH_LIST] 为空、测试框架未探测到或执行成本较高，就判定测试不适用。

执行模式

Ultracode 并发模式： 4-B（测试执行）与 4-C（覆盖率分析）可并行，节省时间：

使用 Agent 工具并行调用：
- agent('执行测试并收集结果：[4-B 的完整测试执行逻辑]', {label: 'Test Run'})
- agent('运行覆盖率分析：[4-C 的完整覆盖率探测与收集逻辑]', {label: 'Coverage'})

收集两个 Agent 返回的测试结果和 [COVERAGE_DATA]，交由 4-D 进行回归分析。

注意：若覆盖率工具与测试命令合一（如 jest --coverage），两个 Agent 会竞争同一命令——此时退回顺序模式，先4-B 后 4-C。

标准顺序模式： 先4-B 执行测试，再4-C 运行覆盖率，最后4-D 分析回归。

4-A 探测测试框架

按以下优先级探测项目测试命令：

若无法自动探测，询问用户：

"请告知测试运行命令（如 npm test、pytest），或输入 skip 跳过本步骤。"

4-B 执行测试

运行探测到的测试命令，收集：

• 测试总数、通过数、失败数、跳过数
• 失败测试的名称与错误信息

若测试命令本身运行失败（如编译错误），视为全量失败，直接标记为回归风险。

4-C 覆盖率分析（可选，提升回归精度）

若项目已配置覆盖率工具，可将 [POSSIBLE_REGRESSION] 升级为更精确的分类。 若未检测到工具，跳过本步骤，直接进入 4-D。

覆盖率工具探测：

覆盖率数据收集：

针对 [CODE_INPUT] 中的变更行，提取：

• 已被现有测试覆盖的行（covered）
• 未被任何测试覆盖的行（uncovered）

记录为 [COVERAGE_DATA]：

[COVERAGE_DATA]
- <file>:<line-range>：已覆盖
- <file>:<line-range>：未覆盖 ← 高风险盲区

4-D 回归分析

对每个失败的测试，交叉比对 [CODE_INPUT] 中的变更文件列表，并结合 [COVERAGE_DATA]（若存在）：

输出测试验证报告：

### 测试验证报告

**执行摘要**
- 框架/命令：<xxx>
- 结果：通过 N / 失败 M / 跳过 K

**覆盖率摘要**（若有 [COVERAGE_DATA]）
- 变更行覆盖率：N%（已覆盖 X 行 / 共 Y 变更行）
- 未覆盖变更行：<file:line-range>

**回归分析**
- [REGRESSION] <测试名> | 关联文件：<file:line> | 疑似原因：<简述>
- [UNCOVERED_CHANGE] <file:line-range> | 无测试覆盖，变更风险未知
- [POSSIBLE_REGRESSION] <测试名> | 需人工确认
- [PRE_EXISTING] <测试名> | 与本次变更无关

**结论**：<无回归 / 发现 N 个疑似回归 / 存在 M 个未覆盖变更行>

4-E 暂停门控

• 若存在 [REGRESSION]，必须暂停：

  "发现疑似回归，是否返回第 3 步修复后再继续？"

  • 用户确认修复后，重新执行第 4 步验证。
• 若存在 [UNCOVERED_CHANGE]，询问：

  "以下变更行无测试覆盖，建议补充测试后合并。是否现在补充，或标记为后续跟进？"

• 若有 [POSSIBLE_REGRESSION]，不得仅以“忽略”继续；先补充调用链、覆盖率、变更前对照或最小复现。仍无法归因时设置 [REVIEW_VERDICT] = needs deep review。
• 若仅有 [PRE_EXISTING]，记录实际失败命令、关键错误和变更前对照结果后，询问是否继续。
• 无回归且无未覆盖变更时，先按下方规则更新 [REVIEW_VERDICT]，再进入第 5 步。

将测试结论（含覆盖率数据）记录为 [TEST_RESULTS]。

只有测试结论与最终审查均无已知阻塞风险时，才将 [REVIEW_VERDICT] 更新为 ready；否则保留 changes required，或在证据不足时设为 needs deep review。

4-F 无自动化测试路径的最终审查

当 [VALIDATION_DECISION] 为 alternative validation 或 tests not applicable 时，必须在进入第 5 步前执行等价门控：

1. 记录未运行自动化测试的具体原因，不得声称测试通过；
2. 若为 alternative validation，记录实际执行的命令/场景及结果；
3. 确认 [ISSUE_VALIDATION] 已在 2-B-1 完成最终分类，不再是 inconclusive；
4. 确认没有未处理的 blocking finding、未解释的失败或必须补充的验证；
5. 重新检查完整 diff、最终 HEAD 和审查范围，确认没有新增未审查内容；
6. 将 [TEST_RESULTS] 记录为 not run — not applicable: <reason>，或列出替代验证的真实结果。

以上条件全部满足时，将 [REVIEW_VERDICT] 更新为 ready；存在可执行问题时保持 changes required；证据仍不足时设置 needs deep review。

第 5 步：生成提交信息

仅当 [REVIEW_VERDICT] = ready 时生成提交信息和后续提交流程。changes required 必须先完成修复与验证；needs deep review 必须先补齐指定证据，二者均不得生成“可提交”结论。

5-A 加载子 Skill

在生成提交信息之前，必须先声明并加载子 Skill：

📂 正在加载子 Skill：git-commit

使用 read 工具读取该文件，获取 git-commit 的完整执行规范。 若文件不存在，停止并告知用户，等待处理。

5-B 生成提交信息

按 git-commit Skill 的规范执行，输入为：

• [REVIEW_REPORT]
• [PATCH_LIST]
• [TEST_RESULTS]
• [VALIDATION_DECISION]
• [REVIEW_VERDICT]
• [CHANGE_PURPOSE]
• [PROPOSAL_INFO]

生成符合 Conventional Commits 规范的提交信息：

<type>(<scope>): <subject>

背景：<[CHANGE_PURPOSE] 的简洁表述；如有 [PROPOSAL_INFO] 则附上>

改动：
- <要点1>
- <要点2>

修复：
- [#I01] <意图层问题简述>
- [#C01] <规范层问题简述>

测试：
- 执行结果：<通过 N / 失败 M>
- <已补充/建议补充的测试用例>

<若有破坏性变更，注明 BREAKING CHANGE: ...>

常用 type：

输出后询问：

"以上是生成的提交信息，是否确认使用？"

第 5.5 步：Secret / Credential 泄露扫描

这是唯一不允许忽略的硬阻塞门控。 一旦 secret 进入 git history，即使删除文件也可被还原，必须 revoke + rotate，代价极高。

5.5-A 探测扫描工具

内置正则兜底规则（无工具时生效）：

始终跳过：

• 测试文件中明显的 placeholder（"test123", "dummy_key", "example" 等）
• .gitignore 已排除的文件

5.5-B 执行扫描

对 [CODE_INPUT] 中所有新增行（+ 开头）执行扫描。

输出命中列表（预览格式：前5字符 + **** + 后3字符，不输出完整 secret）：

[SECRET_SCAN]
- 命中：<file>:<line> | 类型：<类型> | 预览：xxxxx****xxx

5.5-C 门控（硬阻塞，无忽略选项）

若发现命中：

"⚠️ 检测到疑似 secret/credential，提交已阻塞： [命中列表] 请将其删除或移入环境变量 / .env / Secret Manager，并确认加入 .gitignore，然后重新执行第 1 步。"

• 不提供"忽略"选项，用户处理完毕后须重新从第 1 步开始。

若无命中： 直接进入第 6 步。

第 6 步：Git 提交流程说明

用户确认提交信息后，输出完整操作指引：

# 1. 暂存文件
git add <具体文件1> <具体文件2>
# 或交互式暂存（推荐用于需要精筛变更的场景）
git add -p

# 2. 提交
git commit -m "<完整 commit message>"

# 3. 推送
git push origin <分支名>
# 注意：rebase 后使用 --force-with-lease 而非 --force
git push --force-with-lease origin <分支名>

补充提醒（按实际情况输出）：

• pre-commit hook：若项目配置了 pre-commit，提醒会触发哪些检查，建议 commit 前先本地运行。
• Pull Request：若当前分支非 main/master，建议推送后发起 PR/MR，并可将 commit message 直接用作 PR 描述。
• commit 历史整理：若包含多个零散小 commit，建议先执行 git rebase -i HEAD~N 合并为语义清晰的 1–2 个 commit。
• cherry-pick 提示：若此修复需同步到其他分支，提醒可使用 git cherry-pick。

清理临时文件（最后执行）：

# Bash/Linux/macOS
rm -f review_diff.json review_classified.json

# Windows PowerShell
Remove-Item -Force review_diff.json, review_classified.json -ErrorAction SilentlyContinue

这两个文件由第 1 步生成，不应被提交。若项目中 .gitignore 尚未覆盖，建议补充。

上下文传递约定

每一步结束时，保留完整输出作为下一步输入，不得截断或丢弃。

异常处理