القائمة
ddev 工作流步骤：当 spec 或 detail 文档确认后，判断修改是否可在 PC 上写测试 demo 直接验证，并生成测试用例文档与 demo 代码。触发词："写测试""PC 测试""测试 demo""模拟协议测试""测试用例""写个测试脚本验证"。在 ddev-spec 之后或 ddev-detail 之后使用；不可在无 spec 文档的情况下直接使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
在当前会话里按已写好的实现计划顺序执行任务时使用
在已有规格或多步骤任务需求、且在动代码之前使用。若上游 ddev-pc-test 已产出测试用例，自动走 TDD 流程：先实现测试 demo 代码（红灯），再实现被测代码（绿灯），测试覆盖不到的部分直接开发。
文档审查技能。将文档审查任务派发给独立子代理，重点审查文档基于代码改动的合理性、说明正确性、前后一致性、错漏和逻辑谬误，以及 AI 实现过程中产生的决策记录（implementation-notes.md）。当用户需要审查技术文档、spec文档、设计文档、计划文档、API文档、README 或任何与代码改动相关的文档时使用。
代码修改场景下，spec 文档确认后，需要继续以图优先方式梳理结构体定义、数据流和流程时使用
在代码修改前需要编写 spec 文档且应优先用图表达边界、入口、流程和改动关系时使用（仅限代码改动场景，非项目级架构文档初始化）
在代码实现完成后、准备结束任务或进入发布前使用，用来核对代码实现是否与 spec 文档以及 detail 文档一致，并通过代码质量审查、清理、编码规范和注释审查后给出最终验收结论
| name | ddev-pc-test |
| description | ddev 工作流步骤：当 spec 或 detail 文档确认后，判断修改是否可在 PC 上写测试 demo 直接验证，并生成测试用例文档与 demo 代码。触发词："写测试""PC 测试""测试 demo""模拟协议测试""测试用例""写个测试脚本验证"。在 ddev-spec 之后或 ddev-detail 之后使用；不可在无 spec 文档的情况下直接使用。 |
在 spec 或 detail 文档确认后、编码实现前，判断本次修改是否可以在 PC 上通过测试 demo 直接验证。如果可以，产出测试设计文档和可执行的测试 demo 代码。
本 skill 不负责"编码实现"，也不负责"上板实测"。它只负责回答两个问题：
本 skill 可在两个位置触发：
不可在无 spec 文档的情况下直接使用本 skill。必须先有明确的改动边界和接口定义。
docs/plans/YY-MM-DD_<topic>/detail/tests/test/YY-MM-DD-<feature>/在判断可测试性之前，必须先从固件源码中提取本次改动涉及的所有真实接口签名。禁止凭空发明函数名、参数类型、结构体字段或枚举值。
从 spec/detail 文档中提取所有涉及的模块、接口、数据结构名称，然后搜索：
typedef struct / struct）enum / typedef enum）typedef）优先使用 CodeGraph 结构化查询：
codegraph_search 按函数名/结构体名搜索 → codegraph_node 获取精确定义、完整签名和所在文件行号codegraph_context 按模块名获取该模块所有相关符号和上下文codegraph_explore 批量查看多个相关符号的完整源码CodeGraph 未初始化时回退方案：
grep 按函数名/结构体名模式搜索头文件（*.h）中的声明Read 打开搜索到的头文件，确认精确的函数签名和结构体定义grep 搜索 .c 文件中的函数实现确认签名一致性在测试总览文档（<name>-overview.md）中必须包含 API 签名清单，格式如下：
## 被测 API 签名清单
| 接口 | 签名 | 所在文件 |
|------|------|----------|
| sn_read | `int sn_read(char *buf, size_t len)` | `src/module/sn.c:42` |
| ota_frame_parse | `ota_ret_t ota_frame_parse(const uint8_t *data, ota_frame_t *out)` | `include/ota/ota_proto.h:88` |
| ota_frame_t | `typedef struct { uint8_t cmd; uint16_t len; uint8_t payload[256]; } ota_frame_t` | `include/ota/ota_types.h:15` |
每个条目必须包含：精确的 C 函数签名（含参数名和类型）、结构体/枚举的完整定义、所在文件和行号。
以下条件必须全部满足，才算"可以在 PC 上测试"：
如果有一项不满足，就判定为"不可 PC 测试"，不生成产物。
测试设计文档落到 docs/plans/YY-MM-DD_<topic>/detail/tests/，按需生成以下文件：
detail/tests/
├── <name>-overview.md # 测试总览：可测试性结论、覆盖范围、阅读顺序
├── <name>-cases.md # 测试用例：每个用例含输入、预期输出、覆盖点
├── <name>-env.md # 测试环境：需要什么工具、脚本、固件产物、通信方式
<name>-overview.md 至少包含：
在任何 ASCII 图动笔之前，必须执行 Skill("ddev-diagram") 加载绘制规范。加载完成前禁止写任何 ASCII 图。
<name>-cases.md 至少包含：
sn_read、ota_frame_parse），必须与签名清单一一对应<name>-env.md 至少包含：
测试 demo 代码落到仓库根目录 test/YY-MM-DD-<feature>/，目录结构建议：
test/25-06-18-ota-protocol/
├── README.md # 本目录说明：测什么、怎么跑、依赖什么
├── host_sim/
│ └── ota_host.py # Python 模拟上位机：发包、收响应、校验
├── device_demo/
│ └── ota_device_demo.c # 设备端 demo：接收、解析、回复（可 PC 编译）
├── fixtures/
│ └── test_fw.bin # 测试用固件产物（小尺寸占位）
└── run_test.ps1 # Windows 一键运行脚本
每个测试用例的预期输出必须可编程比对。推荐做法：
assert 关键字段测试产物生成完毕后，必须逐项核对以下清单：
如有任一项不通过，必须在修复后再进入下一步。
测试设计文档和 demo 代码完成后：
ddev-plan 拆解执行计划ddev-gate 阶段必须跑通，不通过不算验收完成