菜单
在处理缺陷、回归、线上问题或紧急修复（DTS/hotfix）时使用：需要复现问题、定位根因、界定最小修复范围时。不用于新功能开发或主动重构。
用 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-fix |
| description | 在处理缺陷、回归、线上问题或紧急修复（DTS/hotfix）时使用：需要复现问题、定位根因、界定最小修复范围时。不用于新功能开发或主动重构。 |
修缺陷最大的失败模式不是修不好，而是修了症状：没复现就开改、把"不再报错"当"修好了"、顺手把周围看不顺眼的代码一起动了。纪律一句话：
先复现，再归因，后修复；没有失败的测试就没有修复。
产出按问题严重度伸缩：简单缺陷把三段记录（复现/根因/修复边界）写进组件根下 features/DTS<id>-<slug>/fix.md（或团队覆盖路径）即可；根因涉及设计缺陷或行为变更时，回到完整的 spec/design 流程。
明确写下：最小安全修复范围（哪些文件/函数）、显式不修什么（周边坏味道、同类风险点登记不动手）、回退策略。然后分流：
| 根因性质 | 路径 |
|---|---|
| 实现错误（逻辑/边界/资源），契约本身正确 | 直接进入步骤 4 |
| 行为/契约需要变更（错误码、接口语义、阈值） | 这是变更不是修复 → 走 devflow-specify（modify 条目 + 基线） |
| 设计缺陷（边界划错、并发模型错） | 回 devflow-design 修订后再实现 |
| 波及范围里发现同类隐患 | 登记为独立工作项，不在本次顺手修 |
devflow-tdd）。fix.md 补全四问：根因是什么、为什么测试没拦住、修复改了什么、同类风险登记在哪。代码与测试按 devflow-review 的 code/test rubric 评审；评审闭环后经 devflow-ship 做 DoD 核验与关闭（DoD 对缺陷工作项的裁剪规则见其 definition-of-done）。
| 文件 | 用途 |
|---|---|
references/fix-template.md | fix.md 模板（复现/根因/修复边界三段） |