菜单
在需要为某种编程语言新建或修订 coding-standards 技能时使用：把团队内部编码规范文档转化为符合 DevFlow 形态的 <language>-coding-standards 技能，或把新的团队规则并入既有语言技能。不用于编写业务代码或直接做代码评审。
用 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 技能。
在编写、修改或评审 C++ 代码（.cpp/.cc/.hpp、类、模板、RAII、智能指针、C++ 测试、C++ ABI 边界）时使用。提供资源管理、所有权签名、类设计、错误策略、模板纪律与 ABI 的具体规则与正反例。只适用于 C++；C 或其他语言代码使用对应语言自己的 coding-standards 技能。
| name | coding-standards-creator |
| description | 在需要为某种编程语言新建或修订 coding-standards 技能时使用：把团队内部编码规范文档转化为符合 DevFlow 形态的 <language>-coding-standards 技能，或把新的团队规则并入既有语言技能。不用于编写业务代码或直接做代码评审。 |
本技能把给人读的团队编码规范文档转化为给模型用的 <language>-coding-standards 技能。两者形态完全不同，照搬必然失败：
| 团队规范文档 | DevFlow coding-standards 技能 |
|---|---|
| 面向人，靠理解与自觉执行 | 面向模型，靠触发条件加载、靠可判定规则约束 |
| 规则可以抽象（"命名要有意义"） | 每条规则必须可判定违规，且带正反例 |
| 大而全，几百条平铺 | 上下文预算有限：高频高危进 SKILL.md，长尾进 references/ |
| 常只写"禁止 X" | 必须补"用什么替代"，否则模型会发明自己的替代品 |
产出必须符合 references/coding-standards-skill-contract.md（结构契约）；骨架直接从 references/coding-standards-skill-template.md 起步。需要参考既有实现时，选择一个已存在且与目标语言形态最接近的 <language>-coding-standards 技能读取，不在本技能里固定依赖具体语言名称。
<language>-coding-standards（小写、连字符；语言标识用项目内约定的短名）这是防止技能膨胀和重复的关键步骤。把团队文档的每条规则分到四类，只有第一类进入新技能：
| 归属 | 判定 | 处理 |
|---|---|---|
| 语言级规则 | 离开这门语言就不成立（所有权写法、异常/GC 语义、语言陷阱、惯用法、语言专属工具链） | 收录进新技能 |
| 通用整洁代码规则 | 任何语言都成立（函数单一职责、注释解释 why、死代码清理） | 不收录——已在 devflow-clean-code；技能里写一行引用即可。例外：通用规则的语言特化形态（如 Python 的 PEP 8 命名具体约定）算语言级 |
| 领域规则 | 绑定工程领域而非语言（中断上下文限制、内存预算、ASIL、端到端交互、服务契约等） | 不收录——归属命中 description 的领域技能；发现适用领域技能缺这条时单独提出，若尚无对应领域技能则建议新建 |
| 流程规则 | 评审流程、提交规范、分支策略、文档要求 | 不收录——不属于 coding-standards；提示用户其归属（AGENTS.md / 团队流程文档） |
归属判定输出一张映射表（团队规则编号 → 归属 → 去向），交人确认后再写技能。拿不准的条目标注存疑，不要静默丢弃。
冲突处理：团队规则与 DevFlow 既有判断冲突时（例如团队允许某种宏写法而 devflow-clean-code 反对），团队规则优先，但必须在技能中显式写出："本规则为团队约定，覆盖 DevFlow 默认 X"——隐藏冲突会让模型在两份指令间随机摇摆。
每条收录的规则改写为三要素（详见 contract）：
改写纪律：
devflow-clean-code 默认并标注按 references/coding-standards-skill-template.md 骨架组织：
references/evals/evals.json：至少 3 个压力场景，覆盖本语言最高危的事故类using-devflow 按 <language>-coding-standards 命名约定发现语言技能，无需修改入口scripts/validate_devflow.py 的 EXPECTED_SKILLS，防止误删python3 scripts/validate_devflow.py 与 python3 -m pytest tests/ 必须通过提交三件东西给团队规范负责人：归属映射表（含冲突清单与存疑项）、新技能全文、"DevFlow 默认建议"补充清单。负责人确认前技能不算生效。按 contract 末尾的验收清单自检。
| 话术 | 现实 |
|---|---|
| 「文档照搬进来，内容齐全」 | 文档是给人的。没有触发条件、正反例和可判定性，模型读了也执行不了 |
| 「规则越全越好」 | 上下文预算有限。300 行高频高危规则的执行率远高于 1000 行平铺；长尾进 references/ |
| 「这条 clean-code 有了，再写一遍加强语气」 | 重复制造两处维护与漂移；写一行引用 |
| 「团队没写这条，我帮它补上」 | creator 不发明团队规则。补充必须标注来源待确认 |
| 「团队这条规则不合理，我改成最佳实践」 | 团队规则优先。给负责人提修改建议可以，静默改写不行 |
| 「示例用伪代码就行」 | 正反例必须是目标语言的真实代码——模型会模仿示例的每个细节 |
devflow-clean-code 重复的章节（命名总则、函数长度总则）| 文件 | 用途 |
|---|---|
references/coding-standards-skill-contract.md | <language>-coding-standards 的结构契约：命名、边界、规则写法、消费点、验收清单 |
references/coding-standards-skill-template.md | 新技能的可拷贝骨架 |
既有 <language>-coding-standards 技能 | 可选参考实现；按目标语言相近性选择，不在 creator 中固定依赖具体名称 |