How I Built a Claude Skill
for Endless Business Capabilities

The skill is called generate-capability. It lives in the repository at .claude/skills/generate-capability/SKILL.md. The user surface is one sentence: “Generate capabilities for Insurance.” A few minutes later, a full L1, L2, and L3 layer for that industry sits in the catalogue, written in YAML, registered in the index, validated by the lint script, and mapped to the relevant value streams.

The flow

When the skill receives an industry name, it does the following in order.

1. Load the governance model. Naming rules, decomposition rules, MECE rules, identifier rules. The skill reads them every time, so it cannot drift.
2. Read two or three peer L1 files in the closest existing industry. This calibrates local style and depth.
3. Look up the industry in the governance model’s framework section. If the industry is already documented, use the standards listed there. If it is missing, propose a new subsection with the canonical standards for that industry.
4. Propose the full L1 set for the industry, anchored on those standards. Wait for one approval.
5. Decompose each approved L1 into five to nine L2 children, then three to seven L3 children. Write one YAML file per L1, with sparse identifiers picked from a free hundreds-block.
6. Run the lint script. If it complains, fix the YAML, never the rules.
7. Score each new L1 against the existing value streams and propose stage mappings in a single batched table.

The whole run takes an afternoon. Most of that time is reading the proposal and pushing back on names.

Why it works: self-grounding in industry standards

The interesting move is step 3. The skill does not invent a structure for Insurance from a vague memory of insurance companies. It looks up the canonical reference frameworks for the industry and uses them as the scaffolding. For Insurance that means ACORD for data exchange, Solvency II for capital regulation, IFRS 17 for accounting, ISO 31000 for risk, and the IAIS Insurance Core Principles for supervision.

Those frameworks already encode decades of expert agreement on what an insurer does. Anchoring on them produces a capability layer an insurance practitioner recognises immediately, instead of one that reads like a generic guess at “things insurance companies probably do”.

The same principle applies to every industry. Telco gets eTOM, TM Forum SID, and 3GPP. Pharma gets ICH and GxP. Manufacturing gets ISA-95. Mining gets ICMM, JORC, and GISTM. Defense gets DoDAF and EIA-748. Air Traffic Control gets the ICAO Annexes. The skill never picks the framework from training-data soup. It reads the governance model, finds the named anchors, and uses them.

Why it works: self-documenting in the YAML

Each capability node carries a references field that cites the framework it was anchored on. The YAML for an Insurance L1 explicitly lists ACORD, Solvency II, IFRS 17, ISO 31000, and IAIS ICPs. A reviewer can trace any node back to the standard that justifies it.

This closes the loop. The framework section of the governance model lists the standards the catalogue trusts. The capability YAMLs cite those same standards. If a new industry brings new standards, the skill adds them to the governance model and cites them in the YAML it just wrote. Both directions stay in sync.

The lint script enforces that references resolve. If a capability cites an authority the governance model has never heard of, lint fails. The model cannot smuggle in a fake source.

Closing thought

A skill that produces governed artefacts has to do two things at once: speed up the typing, and stay honest. Self-grounding in industry standards handles the second part. The skill knows it is not the authority. The framework is. Everything the model writes is traceable back to a named anchor that someone else, somewhere, already agreed on.

That is what makes the output trustworthy enough to merge.