automotive-skills-suite：成对的 Builder + Reviewer，把 ISO 26262/21434 交付件拆成 skill 链

大多数汽车项目里的安全与质量交付物都是 xlsx 工作簿，靠人手在交接环节反复编辑。jherrodthomas/automotive-skills-suite 把每一阶段拆成一个 builder 加一个配对的 reviewer，再把它们串成链——上游改动会自动顺流而下，不必重新录入。

为什么这个 Skill 重要

README 把这套套件描述为"76 个 builder skill + 76 个一一对应的确认 reviewer skill"，合计 152 个可安装的 Claude skill（注意：skills.json 里这个仓库的 description 字段写的是"100+"，那是一份更早的描述快照——README 自己展示的是当前的 152）。每个产出交付件的 skill 都配有一个确认 reviewer，输出带 KPI 瓦片图、图表与发现清单的可视化仪表盘。

仓库在 GitHub 上有 2.4k star，MIT 许可。README 明确写着"Built with Claude"——这套套件面向 Claude Desktop / Cowork，配 "Save skill" 安装路径，并不是按可移植 Agent Skills manifest 来发布的。

覆盖的标准很广：ISO 26262:2018（功能安全）、ISO/SAE 21434:2021（网络安全，UN R155 强制要求）、ISO 21448:2022（面向 ADAS/AV 的 SOTIF）、IATF 16949:2016 / AIAG-VDA（APQP、FMEA、控制计划、PPAP、MSA、SPC）、Automotive SPICE PAM 3.1 / 4.0、AUTOSAR Classic 与 Adaptive R22-11、ISO 14229-1（UDS）、SAE J2012（DTC）、ISO 22901-1（ODX），以及通信协议栈（CAN、LIN、FlexRay、汽车以太网）。README 里的完整链图说明 HARA → FSC → TSC → HW/SW 需求 → FMEDA → Safety Case 如何衔接。

"链"才是真正的护城河：每个下游 skill 把上游 skill 输出的 xlsx 当作稳定的文件格式契约来消费。HARA 一旦修改，下游的 FSC、TSC、FMEDA 与 Safety Case 都自动跟着走。

安装

仓库把每个 skill 作为独立的 .skill 文件放在 skills/ 下，frontmatter 里有触发描述，agent 按用户措辞自动选用。README 的快速开始是：

示例：先安装 HARA builder，再让 Claude 执行——"Build a HARA for a new ECU project — Electronic Stability Control"

实际落地步骤：

1. 从 skills/ 下载需要的 .skill 文件（也可以从 Releases 一次性下载整个 bundle）。
2. 在 Cowork 或 Claude Desktop 里点 "Save skill" 完成安装。
3. 通过措辞触发——每个 skill 在 frontmatter 里声明了触发描述，agent 会自动选用。

因为这是 Claude 专用 bundle，找不到 npx skills add … 之类的安装命令，也没有可移植的 SKILL.md manifest。skill 以 .skill 文件形式发布，针对 Claude Desktop / Cowork 优化。

实战：先建一份 HARA，再做确认评审

新 ECU 项目要做一个电子稳定控制功能。链的起点是 HARA。

Step 1. 从 skills/ 安装 hara-builder 与配套的 reviewer。每个 skill 都是面向 Claude 的 .skill 文件；仓库的 reviewer 统一遵循 X-checklist-reviewer 命名模式（例如 hara-checklist-reviewer）。

Step 2. 用下面的话触发 builder：

Build a HARA for a new ECU project — Electronic Stability Control.

Step 3. builder 产出一份 xlsx 工作簿，包含：item 定义、危险列表（14 个失效指引词，加上 function × malfunction × environment 的笛卡尔组合）、严重度 / 暴露率 / 可控度（S/E/C）评分、ASIL 判定，以及为下游汇总的安全目标。

Step 4. 在同一项目上下文里跑配对的 reviewer，得到一份确认仪表盘：包含可视化 KPI 瓦片图、与 ASIL 阈值对照的合规条、按 section 的堆叠分解，以及带"建议行动"的发现清单。

Step 5. 把这份 xlsx 交给下一对（fsc-builder + reviewer，再 tsc-builder + reviewer，然后是 HW/SW 通道），它们按稳定契约读取它。上游 HARA 一改，下游自动跟上——不用重新录入。

实战：诊断 ASIL 为什么"漂了"

安全审计员追问：HARA 里某 HW 元素是 ASIL B，为什么 FMEDA 显示 ASIL C？需要追到分解逻辑。

Step 1. fmeda-builder 产出 SPFM / LFM / PMHF 并自动按 ASIL 阈值核验。打开那份 xlsx，找到那个元素的行。

Step 2. 运行配对的 reviewer skill（fmeda-checklist-reviewer）——它的仪表盘会列出每个不达 ASIL 阈值的元素，以及残余风险分级。

Step 3. 沿链往上追：tsc-builder 消费 FSC；FSC 消费 HARA 的安全目标；HARA 的 ASIL 来自 function × malfunction × environment 的笛卡尔评分。README 里的链图（HARA → FSC → TSC → HW-SR / SW-SR → FMEDA → Safety Case）能把你正在读的这份 xlsx 一路追溯到设定 ASIL 的源头输入。

Step 4. 如果 ASIL 分解本身没问题，那 FMEDA 的阈值告警其实是系统在告诉你手工录入的 SPFM 数字有偏差——带着修正过的诊断覆盖率重跑 builder。

Step 5. 如果是 ASIL 分解错了，根因在 HARA——重新给 malfunction 打分，重新生成 xlsx，让下游链自动重派生。

技巧

• 把 README 的链图先读一遍，后面看参考文档时它会告诉你下一对是谁。
• builder 跑完立刻跑配对的 reviewer——链的设计前提是 builder 的 xlsx 先被确认，下游才会消费。
• 大量 reviewer 会自动核验量化阈值（FMEDA 的 SPFM/LFM/PMHF vs ASIL；PPAP 的 Cpk vs 1.33/1.67；MSA 的 Gauge R&R % vs AIAG；SPC 的 Cpk vs 目标值）。让仪表盘先指出缺口，"建议行动"一列就是待办。
• reviewer 永远不会修改源交付件——缺口会落进"建议行动"。不要为了消除告警而手工改 builder 的 xlsx，带着修正后的输入重跑 builder。

何时不用这个 Skill

如果你的团队不用 Claude Desktop 或 Cowork，这套套件形态对不上——它没有按可移植 Agent Skills manifest 发布，也没有 npx 安装路径。想要跨 agent 可移植的、范围更小的汽车相关 skill，去别处找；这套是 Claude-only，只能在 Claude 工具链里跑。如果你想要的不是 152 个 skill 的链，而是单点安全分析 skill，这个套件过重。

查看 排行榜 了解更多 skill。