Automotive Skills Suite: 76 Claude Builder Skills Paired With Confirmation Reviewers

What the Automotive Skills Suite actually solves

Automotive safety and quality work is dominated by structured documents that follow a fixed shape: a HARA with guide words, a DFMEA with Action Priority, a TARA with STRIDE coverage, a traceability matrix. The content changes per project; the skeleton does not. This repository targets that skeleton. It ships 76 builder skills and 76 matching confirmation reviewer skills, each an installable .skill file, each covering a named step in a standard such as ISO 26262, ISO/SAE 21434, ISO 21448 SOTIF, AIAG-VDA quality, Automotive SPICE, AUTOSAR, calibration, MBSE, SysML or V&V.

The audience is narrow and specific: engineers who already know what a functional safety concept is and want the spreadsheet drafted, not explained. The README lists the deliverables as xlsx files, which tells you the intended consumer is a person who will open the artifact, edit it, and put it into a project folder. Someone looking for a library to call from Python is in the wrong repository.

The builder and reviewer pairing is the design, and the xlsx file is the interface

The README calls the chain "the moat" and describes the mechanism plainly: every downstream skill consumes the upstream skill's xlsx output as a stable file-format contract. So the data flow is file-based, not API-based. A HARA builder writes a workbook; the FSC builder reads it; the TSC builder reads that; the HW and SW lanes branch off; the safety case pulls evidence from all upstream artifacts. Parallel chains run the same way for ISO/SAE 21434, SOTIF, APQP and ASPICE.

Every box in that chain has two skills, a builder and a reviewer. The reviewer produces what the README describes as a visual dashboard with KPI tiles, charts and findings tables. That is a real architectural decision with a real consequence: the reviewer is a second model pass over the same file, not an independent verification authority. It can catch omissions against a checklist, and the dashboard makes gaps visible. It cannot certify that a PMHF calculation is correct. The README does not claim otherwise, but the word "confirmation" invites that reading, and it should not.

The file contract also means the chain breaks quietly. If a builder emits a column the downstream reviewer does not expect, nothing in the described design stops the run; you get a dashboard built on a misread workbook. There is no schema file mentioned in the README or the top-level entries.

Installing a skill and running a first HARA

The Quickstart gives three steps. You download the skill you need from skills/ or the full bundle from Releases, click "Save skill" in Cowork or Claude Desktop to install, and trigger it by phrasing, because each skill declares its triggering description in its frontmatter. The README's own example is the HARA builder:

# Example: install the HARA builder, then ask Claude
"Build a HARA for a new ECU project — Electronic Stability Control"

Note what that block is: a comment and a prompt string, not a command. There is no CLI, no package to pip install, no port to open. Installation happens inside the Claude client. The repository has a scripts/ directory and a Python primary language, but the README does not document what the scripts do or how to invoke them, so treat them as unverified until you read them yourself.

A practical first run: install hara-builder and its matching reviewer from skills/, ask for a HARA on a small, well-understood item rather than a full vehicle program, then open the resulting workbook and check the guide-word rows against the 14 malfunction guide words the README says the builder uses. Then run the reviewer against that same file and compare its findings table with what you found by hand. That comparison is the only honest way to calibrate how much the reviewer is worth on your projects.

Where the suite is the wrong tool

The repository covers a lot of standards, and breadth is exactly where the risk sits. A skill that drafts a cybersecurity goal is not evidence that the goal is right for your architecture, and the README does not describe any mechanism that ties a generated artifact back to your actual item definition beyond the file the upstream skill produced. Garbage in, structured garbage out, with a dashboard.

Three concrete cases where this is the wrong choice. First, teams without an existing xlsx deliverable process: the entire value proposition is the file-format contract, and if your organization works in DOORS, Polarion or Jama, the xlsx is an export detour, not a fit. Second, teams that need audit-grade traceability: nothing in the README describes change history, signatures or tool qualification, and ISO 26262 tool confidence is not discussed. Third, anyone treating the reviewer output as a gate. A findings table is a prompt for a human to look, not a sign-off.

There is also a maintenance question the repository answers only partly. The last push was on 2026-09-17, so the tree is current, but there are no retrieved releases and no version tags in the repository metadata, which makes pinning a known-good skill set harder than it should be for regulated work.

How it differs from generic prompt libraries and from tools like IBM DOORS

The obvious alternative is a folder of your own prompts. The difference is the pairing and the contract. A personal prompt library gives you a HARA template; this gives you a HARA builder whose output another skill is written to consume, plus a reviewer skill written against the same artifact. That chaining is the part you would have to rebuild yourself, and rebuilding it means defining the xlsx schema and keeping both sides of every pair in sync.

The other alternative is a requirements management tool such as IBM DOORS, or Polarion on the application lifecycle side. Those are systems of record: they store the artifact, version it, enforce links and produce the traceability report. This suite is a drafting layer that produces files you then import. The approaches are complementary rather than competing, and the README does not describe any integration with either tool. If your problem is "we cannot trace requirements," a requirements tool is the answer. If your problem is "drafting this DFMEA takes two days," this suite is aimed at you.

Licence, maintenance and what an upgrade costs

The licence is MIT, stated in the README badge and the LICENSE file. MIT is permissive: you can use, modify and redistribute the skills, including commercially, provided the copyright notice and permission notice travel with copies. It says nothing about the standards themselves. The ISO and AIAG-VDA documents the skills reference are separately licensed and are not redistributed here, so the compliance obligation for the standards text sits with you, not with this repository. That is a factual boundary, not legal advice; check with your own counsel before shipping artifacts built from licensed standards.

Upgrade cost is the part the repository leaves open. There are no retrieved releases, so there is no changelog-driven upgrade path described, even though CHANGELOG.md and RELEASES.md sit at the top level. The practical implication: if you adopt these skills, copy the specific skill directories you use into your own repository and pin them there. Then an update to the upstream tree is a diff you review, not a silent change to a document generator that feeds your safety case.

Editorial conclusion

Adopt it if you already produce structured xlsx artifacts for ISO 26262, ISO/SAE 21434, SOTIF or AIAG-VDA work and want a Claude skill to draft them, and if you accept that the reviewer skill is a second model pass rather than an independent check. Do not adopt it expecting a compliance certificate, a CI pipeline, or a replacement for a qualified safety or cybersecurity engineer. Before installing anything, open one builder and its matching reviewer in skills/ and read the frontmatter triggering description, because that text is the only documented install surface and the README does not document rollback.

Frequently asked questions

Official sources

1. Issues
2. jherrodthomas/automotive-skills-suite on GitHub
3. License: MIT
4. README