菜单
在工作项全部任务完成、测试与代码评审闭环后收尾时使用：对照 Definition of Done 核验完成证据、把已确认的规格与设计沉淀为长期文档资产（promotion）、写 closeout 记录。不用于实现、评审或修复。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
在规格、设计、测试或代码需要独立评审时使用：阶段产物完成后的把关、人要求 review、或对既有产物做专项检查时。评审必须由作者之外的独立上下文执行，产出 findings 与 verdict。
在实现任何功能或修复任何缺陷、即将编写实现代码时使用；设计确认后的整个实现期都适用。强制测试先行的 RED→GREEN→REFACTOR 循环。不用于规格编写、设计决策或纯文档修改。
在车载软件工作项（ECU、域控、车载服务、整车平台）的规格、设计、实现或评审中使用，涉及功能安全/ASIL、车载 SOA 服务、DTC/诊断、整车启动/休眠/唤醒、SELinux 或跨 ECU 协同时。只承载车载专属约束；内存/实时性、通用服务接口或其他相邻领域规则由命中 description 的领域技能叠加，语言级规则见适用 `<language>-coding-standards`。
在后端/服务端工作项（HTTP/REST/GraphQL API、服务与仓库层、数据库访问、缓存、鉴权、限流、后台任务、可观测性、配置与机密、弹性容错、生产就绪）的规格、设计、实现或评审中使用，涉及接口契约、分层与依赖方向、配置与机密、错误模型、数据一致性、幂等、认证授权、依赖超时重试熔断、过载保护、优雅停机时。只承载服务端/API 领域约束；客户端/UI、行业专属服务或其他相邻领域规则由命中 description 的领域技能叠加，语言级规则见适用 `<language>-coding-standards`。
在编写、修改或评审 C 代码（.c 源文件、.h 头文件、C 单元测试、C ABI 边界）时使用。提供指针所有权、手动内存与资源释放、缓冲区容量、整数转换、宏、头文件、错误返回的具体规则与正反例。只适用于 C 语言；其他语言或 C++ 代码使用对应语言自己的 coding-standards 技能。
在需要为某种编程语言新建或修订 coding-standards 技能时使用：把团队内部编码规范文档转化为符合 DevFlow 形态的 <language>-coding-standards 技能，或把新的团队规则并入既有语言技能。不用于编写业务代码或直接做代码评审。
| name | devflow-ship |
| description | 在工作项全部任务完成、测试与代码评审闭环后收尾时使用：对照 Definition of Done 核验完成证据、把已确认的规格与设计沉淀为长期文档资产（promotion）、写 closeout 记录。不用于实现、评审或修复。 |
收尾回答两个问题：这个工作项真的可以关闭吗？关闭之后给仓库留下什么？
对应两个动作，缺一不可：
features/<id>/（或团队覆盖路径）里已确认的规格与设计按原模板结构沉淀为同一组件根下的长期文档。promotion 不是重新创作交付件；原 spec / design / component-design 模板中的正文、章节、表格和锚点默认保留，只做最小清理。过程工件是给本次开发用的；长期资产是给下一个工作项、下一个人、下一轮 AI 用的。不做 promotion，工件就停在 features/ 里腐烂，组件设计基线逐渐失真。收尾不修代码、不补测试：核验发现缺口 → 回对应阶段补，补完再回来。
对照 references/definition-of-done.md 逐项检查，每项写结论（满足 / 缺口 + 去向）。任一项不满足：
| 缺口 | 回到 |
|---|---|
| 需求条目无对应通过测试 / 验收标准未覆盖 | devflow-tdd |
| reviews/ 缺某个门禁的评审记录，或 findings 的 Resolution 列有空缺 | 补评审（devflow-review）或按 findings 返工并回写 resolution |
| plan.md 门禁状态表与 reviews/ 实际记录不一致 | 修正门禁表；状态造假按 critical 处理 |
| 实现与 design.md / 组件设计漂移 | devflow-design（改工件）或 devflow-tdd（改代码） |
| 证据缺失或过期（RED/GREEN 证据行、静态分析） | devflow-tdd 补真实证据，不补叙述 |
通读同一组件根/工件根下 features/<id>/traceability.md（或团队覆盖路径）：每条需求 → 设计章节 → 测试用例 → 代码/测试文件 → 证据的链路闭合；N/A 项有理由。断链 = spec-design-code 不一致的直接信号，按 critical 处理。
按 references/promotion-checklist.md 同步长期资产：
| 过程工件 | 长期资产 | 条件 |
|---|---|---|
spec.md | 组件根下 docs/ar-specs/<id>-<slug>.md（或团队覆盖路径） | AR/CHANGE 工作项必做；纯缺陷（无规格变更）N/A |
design.md | 组件根下 docs/ar-designs/<id>-<slug>.md（或团队覆盖路径） | 有正式设计的工作项必做 |
component-design-draft.md | 组件根下 docs/component-design.md（或团队覆盖路径） | 本工作项修订了组件设计时必做（模块架构师确认后） |
promotion 是保留模板的最小清理，不是重新改写：原 spec / design / component-design 模板中的已确认内容都应作为交付件保留，只去掉 Open Questions、过程笔记、评审应答这类不属于长期资产的过程内容；保留追溯锚点（ID、来源、测试设计用例、评审记录路径）。若长期文档已有变更记录表，追加本次修订（日期、触发工作项、摘要）；若原模板没有，不为统一格式强行重写全文。组件设计只更新受影响章节，不顺手重排其他章节。
写同一组件根/工件根下 features/<id>/closeout.md（或团队覆盖路径，一页内）：DoD 核验结果摘要、promotion 路径表（同步了什么 / N/A 及理由）、遗留债务清单（带去向：新工作项 / 登记的 issue）、复盘一句话（本次流程哪里最磨损，反哺 skill 或模板）。
把 closeout 呈给人。人确认后工作项关闭；组件根下 features/<id>/（或团队覆盖路径）原地保留（不移动、不删除），保证追溯链接长期有效。
docs/component-design.md| 文件 | 用途 |
|---|---|
references/definition-of-done.md | Definition of Done 核验清单 |
references/promotion-checklist.md | 长期资产同步对象与最小清理规则 |