platform-skills

The platform-skills repository teaches every coding agent how to work on Airframe. A skill is a set of instructions a coding agent loads when its task matches: where a change belongs, how the catalog works, how a product’s roots are shaped, how things are named, what each policy rule refuses and what to do instead. Each skill comes with tests that the platform’s real checks run, so a skill that stops matching the rules fails here before it misleads anyone.

What it is for

A coding agent that does not know the platform’s rules learns them the slow way: it writes a change, the pipeline refuses it, it reads the message and tries again. The skills give it the rules up front, so its first attempt is usually the conforming one. They are the same rules a person reads in these pages, written for a coding agent to act on.

What is in it

Five skills, each a folder with its instructions, SKILL.md, and its tests:

airframe-platform: how a change becomes infrastructure, from airframe validate to production, and what a coding agent never does. It is the one to load first.
airframe-catalog: the catalog’s files, what is derived from them, who approves what, and the catalog checks’ messages with their fixes.
airframe-infra: a product’s roots, the golden-path modules, and what the modules do not cover.
airframe-naming: how every resource, hostname, label and state prefix is named.
airframe-policies: every policy rule, its level, its message as printed, and the conforming alternative.

A person installs a skill with one command per skill, and a product repository’s instructions for a coding agent point to them. More skills are planned, such as one for services and one for pipelines, as their modules and rules settle.

How it connects

It is tested against the policy pack. A skill’s examples are Terraform roots, pipeline files, Dockerfiles, catalog entries and cost summaries that the policy pack, terraform validate or the catalog’s checks must accept or refuse, with the message the skill quotes.
It pins a release. The tests run against the policy pack at the control-plane commit of the release the skills pin, and a new release runs them again before it is permitted.
It names real paths. A test checks that the repository paths listed in a skill’s tests/references exist on that repository’s main branch, so a moved file breaks the skill here rather than in a coding agent’s work.

Who changes it, and how

Changes are merge requests approved by the platform team, with the gate’s approval required; this was the first repository the gate enforced, on 2026-09-28. The pipeline runs four jobs: skills:policy, skills:validate, skills:catalog and skills:references, and GitLab merges a change only when they pass.

Two limits are worth knowing. Four of the five skills ship examples that these jobs check; airframe-platform ships none yet: only the paths it names are checked, not what it says about the platform’s behavior. And whether a coding agent loads a skill at all is up to the agent and its user: the platform’s checks apply either way.

The repository has no roots and costs nothing while idle.

Where it lives

In the platform-skills repository: