メニュー
在车载软件工作项（ECU、域控、车载服务、整车平台）的规格、设计、实现或评审中使用，涉及功能安全/ASIL、车载 SOA 服务、DTC/诊断、整车启动/休眠/唤醒、SELinux 或跨 ECU 协同时。只承载车载专属约束；内存/实时性、通用服务接口或其他相邻领域规则由命中 description 的领域技能叠加，语言级规则见适用 `<language>-coding-standards`。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
在规格、设计、测试或代码需要独立评审时使用：阶段产物完成后的把关、人要求 review、或对既有产物做专项检查时。评审必须由作者之外的独立上下文执行，产出 findings 与 verdict。
在实现任何功能或修复任何缺陷、即将编写实现代码时使用；设计确认后的整个实现期都适用。强制测试先行的 RED→GREEN→REFACTOR 循环。不用于规格编写、设计决策或纯文档修改。
在后端/服务端工作项（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 技能，或把新的团队规则并入既有语言技能。不用于编写业务代码或直接做代码评审。
在编写、修改或评审 C++ 代码（.cpp/.cc/.hpp、类、模板、RAII、智能指针、C++ 测试、C++ ABI 边界）时使用。提供资源管理、所有权签名、类设计、错误策略、模板纪律与 ABI 的具体规则与正反例。只适用于 C++；C 或其他语言代码使用对应语言自己的 coding-standards 技能。
| name | automotive-development |
| description | 在车载软件工作项（ECU、域控、车载服务、整车平台）的规格、设计、实现或评审中使用，涉及功能安全/ASIL、车载 SOA 服务、DTC/诊断、整车启动/休眠/唤醒、SELinux 或跨 ECU 协同时。只承载车载专属约束；内存/实时性、通用服务接口或其他相邻领域规则由命中 description 的领域技能叠加，语言级规则见适用 `<language>-coding-standards`。 |
车载约束的共同点：很多决策不属于本组件，而属于整车级角色（功能安全负责人、模块架构师、系统工程师）。所以本技能的核心纪律有两条：一是把车载维度前置到规格和设计；二是识别哪些决策必须上抛——agent 不替功能安全和整车架构拍板。本技能只承载车载专属维度；通用内存、中断、实时性、服务接口等约束由命中 description 的相应领域技能叠加。
动笔前先对工作项涉及的每个车载维度做归属判定——这一步决定哪些能自己实现、哪些必须上抛：
变更涉及车载维度
│
├─ 安全相关行为？（喂狗时机/安全状态/监控阈值）──► 上抛功能安全负责人，ASIL/safety goal 确认前 blocking
├─ 跨组件/跨 ECU 可观察契约？（service/DTC/信号）──► 走 devflow-specify modify + 列消费者 + owner 协调
├─ 整车规范派生约束？（电源/网络管理/休眠唤醒）──► 引用规范章节为 Source，不凭记忆
└─ 组件内部实现细节 ──► 可自行实现，仍遵守下列各维度红线
拿不准归属时按"上抛"处理，记为 Open Question，而不是默默实现。
modify + 上抛确认。/* ❌ 顺手"优化"安全相关时序：改了喂狗节奏却当普通重构提交 */
- feed_watchdog_every(50 /*ms*/);
+ feed_watchdog_every(200 /*ms*/); /* 看似省 CPU，实则放大故障检测窗口 */
/* ✅ 安全相关参数变更 = modify + 上抛功能安全负责人，附安全分析依据后才改 */
组件必须显式回答四个状态的行为，缺一即设计缺口：
| 状态 | 必答问题 |
|---|---|
| 启动 | 依赖服务还没起来时怎么办（等待/降级/重试）；启动顺序依赖是否有环 |
| 正常退出 | 收到退出信号后多久内完成清理；未完成的写入怎么处理 |
| 休眠 | 哪些状态要持久化；唤醒后怎么恢复 |
| 异常恢复 | 进程被重启后与外界状态的一致性 |
devflow-specify 的 IFR + 基线纪律；车载语境下消费者常跨 ECU，兼容窗口受整车版本管理约束（不假设对端同步升级）devflow-review）：本文件各节红线即检查项；安全相关行为变更无上抛记录 → critical。| 话术 | 现实 |
|---|---|
| 「功能很小，ASIL 应该不涉及」 | safety 适用性由功能安全负责人确认，不由功能大小推断 |
| 「改个错误码，下游应该没人依赖」 | 车载接口的可观察语义都有消费者；列出消费者和兼容策略 |
| 「休眠唤醒场景后面再补」 | 生命周期行为是设计输入；后补通常意味着重新设计持久化 |
| 「SELinux 先放宽，量产前收紧」 | "临时"宽策略会跟着发布走；最小权限从第一天开始 |
| 「诊断日志够了，不用报 DTC」 | DTC 策略是领域决策；缺失时上抛，不自行降级 |