| name | b6-verification-before-completion |
| description | B6x 完成前验证 — 在声称任何工作完成、修复、通过之前，强制运行验证命令并展示输出证据。
TRIGGER when: 即将声称工作完成、Bug 已修复、编译通过、测试通过、功能正常、代码质量达标，
或准备提交/推送/创建 PR，或在 /b6-build、/b6-auto-debug、/b6-code-review 完成后。
即任何正面陈述工作状态的时刻。
DO NOT TRIGGER when: 正在进行中的操作（搜索、阅读、编辑），纯信息查询，用户闲聊。
|
| user-invocable | true |
B6x 完成前验证
铁律
没有新鲜的验证证据，就不能声称完成。
如果你在本消息中没有运行过验证命令，就不能声称它通过了。
违反这条规则的字面意思，就是违反这条规则的精神。
门控函数
在声称任何状态或表达满意之前：
1. 识别：什么命令/操作能证明这个断言？
2. 执行：运行验证（全新的，完整的）
3. 阅读：完整输出，检查退出码，统计失败
4. 验证：输出是否确认断言？
- 否 → 陈述实际状态并附证据，不做断言
- 是 → 陈述断言并附证据
5. 然后才能声称
跳过任何步骤 = 未验证
B6x 验证矩阵
驱动/外设代码修改
| 断言 | 必须验证 | 通过标准 | 验证命令 |
|---|
| "编译通过" | 编译输出 | 0 Error, ≤5 Warning | /b6-build |
| "功能正常" | 烧录 + RTT 日志 | RTT 输出符合预期，无异常 | /b6-auto-debug |
| "Bug 已修复" | 原始症状不再复现 | 修复前的问题消失 | /b6-auto-debug |
BLE 相关修改
| 断言 | 必须验证 | 通过标准 | 验证命令 |
|---|
| "Profile 添加完成" | 编译 + 连接测试 | 手机可发现 Service/Characteristic | /b6-build + 烧录 |
| "连接参数正确" | 实际连接参数 | Interval/Latency/Timeout 在规范范围内 | RTT 日志或抓包 |
| "数据传输正常" | Notify/Write 测试 | 数据完整收发 | RTT 日志 |
硬件配置
| 断言 | 必须验证 | 通过标准 | 验证命令 |
|---|
| "引脚配置正确" | 配置验证 | 0 Error, 0 Warning | /b6-validate-hardware |
| "时钟配置正确" | 配置验证 | 频率在允许范围内 | /b6-validate-hardware |
| "DMA 配置正确" | 配置验证 | 通道无冲突 | /b6-validate-hardware |
代码质量
| 断言 | 必须验证 | 通过标准 | 验证命令 |
|---|
| "代码质量达标" | 代码审查 | 无 Critical/Warning ≥ 75 分问题 | /b6-code-review |
| "项目完整" | 项目检查 | 所有检查项通过 | /b6-project-checklist |
证据模板
编译证据
✅ 编译验证证据：
工具链: {Keil MDK / GCC}
输出: {0} Error(s), {N} Warning(s)
产物: {文件路径}
退出码: {0 / 非0}
烧录验证证据
✅ 烧录验证证据：
调试器: {DAPLink / J-Link}
固件: {ELF 路径}
烧录: 成功
目标状态: {running / halted}
RTT 日志证据
✅ RTT 输出证据：
附加地址: {0x2000xxxx}
关键日志:
- {日志行1}
- {日志行2}
异常检查: {无异常 / 发现异常: ...}
硬件配置证据
✅ 硬件配置验证证据：
错误: {0}
警告: {0}
引脚分配: {已验证}
代码审查证据
✅ 代码审查验证证据：
Critical: {0}
Warning: {N} (均为 < 75 分)
过滤误报: {M}
结论: {通过 / 不通过}
回归验证（Bug 修复）
修复 Bug 时，必须完成红-绿循环：
1. 复现 Bug → 记录症状（RTT 日志/错误现象）
2. 修改代码
3. 验证修复 → 编译通过 → 烧录 → 原始症状消失
4. 验证无回归 → 原有功能仍正常
5. 才能声称 "Bug 已修复"
跳过步骤 4（回归验证）= 未完成验证。
适用时机
以下时刻 MUST 触发本 Skill：
- 任何包含"完成"、"修复"、"通过"、"正常"、"成功"的声明
- 任何表达满意的情绪词（"好了"、"没问题了"、"搞定了"）
- 准备提交代码 / 推送 / 创建 PR
- 从一个任务切换到下一个任务
- Agent 或子任务报告完成后
- /b6-build、/b6-auto-debug、/b6-code-review 执行完毕后
规则覆盖范围：
- 精确短语（"编译通过"）
- 近义词和同义转述（"看起来没问题"、"应该好了"）
- 任何暗示成功的表达（包括省略验证直接跳到下一步）
排除： 正在进行中的操作（搜索、阅读、编辑）、纯信息查询、用户闲聊。
常见自我辩解预防
| 借口 | 现实 |
|---|
| "应该能工作了" | 运行验证命令 |
| "代码逻辑没问题" | 编译过了吗？编译器比你严谨 |
| "之前的测试通过了" | "之前"不等于"现在"，重新运行 |
| "只是改了一行注释" | 改了什么就验证什么，编译一次花不了几秒 |
| "嵌入式验证太麻烦" | 不验证的代价是硬件上不可预测的行为 |
| "Linter/静态分析过了" | 静态分析 ≠ 编译通过 ≠ 硬件上能跑 |
| "这个改动很简单" | 简单的改动也引入过最难的 Bug |
| "我很确定" | 确信 ≠ 证据 |
为什么这很重要
来自 B6x 嵌入式开发的实际失败教训：
- 编译通过但未烧录验证 → 芯片行为与预期不符，浪费时间排查
- RTT 有输出但未验证内容 → 看似正常实则数据错误（如 UART 乱码）
- BLE Service 添加后未连接测试 → 手机无法发现，Profile 句柄错位
- Agent/子任务报告成功但未独立验证 → 漏改文件、编译未实际执行
- 跳过回归验证 → Bug 修复引入新问题，原功能退化
底线：不验证就声称完成，等于对用户撒谎。信任一旦打破就很难重建。
红旗 — 看到这些想法时停止
| 想法 | 为什么禁止 |
|---|
| "编译通过了，应该没问题" | 编译通过 ≠ 功能正确，嵌入式尤其如此 |
| "RTT 有输出了，修好了" | 有输出 ≠ 正确输出，验证具体内容 |
| "代码审查过了，可以提交" | 审查通过 ≠ 编译通过，编译 ≠ 运行正确 |
| "就跳过验证这一次" | 没有例外 |
| "没时间验证了" | 不验证就提交，返工花的时间更多 |
| "Agent/子任务说完成了" | 必须独立验证，不接受代理报告 |
与其他 Skill 的关系
本 Skill 被以下 Skill 的流程内嵌引用：
| Skill | 嵌入位置 | 作用 |
|---|
/b6-build | 退出条件 | 编译结果必须用本 Skill 的证据模板报告 |
/b6-auto-debug | 阶段 1-4 通过条件 | 每个阶段的通过条件就是验证门控 |
/b6-code-review | Step 5 生成报告前 | 报告数据必须来自实际运行，不可推断 |
调用本 Skill 的时机：
- 在上述任何 Skill 执行完成后，声称成功之前
- 在手动修改代码后，准备向用户报告结果时
- 在准备提交/推送/创建 PR 时
- 用户直接调用
/b6_verification-before-completion
执行示例
示例 1：修复 UART 驱动 Bug
用户: "UART 发送数据乱码，帮我看看"
[诊断 + 修改代码]
门控执行:
1. 识别: 需要编译 + 烧录 + RTT 验证
2. 执行: /b6-build → /b6-auto-debug
3. 阅读:
✅ 编译验证证据：
工具链: Keil MDK
输出: 0 Error(s), 1 Warning(s)
产物: mdk/output/bleUart.hex
退出码: 0
✅ RTT 输出证据：
附加地址: 0x20001234
关键日志:
- UART init OK, baudrate=115200
- TX: 48 65 6C 6C 6F ("Hello")
- RX: 48 65 6C 6C 6F (match)
异常检查: 无异常
4. 验证: 原始症状（乱码）消失，数据正确
5. 断言: "UART Bug 已修复，编译通过，RTT 数据收发正常"
示例 2：添加 BLE Service
用户: "加一个 Battery Level Service"
[实现代码]
门控执行:
1. 识别: 需要编译 + 手机连接验证
2. 执行: /b6-build → 烧录 → 手机 nRF Connect 测试
3. 阅读:
✅ 编译验证证据：
工具链: GCC
输出: 0 Error(s), 0 Warning(s)
产物: build/bin/bleBatt.bin
退出码: 0
✅ RTT 输出证据：
关键日志:
- Battery Service added, handle: 0x002A
- Connection established, interval: 30ms
- Read request: Battery Level = 85%
异常检查: 无异常
4. 验证: 手机可发现 Battery Service，读取值正确
5. 断言: "Battery Level Service 添加完成，功能验证通过"
底线
验证没有捷径。
运行命令。阅读输出。然后再声称结果。
这是不可协商的。
