菜单
B6x 完成前验证 — 在声称任何工作完成、修复、通过之前，强制运行验证命令并展示输出证据。 TRIGGER when: 即将声称工作完成、Bug 已修复、编译通过、测试通过、功能正常、代码质量达标， 或准备提交/推送/创建 PR，或在 /b6-build、/b6-auto-debug、/b6-code-review 完成后。 即任何正面陈述工作状态的时刻。 DO NOT TRIGGER when: 正在进行中的操作（搜索、阅读、编辑），纯信息查询，用户闲聊。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
编译 B6x SDK 工程 (Keil/GCC 自动检测)，解析编译日志，迭代修复错误和警告直到 0 ERROR 且 WARNING ≤ 5。 TRIGGER when: 用户要求编译、build、构建项目，修复编译错误/警告，检查编译结果，或提及 Keil/GCC 编译问题。 DO NOT TRIGGER when: 用户要求烧录/调试/下载固件（用 /b6-auto-debug）、纯代码审查、BLE协议问题、无硬件连接。
根据应用需求推荐 BLE 库并生成 cfg.h 配置。 TRIGGER when: 用户询问 BLE 库选择、应该用哪个 BLE 库、库配置、连接数配置、RAM 配置、 BLE 角色配置（Master/Slave）、BLE_LITELIB/BLE_LARGELIB 设置、ANCS Client 支持、 低功耗 BLE 配置、多连接配置、Mesh 配置。即使没有明确说 "推荐库"，只要涉及 BLE 库/连接数/角色的选择，也应使用此 skill。 DO NOT TRIGGER when: 用户要求创建新项目（用 /b6-create-project）、编译构建（用 /b6-build）、 烧录调试（用 /b6-auto-debug）、代码审查（用 /b6-code-review）、硬件配置验证（用 /b6-validate-hardware）。
翻译 BLE 错误码，提供排查建议。 TRIGGER when: 用户询问 BLE 错误码含义、错误码翻译、0x 开头的错误代码、ATT_ERR/GAP_ERR/SMP_ERR 等错误常量、配对失败原因、连接错误、GATT 错误、BLE 返回码、协议栈错误。即使没有明确说 "翻译错误码"， 只要出现 BLE 相关的数字错误码或错误常量名，也应使用此 skill。 DO NOT TRIGGER when: 用户要求创建新项目（用 /b6-create-project）、编译构建（用 /b6-build）、 烧录调试（用 /b6-auto-debug）、代码审查（用 /b6-code-review）、硬件配置验证（用 /b6-validate-hardware）。
验证 B6x 硬件配置（引脚冲突/时钟/DMA/中断/Timer）是否符合芯片约束。使用此 skill 验证硬件配置的正确性。 TRIGGER when: 用户提及引脚配置、硬件验证、pin mux、外设冲突、ADC引脚、UART引脚、Timer引脚、DMA配置、中断优先级、时钟配置、检查配置冲突、验证硬件设置、引脚能否用作某功能。即使用户没有明确说"验证硬件"，只要涉及引脚/时钟/DMA/中断的配置检查，也应使用此 skill。 DO NOT TRIGGER when: 纯代码审查、编译错误修复、BLE协议问题、编写新驱动代码、解释函数作用、烧录程序。
B6x 系统化烧录调试 — 编译 → 诊断 → 烧录 → RTT 监控。 先理解失败原因，再采取行动。 TRIGGER when: 用户要求烧录、调试、下载固件、RTT监控、DAPLink/J-Link 操作、 自动调试、flash编程、运行固件、连接失败、烧录失败、RTT无数据 DO NOT TRIGGER when: 仅编译请求（用 /b6-build）、纯代码审查、无硬件连接
为现有 B6x SDK Keil 项目生成 CMakeLists.txt，实现 Keil → GNU/CMake 迁移。 TRIGGER when: 用户要求为现有项目生成 CMakeLists.txt、添加 GCC/CMake 支持、迁移 Keil 项目到 GNU 环境、 创建 CMake 配置、转换 Keil 工程到 CMake、为项目添加 GCC 编译支持、支持 CI/CD 编译、 "帮我生成 CMakeLists.txt"、"添加 CMake 支持"、"迁移到 GCC"、"让项目支持 GCC 编译"。 DO NOT TRIGGER when: 用户要求创建全新项目（用 /b6-create-project）、编译现有项目（用 /b6-build）、 烧录调试（用 /b6-auto-debug）、纯代码审查、BLE 协议问题、仅查看项目结构。
| 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 |
没有新鲜的验证证据，就不能声称完成。
如果你在本消息中没有运行过验证命令，就不能声称它通过了。
违反这条规则的字面意思，就是违反这条规则的精神。
在声称任何状态或表达满意之前：
1. 识别：什么命令/操作能证明这个断言？
2. 执行：运行验证（全新的，完整的）
3. 阅读：完整输出，检查退出码，统计失败
4. 验证：输出是否确认断言？
- 否 → 陈述实际状态并附证据，不做断言
- 是 → 陈述断言并附证据
5. 然后才能声称
跳过任何步骤 = 未验证
| 断言 | 必须验证 | 通过标准 | 验证命令 |
|---|---|---|---|
| "编译通过" | 编译输出 | 0 Error, ≤5 Warning | /b6-build |
| "功能正常" | 烧录 + RTT 日志 | RTT 输出符合预期，无异常 | /b6-auto-debug |
| "Bug 已修复" | 原始症状不再复现 | 修复前的问题消失 | /b6-auto-debug |
| 断言 | 必须验证 | 通过标准 | 验证命令 |
|---|---|---|---|
| "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 输出证据：
附加地址: {0x2000xxxx}
关键日志:
- {日志行1}
- {日志行2}
异常检查: {无异常 / 发现异常: ...}
✅ 硬件配置验证证据：
错误: {0}
警告: {0}
引脚分配: {已验证}
✅ 代码审查验证证据：
Critical: {0}
Warning: {N} (均为 < 75 分)
过滤误报: {M}
结论: {通过 / 不通过}
修复 Bug 时，必须完成红-绿循环：
1. 复现 Bug → 记录症状（RTT 日志/错误现象）
2. 修改代码
3. 验证修复 → 编译通过 → 烧录 → 原始症状消失
4. 验证无回归 → 原有功能仍正常
5. 才能声称 "Bug 已修复"
跳过步骤 4（回归验证）= 未完成验证。
以下时刻 MUST 触发本 Skill：
规则覆盖范围：
排除： 正在进行中的操作（搜索、阅读、编辑）、纯信息查询、用户闲聊。
| 借口 | 现实 |
|---|---|
| "应该能工作了" | 运行验证命令 |
| "代码逻辑没问题" | 编译过了吗？编译器比你严谨 |
| "之前的测试通过了" | "之前"不等于"现在"，重新运行 |
| "只是改了一行注释" | 改了什么就验证什么，编译一次花不了几秒 |
| "嵌入式验证太麻烦" | 不验证的代价是硬件上不可预测的行为 |
| "Linter/静态分析过了" | 静态分析 ≠ 编译通过 ≠ 硬件上能跑 |
| "这个改动很简单" | 简单的改动也引入过最难的 Bug |
| "我很确定" | 确信 ≠ 证据 |
来自 B6x 嵌入式开发的实际失败教训：
底线：不验证就声称完成，等于对用户撒谎。信任一旦打破就很难重建。
| 想法 | 为什么禁止 |
|---|---|
| "编译通过了，应该没问题" | 编译通过 ≠ 功能正确，嵌入式尤其如此 |
| "RTT 有输出了，修好了" | 有输出 ≠ 正确输出，验证具体内容 |
| "代码审查过了，可以提交" | 审查通过 ≠ 编译通过，编译 ≠ 运行正确 |
| "就跳过验证这一次" | 没有例外 |
| "没时间验证了" | 不验证就提交，返工花的时间更多 |
| "Agent/子任务说完成了" | 必须独立验证，不接受代理报告 |
本 Skill 被以下 Skill 的流程内嵌引用：
| Skill | 嵌入位置 | 作用 |
|---|---|---|
/b6-build | 退出条件 | 编译结果必须用本 Skill 的证据模板报告 |
/b6-auto-debug | 阶段 1-4 通过条件 | 每个阶段的通过条件就是验证门控 |
/b6-code-review | Step 5 生成报告前 | 报告数据必须来自实际运行，不可推断 |
调用本 Skill 的时机：
/b6_verification-before-completion用户: "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 数据收发正常"
用户: "加一个 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 添加完成，功能验证通过"
验证没有捷径。
运行命令。阅读输出。然后再声称结果。
这是不可协商的。