152 in the header, 100 plus in the description, and an xlsx file as the contract between skills

152 in the header and 100 plus in the description

The count appears in three forms and only two of them agree.

The repository description says the suite has more than 100 installable skills. The README header says 152 installable skills covering safety, cybersecurity, quality, communication, diagnostics, AUTOSAR, calibration, model based engineering, modelling and verification. And the body of the README explains the number differently: 76 builder skills plus 76 matching confirmation reviewer skills.

So 152 is not a count of distinct capabilities. It is the product of a rule and a half-count. The rule is stated in the same sentence as the pairings: every artifact-producing skill is paired with a confirmation reviewer, which means the number of reviewers is set by the number of builders rather than chosen.

The description's more modest figure is the one a visitor sees before opening anything. It is not wrong, since more than 100 is a subset of 152, but the two numbers invite the reader to assume the suite grew from 100 to 152 rather than that one figure counts both halves of a pair.

The contract between two skills is a spreadsheet

One sentence explains how the pieces fit together, and it is the design decision of the whole project:

> Each skill is an installable `.skill` file. The chain is the moat. Every downstream skill consumes the upstream skill's xlsx output as a stable file-format contract.

The chain is the term used throughout for the sequence of documents, and the file format is the integration surface. A hazard analysis produces a workbook, a fault tree analysis consumes it, a hardware safety requirements skill consumes that, and so on to the safety case at the end.

That has two consequences. The first is favourable: the skills are decoupled by a file rather than by a library, so one can be replaced without rewriting the chain. The second is that the only thing enforcing the contract is the convention of whoever wrote the columns. Nothing in the format records which skill produced the file, when, or from which inputs, so a downstream skill has no way to notice that the workbook in front of it was edited by hand or generated by a different toolchain.

The suite also leans on spreadsheets as the human deliverable, which is a deliberate choice for a domain where review trails and sign-off forms are the point.

Installation is a button and a phrase, and one path does not exist

The quickstart has three steps. Download the skill you need from the skills directory, or the full bundle from Releases. Click Save skill in Cowork or Claude Desktop. Then trigger it by phrasing, because every skill declares its triggering description in its frontmatter.

The example shows what that means in practice:

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

Two things are worth pulling apart. The install is a download and a button rather than a package manager entry, so there is no version resolution, no lockfile and no way to see what is installed. And the trigger is natural language matched against a description the skill declares about itself, which means two skills with overlapping descriptions can both claim a prompt.

The first step also points at Releases for the full bundle. There are no tagged releases on this repository, so that path has nothing to resolve to. What the root does carry is a releases file, a changelog and a status file, which is the manual equivalent of what the step promises.

The chain diagram stops in the middle of the fourth row

The diagram is the project's clearest statement of what it is, drawn as text with two lanes converging on one capstone.

The safety chain runs from item definition to a safety plan to a diagnostic analysis, then to hazard analysis, a fault tree and a technical safety concept. From there it splits into a hardware lane and a software lane, each of which fans out into requirements, architecture, an interface and an analysis, and both converge on a safety case described as the capstone. Three further chains are listed alongside it: threat analysis through to an incident response plan for cybersecurity, a SOTIF chain from analysis to validation strategy, and a quality chain from planning through design and process analyses to a control plan and a submission package.

Underneath the diagram there is a line that states the invariant: every box above has a builder skill and a matching reviewer skill.

The last line of the diagram does not finish. The fourth parallel chain, the one for the process improvement assessment, ends after its third arrow with the word for improvement cut off partway through. So the diagram that defines the contract also shows the boundary where the file ends, and the last step of that chain is not visible anywhere in the table.

A reviewer that emits a dashboard as well as a verdict

What the reviewer half of each pair produces is described in one line near the top of the file: reviewer outputs include a visual dashboard with KPI tiles, charts and findings tables.

That is a heavier output than a pass or fail. A findings table is a list of problems, which is what a reviewer should produce. KPI tiles and charts are a presentation layer, which means each reviewer skill is doing two jobs, and the repository's own framing calls them confirmation reviewers rather than reporting tools.

The example directories show how the pair is named, and the naming is not uniform across families. Some reviewers carry the word checklist in their name and some do not, so a reader looking for the review of one artifact has to know the convention for that family rather than a single rule.

What is missing from the description is the part that matters for trust: how a finding becomes a tile. Whether the tiles are counts, whether a red tile means a failed check or an unresolved comment, and whether a reviewer can pass an artifact with findings open, are all questions the file does not answer.

Standards are cited down to the clause

The tables are where the project's seriousness shows. Each skill is listed with the standard it serves, often down to a clause number.

The three foundation skills cite the product and system level safety lifecycle clauses of ISO 26262, one each for item definition, the safety plan and the diagnostic analysis. The concept phase adds a hazard analysis described with 14 malfunction guide words and a Cartesian enumeration across function, malfunction and environment, a fault tree per safety goal with a visual rendering and an ASIL decomposition, and a technical safety concept producing hardware and software technical safety requirements with safety mechanisms and a system analysis diagram.

The hardware lane of Part 5 includes a metrics builder described as formula driven with automatic verification against per-ASIL targets, and an interface builder that generates a C header. The software lane of Part 6 adds scheduling, memory partitioning and MISRA targets, and verification methods per ASIL.

Elsewhere the citations are equally specific: process improvement scoring against version 3.1 of the assessment model, a design analysis per the 2019 manual where action priority replaces the risk priority number, an 18 element submission package with a parts submission warrant, notification deadlines under a regulation and two agencies named, and a secure coding subset combining three sources.

That density is the repository's real contribution, and it is also its obligation: every claim is checkable against the standard text, and the suite itself is not the authority.

The visible tables account for 33 pairs of the 76

The skill tables carry pair counts in their headings, and adding them up does not reach the headline.

Three foundation pairs, three in the concept phase, four in the hardware lane, four in the software lane, one capstone for the safety case, six for cybersecurity, three for SOTIF, five for quality and four for process improvement. That is 33 pairs, or 66 skills, against a stated 76 pairs.

The missing 43 pairs are in sections the file continues into, so this is a boundary rather than an error. It does mean the two numbers cannot be reconciled from the file alone, and a reader who counts the tables and then reads the header has no way to tell whether they miscounted or whether the file is simply longer.

The root of the repository is small and shaped for maintenance rather than for packaging: a changelog, a releases file, a status file, a licence, and three directories for documentation, examples and scripts, alongside the skills directory itself. The examples directory holds one directory per skill, with both halves of each pair present as their own directories.

Editorial conclusion

This suite fits an automotive engineer who already knows the standard and wants the document skeleton produced quickly, and the per-clause citation density is the strongest thing in it. Four things to check before you rely on it. The headline count is derived from a rule, every builder paired with a reviewer, rather than from distinct capabilities, and it is stated differently in the header and in the repository description. The contract between one skill and the next is a workbook file, which means nothing in the format prevents a hand-edited file from passing downstream. The reviewer skills emit a dashboard with charts and tables, which is presentation work as well as checking, and nothing describes how a finding becomes a tile. And the quickstart sends you to a release bundle the repository does not publish, while a releases file sits in the tree instead. Treat every generated document as a draft to check against the standard text, and not as a deliverable. The branch was pushed on 2026-10-01 and there are no tagged releases.

Frequently asked questions

Official sources

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