用途
verify-before-merge 是一个基于证据的完成门禁技能。它用于在你即将声称工作“完成”“修复”或“通过”，或者即将合并变更时，强制先运行所有验证并粘贴真实输出。其核心规则是：证据先于断言，始终如此。任何没有新鲜执行命令输出的“完成”“修复”或“通过”声明都构成违规；“应该会通过”“我有信心”以及凭记忆认为通过都不算数。
主要能力
该技能定义了一套门禁检查流程，由独立子代理在变更工作树中执行，并返回固定格式的门禁摘要。检查项包括：
- 运行 verify_commands（.guardrails/config.yaml）中的每条命令：完整测试套件、类型检查、linter，要求零失败、输出干净。
- 运行 .guardrails/scripts/check-trace.sh，要求干净。
- 运行 .guardrails/scripts/check-ids.sh，要求无草稿 ID、无草稿命名文件、无重复和格式错误的 ID。
- 变更自身的声明，分为两部分：子代理负责确认计划中每个 Implements ID 在变更工作树中存在对应的 verifies: 测试，并在摘要中指明哪个测试验证哪个 ID；调度者负责从派发报告中读取这些测试在通过前是否因正确原因失败过（red -> green: 行）。
- 覆盖率门禁：如果配置了 coverage_command，则运行并根据类别目标判断：A 类无需覆盖率，B 类语句覆盖率，C 类语句 + 决策覆盖率（MC/DC 可选）。缺口除非用户明确接受并记录，否则视为失败。
- 健壮性完整性（B/C 类）：每个 Implements ID 都有正常用例和异常输入测试。
- git status：无未提交工作，无游离文件。
- 每次一致性审查都已运行，调度者已修复或处置每个发现。
门禁摘要具有固定结构，包含每条命令的通过/失败/跳过计数、套件总计、覆盖率数字、Implements 映射、健壮性覆盖、git status 结果、每条命令输出的尾部以及日志路径。
使用方式
开始时宣布：“Using the verify-before-merge skill.”
不要在自己的上下文中运行门禁。使用你的工具（Task 或 Agent 工具、/agent 命令）派发一个全新的子代理进入变更工作树运行所有检查。子代理将每条检查的原始输出捕获到仓库外或 gitignored 路径的日志文件（例如 $TMPDIR/<branch>-gate.log），只返回门禁摘要，不返回 diff 或粘贴的日志。
子代理只报告，不修复。任何失败都应停止，由调度者决定修复内容，像其他任务一样派发修复到自己的任务工作树，合并到变更分支而非基础分支，然后重新派发整个门禁。部分通过的结果不算数。
退出码 0 不等于通过。必须从报告的通过/失败计数读取判定，绝不能从状态码读取。
适用场景
适用于任何需要声称“完成”“修复”或“通过”或合并变更的场景，包括调度者、任务子代理或门禁子代理。特别适用于变更工作树中所有计划任务分支已合并到变更分支（develop-change）后的门禁阶段。
限制
- 不得削弱任何检查以通过门禁（跳过测试、放宽配置、编辑预期输出），也不得在派发提示中削弱检查。
- 如果必须停止，应如实报告失败：什么失败了、实际输出、尝试了什么。
- 门禁摘要中缺少的数字应向子代理索取，而不是重新运行命令。
- 只有完全绿色的门禁才允许 merge-change 通过步骤 6a。
- 检查 4 的另一半由调度者从派发报告回答，检查 5 的另一半由用户回答（只有用户能接受文档化的覆盖率缺口），检查 8 完全由调度者回答。
- 不要将 check-review.sh 添加到此列表；它读取的验证记录在 merge-change 步骤 5 写入，在 6c 检查。
- 完成报告必须引用门禁摘要并引用日志路径，不得重新运行命令查看输出。
完成条件
门禁摘要报告其包含的每一行都是绿色并带有计数：检查 1、2、3、5、6、7 以及子代理负责的检查 4 的一半。调度者在完成报告中回答检查 4 的另一半和检查 8。完成报告引用门禁摘要并引用日志路径。变更工作树中的 git status 干净。