| name | coding-standards-creator |
| description | 在需要为某种编程语言新建或修订 coding-standards 技能时使用：把团队内部编码规范文档转化为符合 DevFlow 形态的 <language>-coding-standards 技能，或把新的团队规则并入既有语言技能。不用于编写业务代码或直接做代码评审。 |
Coding Standards Creator
总览
本技能把给人读的团队编码规范文档转化为给模型用的 <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 技能读取，不在本技能里固定依赖具体语言名称。
工作流
1. 收集输入
- 团队规范文档（必需）：任意格式；记录版本/修订号作为 Source 锚点
- 目标语言：决定技能名
<language>-coding-standards（小写、连字符；语言标识用项目内约定的短名）
- 工具链事实：编译器/解释器版本、linter、格式化工具、静态分析、测试框架——技能的「工具链」节需要真实命令与基线
- 代码样例（可选但强烈建议）：团队真实代码风格，让正反例贴近实际而不是教科书
2. 逐条做归属判定
这是防止技能膨胀和重复的关键步骤。把团队文档的每条规则分到四类，只有第一类进入新技能：
| 归属 | 判定 | 处理 |
|---|
| 语言级规则 | 离开这门语言就不成立（所有权写法、异常/GC 语义、语言陷阱、惯用法、语言专属工具链） | 收录进新技能 |
| 通用整洁代码规则 | 任何语言都成立（函数单一职责、注释解释 why、死代码清理） | 不收录——已在 devflow-clean-code；技能里写一行引用即可。例外：通用规则的语言特化形态（如 Python 的 PEP 8 命名具体约定）算语言级 |
| 领域规则 | 绑定工程领域而非语言（中断上下文限制、内存预算、ASIL、端到端交互、服务契约等） | 不收录——归属命中 description 的领域技能；发现适用领域技能缺这条时单独提出，若尚无对应领域技能则建议新建 |
| 流程规则 | 评审流程、提交规范、分支策略、文档要求 | 不收录——不属于 coding-standards；提示用户其归属（AGENTS.md / 团队流程文档） |
归属判定输出一张映射表（团队规则编号 → 归属 → 去向），交人确认后再写技能。拿不准的条目标注存疑，不要静默丢弃。
冲突处理：团队规则与 DevFlow 既有判断冲突时（例如团队允许某种宏写法而 devflow-clean-code 反对），团队规则优先，但必须在技能中显式写出："本规则为团队约定，覆盖 DevFlow 默认 X"——隐藏冲突会让模型在两份指令间随机摇摆。
3. 提炼改写每条规则
每条收录的规则改写为三要素（详见 contract）：
- 可判定的规则：评审者拿着它能对一段代码说"违规/不违规"。"命名要清晰"不可判定；"布尔变量用 is/has/can 开头、肯定语义"可判定。
- 针对的事故类：这条规则防止什么真实失败（NPE、资源泄漏、注入、精度丢失）。团队文档里没写动机的规则，向规范负责人确认或从语言知识补全并标注。
- 正反例代码：用目标语言写最小对比。团队代码样例里有真实反例的优先用（脱敏后）。
改写纪律：
- "禁止 X" 必须补 "用 Y 替代"，否则模型遇到场景仍会写出 X 的变体
- 量化模糊词：团队文档写"函数不要太长" → 找负责人要阈值，或沿用
devflow-clean-code 默认并标注
- 不发明团队规则：文档没覆盖的语言危险区（如 Java 的 equals/hashCode 配对、Python 的可变默认参数），可以建议补充，但必须标注"DevFlow 默认建议，待团队确认"，与团队条目区分
4. 组织与生成
按 references/coding-standards-skill-template.md 骨架组织：
- 主题节按"事故密度"排序（该语言最常出错的主题在前）
- SKILL.md 控制在 ~300 行内；低频细则、完整规则号对照表（如团队的 MISRA/CERT/内部编号映射）放
references/
- frontmatter description 按 contract 的模式写触发条件（含文件类型、相邻语言的负触发）
- 生成
evals/evals.json：至少 3 个压力场景，覆盖本语言最高危的事故类
5. 接入 DevFlow
- 自动发现：
using-devflow 按 <language>-coding-standards 命名约定发现语言技能，无需修改入口
- 注册清单：更新仓库 README 两份语言版的叠加技能表；（建议）把新技能名追加进
scripts/validate_devflow.py 的 EXPECTED_SKILLS，防止误删
- 运行校验：
python3 scripts/validate_devflow.py 与 python3 -m pytest tests/ 必须通过
6. 交人验收
提交三件东西给团队规范负责人：归属映射表（含冲突清单与存疑项）、新技能全文、"DevFlow 默认建议"补充清单。负责人确认前技能不算生效。按 contract 末尾的验收清单自检。
合理化反驳
| 话术 | 现实 |
|---|
| 「文档照搬进来，内容齐全」 | 文档是给人的。没有触发条件、正反例和可判定性，模型读了也执行不了 |
| 「规则越全越好」 | 上下文预算有限。300 行高频高危规则的执行率远高于 1000 行平铺；长尾进 references/ |
| 「这条 clean-code 有了，再写一遍加强语气」 | 重复制造两处维护与漂移；写一行引用 |
| 「团队没写这条，我帮它补上」 | creator 不发明团队规则。补充必须标注来源待确认 |
| 「团队这条规则不合理，我改成最佳实践」 | 团队规则优先。给负责人提修改建议可以，静默改写不行 |
| 「示例用伪代码就行」 | 正反例必须是目标语言的真实代码——模型会模仿示例的每个细节 |
风险信号
- 产出的技能里出现"良好""合理""适当"等不可判定词
- 某节只有规则清单没有一段代码
- 与
devflow-clean-code 重复的章节（命名总则、函数长度总则）
- 归属映射表缺失，无法回答"团队文档第 N 条去哪了"
- 团队规则与 DevFlow 默认的冲突被静默吞掉
- description 总结了技能内容而不是触发条件
自检清单
支撑参考
| 文件 | 用途 |
|---|
references/coding-standards-skill-contract.md | <language>-coding-standards 的结构契约：命名、边界、规则写法、消费点、验收清单 |
references/coding-standards-skill-template.md | 新技能的可拷贝骨架 |
既有 <language>-coding-standards 技能 | 可选参考实现；按目标语言相近性选择，不在 creator 中固定依赖具体名称 |
