Menú
在代码实现完成后、准备结束任务或进入发布前使用，用来核对代码实现是否与 spec 文档以及 detail 文档一致，并通过代码质量审查、清理、编码规范和注释审查后给出最终验收结论
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
在当前会话里按已写好的实现计划顺序执行任务时使用
在已有规格或多步骤任务需求、且在动代码之前使用。若上游 ddev-pc-test 已产出测试用例，自动走 TDD 流程：先实现测试 demo 代码（红灯），再实现被测代码（绿灯），测试覆盖不到的部分直接开发。
文档审查技能。将文档审查任务派发给独立子代理，重点审查文档基于代码改动的合理性、说明正确性、前后一致性、错漏和逻辑谬误，以及 AI 实现过程中产生的决策记录（implementation-notes.md）。当用户需要审查技术文档、spec文档、设计文档、计划文档、API文档、README 或任何与代码改动相关的文档时使用。
代码修改场景下，spec 文档确认后，需要继续以图优先方式梳理结构体定义、数据流和流程时使用
在代码修改前需要编写 spec 文档且应优先用图表达边界、入口、流程和改动关系时使用（仅限代码改动场景，非项目级架构文档初始化）
当需要基于仓库代码推导刷写参数，并复用统一流程完成固件探测、分包或刷写时使用。
| name | ddev-gate |
| description | 在代码实现完成后、准备结束任务或进入发布前使用，用来核对代码实现是否与 spec 文档以及 detail 文档一致，并通过代码质量审查、清理、编码规范和注释审查后给出最终验收结论 |
这个 skill 用于代码实现阶段的最终验收。
它不是普通代码审查，也不是只跑测试的验证门禁。它的核心任务根据项目语言分支：
C 项目（.c / .h）— 四段流程：
ddev-clean，在受限范围内做垃圾代码清理和可维护性提升；若清理改了代码，再重新回到一致性验收ddev-c-pro，统一完成编码规范审查 + 代码质量审查（安全、架构性能、死代码/重复）。C 项目不再单独调用 ddev-code-review，由 c-pro 吸收其 C 相关职责。若审查不通过，修改后重新回到一致性验收ddev-comment-gen，对最终代码做注释完整性和规范性审查；若审查不通过，修改后重新回到一致性验收非 C 项目 — 五段流程：
ddev-clean 清理（同上）ddev-code-review 代码质量审查（安全、性能、可维护性）；若审查不通过，修改后重新回到一致性验收第一段一致性验收要对照的设计输入包括：
ddev-spec 产出的 spec 文档ddev-detail 产出的 detail 文档目标是明确回答：
这里的设计一致性判断遵循同一条文档规则：spec、detail、exec plan 只定义”这次要做什么”。凡是文档里没有明确写到的实现、结构、流程、共享状态、旁路逻辑或验证动作，都按未获批准处理，而不是等待文档再额外写一段”明确不做”。
如果审查 agent 发现任何未被批准的差异，就必须审核不通过，打回主 agent 修改。主 agent 修改后，必须重新进入这个 skill，再拉审查 agent 重审。这个循环要一直持续到审查 agent 给出一致性 pass。
但一致性 pass 还不是最终放行：主 agent 还必须再拉一个独立 subagent，受限调用 ddev-clean 做清理。如果清理阶段产生任何代码修改，就必须重新进入这个 skill，再次拉独立审查 agent 做一致性重审。
一致性重审通过后，对 C 项目：拉独立 subagent 加载 ddev-c-pro skill，统一完成编码规范审查和代码质量审查（安全、架构性能、死代码/重复）。C 项目不再单独调用 ddev-code-review。对非 C 项目：先拉 ddev-code-review 做代码质量审查，再按语言加载编码规范审查 skill。如果审查不通过，修改后同样要重新进入这个 skill 从头验收。
c-pro / 编码规范审查通过后，还需再拉一个独立 subagent 做注释/文档审查。C 项目加载 ddev-comment-gen skill，对最终代码做注释完整性和规范性审查。其他语言项目根据实际语言加载对应的注释审查 skill。如果注释审查不通过，修改后同样要重新进入这个 skill 从头验收。
只有在清理后的最终代码通过一致性验收、代码规范与质量审查（C 项目由 c-pro 统一完成，非 C 项目由 code-review + 语言规范审查完成）和 注释审查均通过后，主 agent 才能宣称”计划已经完成”。
在以下场景使用：
如果只是想先检查有没有跑验证命令，优先用 verification-before-completion。
如果只是想让另一个视角找 bug，优先用 ddev-code-review。
如果目标是实现与设计一致性验收，并在通过后继续做一轮受限 deslop / maintainability cleanup，再经代码质量审查、编码规范审查和注释审查，最后复核一致性，用这个 skill。
如果主 agent 正准备宣称“已经完成计划”“已经按计划实现完成”“可以正式收尾”，这个 skill 是必经门禁。
开始验收前，至少定位这些输入：
能拿到的话，额外读取：
implementation-notes.md（由 ddev-exec 在执行过程中写入，含 Design Decisions / Deviations / Tradeoffs / Open Questions）task_plan.md（由 ddev-exec 创建，含任务 checkbox 和 Errors 表）ddev-plan 产出的执行计划如果连 spec 或 detail 文档都没有，不能直接给通过结论。
如果无法唯一定位 spec 文档、detail 文档或本次改动范围，不要退化成泛化 code review。此时应立即停止一致性验收，并输出：
need-info：信息暂时不足，但理论上可补齐blocked：当前上下文下无法继续定位或缺失关键设计输入如果拿到了 exec plan，还要检查它是否明确引用了 spec / detail / flow / dataflow 文档，是否把这些文档里的约束正确传递给执行阶段；不能把 exec plan 当成脱离设计文档独立成立的真源。
验收范围必须先定清楚，再开始对照。
优先级如下：
ddev-plan 中列出的文件清单如果 exec plan 中列出的文件范围明显超出 spec / detail / flow / dataflow 文档允许的边界，也要按范围异常处理，不能默认放行。
后续 ddev-clean 的作用范围默认也必须继承这份范围；如果能拿到更窄的 changed-files 列表，优先把清理范围进一步收敛到 changed files。
ddev-c-pro 规范审查和 ddev-comment-gen 注释审查（C 项目）或其他语言的编码规范审查和注释审查的范围与 cleaner 一致，审查最终版本的代码文件。
如果为了满足 ddev-clean 的 regression-tests-first 规则，必须补最小测试覆盖，则允许把锁定既有行为所必需的最小测试文件纳入 cleanup 附属范围；这些测试文件也必须计入 cleanup 范围说明和后续验证证据。
如果范围仍然不清楚，先输出 need-info，不要自己扩散成全仓库审查。
task_plan.md 和 implementation-notes.md，确认以下条件同时满足才能继续验收流程，否则返回 blocked：
[x]（completed）implementation-notes.md 中存在且 Open Questions 已全部回答完毕（无未决项）scripts/check-complete，运行确认输出 "ALL PHASES COMPLETE"implementation-notes.md、代码范围和本轮验证证据。implementation-notes.md，提取 Deviations 和 Open Questions：
blocked；若已回答，将其回答结论纳入验收范围pass、need-info 或 blocked。blocked，主 agent 必须先修改代码或补齐文档，再重新进入这个 skill，重新拉审查 agent 验收。need-info，主 agent 必须先补齐缺失输入、范围或验证证据，不得进入 cleanup；补齐后重新进入这个 skill。pass 时，主 agent 才能进入清理阶段。ddev-clean。ddev-clean 的 regression-tests-first、显式 cleanup plan、分 smell 分 pass、最小 diff、最小作用域规则。pass 时，主 agent 才能进入代码规范与质量审查阶段。.c / .h）：主 agent 拉一个新的独立 subagent 加载 ddev-c-pro skill，对当前代码范围统一完成编码规范审查和代码质量审查（安全、架构性能、死代码/重复）。C 项目不再单独调用 ddev-code-review。ddev-c-pro 中的设计规范、命名规范、风格偏好、安全、架构性能、死代码/重复逐项审查，对问题按 CRITICAL/HIGH/MEDIUM/LOW 分级。pass 或 blocked。存在 CRITICAL 或 HIGH → blocked。仅 MEDIUM/LOW → pass（在建议项中列出）。blocked，主 agent 必须按清单修改代码，然后重新进入这个 skill（从一致性验收重新开始完整流程）。ddev-code-review skill 做代码质量审查，结论 REQUEST CHANGES（CRITICAL/HIGH）视为 blocked。通过后再按语言加载编码规范审查 skill（如存在），不通过则回到一致性验收。pass（或合理跳过）时，主 agent 才能进入注释/文档审查阶段。.c / .h）：拉新的独立 subagent 加载 ddev-comment-gen skill，对通过规范审查的最终代码做注释审查pass 或 blocked，blocked 时必须附带缺失项清单和补全建议。blocked，主 agent 必须按清单补全注释，然后重新进入这个 skill（从一致性验收重新开始完整流程）。pass（或合理跳过）时，主 agent 才能宣称”已经按计划完成”。如果没有新的、可归属到本轮结论的验证证据，最多输出 need-info，不能输出 pass。
如果清理 subagent 产出的改动超出既定范围、引入新的抽象层、或让实现偏离 spec/detail/exec plan，也必须回到 blocked，不能因为”一致性阶段之前通过过”而继续放行。
codegraph_impact 评估改动影响面：对关键符号做影响半径分析，确认实际影响范围与 spec/detail 声明的范围一致；若存在文档未声明的受影响模块，视为偏离blockedddev-clean 清理，必须按清理后的最终代码重做对照，不能沿用清理前结论审查提示模板见 reviewer-prompt.md。
ddev-c-pro skill，统一完成编码规范审查和代码质量审查（已吸收 ddev-code-review 的 C 相关职责）ddev-code-reviewcodegraph_impact 评估改动影响面：确认审查范围内外的符号依赖，避免遗漏受影响的文件blocked。仅 MEDIUM/LOW → pass（在建议项中列出）c-pro 审查提示模板见 reviewer-prompt.md。
非 C 项目：先调用
ddev-code-review做代码质量审查，再按语言调用编码规范审查 skill。无对应编码规范审查 skill 则跳过，在验收结论中注明。
ddev-comment-gen skill，按其中定义的审查维度逐文件、逐函数、逐结构体验证注释完整性codegraph_impact 评估改动影响面：确认所有目标文件的公开 API、结构体、枚举均已纳入审查blocked，并附带逐项缺失清单和补全建议文本comment-gen 审查提示模板见 reviewer-prompt.md。
非 C 项目：如果没有对应的注释审查 skill，合理跳过本阶段。在验收结论中注明"本语言暂无注释审查 skill，已跳过"。
ddev-clean skill，遵守 regression-tests-first、显式 cleanup plan、最小 diff、最小作用域规则codegraph_impact 评估清理影响面：在删除/重命名符号前，确认没有外部调用方；清理操作不得波及范围外代码cleaner 提示模板见 reviewer-prompt.md。
ddev-code-review skill，按 4 阶段流程执行：识别变更 → codegraph 结构影响分析 → 深度审查 → 结构化报告codegraph_impact 评估改动影响面：确认变更波及半径，交叉验证调用链APPROVE / REQUEST CHANGES / COMMENT，REQUEST CHANGES（CRITICAL/HIGH 问题）视为 blockedcode-reviewer 提示模板见 reviewer-prompt.md。
默认重点检查：
if/else对于 C 项目，代码规范审查由 ddev-c-pro skill 专门负责，注释审查由 ddev-comment-gen skill 专门负责，此处一致性验收不重复做风格/注释/命名审查。对于非 C 项目，编码规范和注释审查按对应语言的 skill 路由（如无对应 skill 则跳过）。
对于嵌入式 C / 纯 C 项目，额外重点检查：
context / session / handle 结构体enum 或等价显式语义，而不是魔法数字switch、表驱动或状态机static 私有函数边界是否与文档设计一致详细检查清单见 acceptance-checklist.md。
标准输出样例见 example-acceptance-output.md。
只允许输出这三种最终结论：
passneed-infoblockedpass只有在以下条件同时满足时才能给：
implementation-notes.md 中 Open Questions 已全部回答完毕ddev-clean 清理，则清理后的最终代码也已重新完成一致性验收ddev-c-pro 统一完成，非 C 项目由 ddev-code-review + 语言规范审查完成）.c / .h），则 ddev-comment-gen 注释审查已通过；若为其他语言，则对应的注释审查已通过或已合理跳过need-info用于信息不足但还不构成硬阻塞的情况，例如：
pass判定原则：
need-infopass，但继续核对仍然有意义的，用 need-infoblocked用于无法验收或明显不通过的情况，例如：
implementation-notes.md 不存在，或其中 Open Questions 仍有未回答项ddev-clean 修改了代码，但清理后的实现还没有重新完成一致性验收blocked，且修改后尚未重新完成完整门禁流程（C 项目为 ddev-c-pro 审查 blocked，非 C 项目为 ddev-code-review 或语言规范审查 blocked）blocked，且修改后尚未重新完成完整门禁流程判定原则：
blockedblockedblocked最终输出必须包含：
pass / need-info / blockedimplementation-notes.md 中存在 Deviations 条目，必须在差异归类或发现的问题中对每一项偏离给出验收结论（已接受 / 需修正 / 需补文档）ddev-clean，要明确说明：清理是否改代码、清理范围是什么、清理后是否已重新验收ddev-c-pro 统一输出此结论；非 C 项目分别列出 ddev-code-review 和语言规范审查结论。若 blocked 则附修改项清单。若项目语言无对应审查 skill 则注明"已跳过"如果没有发现不一致，也不能只说“通过”，仍要说明对照了什么。
如果需求结论依赖真实目标板、外设、时序、功耗、波形或现场观察，而本轮没有对应人工或现场证据，不能给 pass。
如果审查结论是 blocked，输出里必须明确列出“需要主 agent 修改的项”，这样主 agent 才能按项修复并重新送审。
ddev-specddev-detailverification-before-completionddev-code-review（非 C 项目）ddev-cleanddev-c-pro（已吸收代码质量审查），非 C 项目联动 ddev-code-review + 对应语言编码规范 skillddev-comment-gen）ddev-exec 的末尾作为最终收口门禁没有 spec 文档、没有 detail 文档、没有代码对照，就不要假装做了最终验收。
验收的重点是实现是否符合 spec、detail 和 exec plan，不是只看”代码能不能跑”。
如果进入了 ddev-clean 清理阶段，最终放行对象是清理后的最终代码，不是清理前那一版代码。
对于 C 代码项目，ddev-c-pro（统一完成规范与代码质量审查）和 ddev-comment-gen 注释审查是必经环节，两者均通过才能给最终 pass。对于其他语言项目，ddev-code-review 代码质量审查 + 语言规范审查 + 注释审查按存在情况逐一通过后放行；如无对应 skill，应标注"已跳过"而非静默略过。