docevilOck
docevilOck/agent-skills-hook
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/docevilOck/agent-skills-hook --skill ddev-gate命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | ddev-gate |
| description | 在代码实现完成后、准备结束任务或进入发布前使用，用来核对代码实现是否与 spec 文档以及 detail 文档一致，并通过代码质量审查、清理、编码规范和注释审查后给出最终验收结论 |
这个 skill 用于代码实现阶段的最终验收。
它不是普通代码审查，也不是只跑测试的验证门禁。它的核心任务根据项目语言分支：
按改动面大小分流（判定标准见「改动面路由」）：
ddev-clean，输出一份结论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，不要自己扩散成全仓库审查。
进入核心流程前，先判定本次改动面大小，决定走 streaming（流式）还是 compact（整合）路线。
默认 compact：除命中「大改动」外，一律走 compact 整合审查。
判定「大改动」— 命中任一即走 streaming：
codegraph_impact 影响半径超出本模块（存在受影响的跨模块调用方/文件）以下不单独构成「大改动」，仍走 compact：
判定依据取 spec/detail 声明的范围与 git diff / codegraph_impact 实际影响面中的较严者。
ponytail: diff 行数阈值是启发式，可按团队习惯调整；与第 3 条结构性重构判定冲突时，以重构性质为准。
task_plan.md 和 implementation-notes.md，确认以下条件同时满足才能继续验收流程，否则返回 blocked：
[x]（completed）implementation-notes.md 中存在且 Open Questions 已全部回答完毕（无未决项）scripts/check-complete，运行确认输出 "ALL PHASES COMPLETE"
0.5. 改动面路由：按「改动面路由」判定本次改动面。
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 加载 skill，对统一完成编码规范审查和代码质量审查（安全、架构性能、死代码/重复）。C 项目不再单独调用 。如果没有新的、可归属到本轮结论的验证证据，最多输出 need-info，不能输出 pass。
如果清理 subagent 产出的改动超出既定范围、引入新的抽象层、或让实现偏离 spec/detail/exec plan，也必须回到 blocked，不能因为”一致性阶段之前通过过”而继续放行。
改动面路由判定为小改动时走本路线。核心原则：一次整合审查取代四段流，跳过 ddev-clean，保留独立视角。
C0. 前置检查：同 Streaming 步骤 0（task_plan 全部完成、错误已解决、implementation-notes.md 存在且 Open Questions 已答完、check-complete 通过）。不满足 → blocked。
C1. 主 agent 定位 spec、detail、exec plan（如有）、implementation-notes.md、代码范围和本轮验证证据，读取并整理成审查上下文。
C2. 主 agent 读取 implementation-notes.md，提取 Deviations（映射为一致性重点检查项）、Design Decisions（作为 spec 空白处补充依据）、Open Questions（未答 → blocked）。
C3. 拉 1 个独立 subagent 做整合审查，提示模板见 compact-reviewer-prompt.md。该 agent 一次性完成：
- 一致性对照：按 spec → detail → exec plan → notes → code → evidence 顺序逐项对照，显式核对 Deviations，检查 exec plan 是否只做执行映射；必须用 codegraph_impact 核对影响面是否超出 spec/detail 声明范围
- 编码规范与质量：C 项目按 ddev-c-pro 维度（规范 + 安全 + 架构性能 + 死代码/重复），非 C 项目按语言对应 skill；问题按 CRITICAL/HIGH/MEDIUM/LOW 分级
- 注释完整性：C 项目按 ddev-comment-gen 维度逐文件核对；其他语言按对应注释审查 skill，无则跳过
- 输出一份结论 pass / need-info / blocked，附差异归类、问题清单、缺失注释清单
C4. 跳过 ddev-clean。整合审查发现的低危可清理项（MEDIUM/LOW）直接列入问题清单不阻塞；主 agent 决定是否顺手清理，若清理改了代码，补验证证据后回到 C3 重审。
C5. blocked → 主 agent 按清单修改，重新进入本 skill，从 C1 重跑 Compact 路线（不升级为 Streaming）。
C6. need-info → 补齐缺失输入 / 范围 / 验证证据后从 C3 重跑。
C7. pass → 满足「结论规则」中 compact 条件后，主 agent 才能宣称"已经按计划完成"。
Compact 路线同样要求 spec、detail、代码范围、验证证据齐全，缺任何一项都不能给 pass。
codegraph_impact 评估改动影响面：对关键符号做影响半径分析，确认实际影响范围与 spec/detail 声明的范围一致；若存在文档未声明的受影响模块，视为偏离blockedddev-clean 清理，必须按清理后的最终代码重做对照，不能沿用清理前结论审查提示模板见 streaming-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。
（compact 路线专用；Streaming 路线使用上方各阶段独立 agent）
codegraph_impact 评估影响面，影响面超出 spec/detail 声明范围视为偏离ddev-c-pro 维度（规范、安全、架构性能、死代码/重复），非 C 项目按语言对应 skill；问题按 CRITICAL/HIGH/MEDIUM/LOW 分级，存在 CRITICAL/HIGH → blockedddev-comment-gen 维度逐文件核对，缺失 → blocked 并附缺失清单；其他语言无对应 skill 则跳过pass / need-info / blockedcompact 整合审查提示模板见 compact-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-infoblockedcompact 路线同样只允许这三种结论，且三合一整合审查一次性覆盖一致性、编码规范与质量、注释三个维度，无需分段输出。
pass只有在以下条件同时满足时才能给：
implementation-notes.md 中 Open Questions 已全部回答完毕ddev-clean 清理，则清理后的最终代码也已重新完成一致性验收ddev-c-pro 统一完成，非 C 项目由 ddev-code-review + 语言规范审查完成）.c / .h），则 ddev-comment-gen 注释审查已通过；若为其他语言，则对应的注释审查已通过或已合理跳过ddev-clean、ddev-c-pro / ddev-code-review、注释审查的条目，由三合一整合审查一次性覆盖；ddev-clean 明确跳过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 则注明"已跳过"compact 路线：上述第 7–9 项合并为一份「整合审查结论」，一次性输出一致性、规范与质量、注释三个维度的结果。
如果没有发现不一致，也不能只说“通过”，仍要说明对照了什么。
如果需求结论依赖真实目标板、外设、时序、功耗、波形或现场观察，而本轮没有对应人工或现场证据，不能给 pass。
如果审查结论是 blocked，输出里必须明确列出“需要主 agent 修改的项”，这样主 agent 才能按项修复并重新送审。
ddev-specddev-detailverification-before-completionddev-code-review（非 C 项目）ddev-cleanddev-c-pro（已吸收代码质量审查），非 C 项目联动 ddev-code-review + 对应语言编码规范 skillddev-comment-gen）ddev-clean，三合一整合审查一次性覆盖一致性 + 规范质量 + 注释；大改动才走上述完整链路ddev-exec 的末尾作为最终收口门禁本 skill 完成后，禁止 agent 自动进入任何后续阶段（ddev-archive / git commit / 发布 / 部署 等）。
pass 后，向用户报告完整的验收结论（一致性、代码质量、注释审查）。没有 spec 文档、没有 detail 文档、没有代码对照，就不要假装做了最终验收。
验收的重点是实现是否符合 spec、detail 和 exec plan，不是只看”代码能不能跑”。
如果进入了 ddev-clean 清理阶段，最终放行对象是清理后的最终代码，不是清理前那一版代码。
对于 C 代码项目，ddev-c-pro（统一完成规范与代码质量审查）和 ddev-comment-gen 注释审查是必经环节，两者均通过才能给最终 pass。对于其他语言项目，ddev-code-review 代码质量审查 + 语言规范审查 + 注释审查按存在情况逐一通过后放行；如无对应 skill，应标注"已跳过"而非静默略过。
compact 路线：同样必须有 spec、detail、代码范围、验证证据；三合一整合审查通过（C 项目覆盖 c-pro 与 comment-gen 维度）才能给最终 pass，不因改动小而降低底线。
ddev-c-proddev-code-reviewddev-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 才能宣称”已经按计划完成”。