How the skills are built

The bundles are generated from the site's own pages by a build step: how the conversion works, why the archives are byte-reproducible, what the checks enforce, and what the published research says about the limits of skills as a format.

The skills on this site are not written twice. A build step takes the same pages you read in a browser and converts them to plain Markdown. It packages them with a short instruction file. This page shows how that works. A reference you install is only trustworthy if you can see how it was made. The bundles are reproducible. The same content always produces the same fingerprint, so a changed fingerprint means the content changed.

One source, two outputs

The pages provide a versioned starting point for analysis. Check their evidence and test their recommendations against the task. A skill adds two things to them. The first is an instruction file that says when the material is useful and how to work through it. The second is a choice of which pages travel together.

The instruction file is written by hand, on purpose. Its description is the only text most agents ever read. It decides whether the agent reaches for the skill at all. So it is written for that job, not generated from a page's summary. Everything underneath is generated. So the references cannot drift from the pages they came from.

The conversion

Pages are written in MDX, which mixes Markdown with components. The components carry real content: a figure's underlying data, a chart's numbers, a glossary. Stripping the components would quietly drop the evidence a skill exists to supply, so each one has an explicit rendering:

On the page	In the bundle
A diagram	Its title, its takeaway, its caption, a description of what it shows in words, and a link to the SVG
A results chart	A GitHub-flavoured table of the same numbers, plus the caption and the experiment artifact it came from
Stat tiles	A table of measure, value and note
A glossary term	Its own words, with the tooltip dropped
The full glossary	Every term and definition, grouped

On the page: A diagram
In the bundle: Its title, its takeaway, its caption, a description of what it shows in words, and a link to the SVG

On the page: A results chart
In the bundle: A GitHub-flavoured table of the same numbers, plus the caption and the experiment artifact it came from

On the page: Stat tiles
In the bundle: A table of measure, value and note

On the page: A glossary term
In the bundle: Its own words, with the tooltip dropped

On the page: The full glossary
In the bundle: Every term and definition, grouped

A component with no rendering fails the build rather than vanishing from a bundle. So a new component on a page cannot silently leave a gap in a published skill.

Site-relative links become full web addresses. So a reference in a bundle can still be followed back to its page. Every reference also opens with the URL it was generated from.

Reproducible archives

The discovery index names each bundle by a sha256 digest, a fingerprint of the file. That only helps if the same inputs always produce the same bytes. So the archive writer fixes everything that could vary:

entries are sorted by path;
timestamps are pinned, not taken from the clock;
file attributes are fixed;
the compression level is set.

Building twice produces identical files. A digest that changes tells you the content changed. Nothing else can move it.

What the checks enforce

Before anything is written, and again against what was written, each bundle is checked:

Frontmatter within the specification. Frontmatter is the block of fields at the top of the file. Exactly six fields are allowed. Any other field is a hard error when uploading to claude.ai or through the API. So a bundle that works locally could still fail everywhere else. The check refuses it early.
The name matches the folder, is lowercase with single hyphens, is at most 64 characters, and contains no reserved word.
The description is present, under 1024 characters, and says when to use the skill. A description that only says what something is will not trigger.
The body is under 500 lines, with the detail in references rather than in the instruction file.
References are one level deep and in a readable format. Every bundled file is mentioned in the body. A file that nothing opens only adds weight.
Digests match the bundles they claim to describe.

Where they are published

One build publishes to three places:

the discovery index at /.well-known/agent-skills/index.json, with a downloadable archive per skill;
a public repository laid out the way the installers expect;
a Claude Code plugin marketplace in that same repository.

What the evidence says about skills

The format is worth using, with care. Published analysis looked at a large public set of skills. Most were single-version and never updated. Only about six percent appeared on more than one marketplace. Roughly a quarter raised concerns about the scope of their instructions. Separately, machine-generated context files were measured to slightly reduce task success while raising cost. Reuse is claimed more often than it is shown.

Three consequences shape how this site publishes them. Bundles are generated from maintained pages rather than written once and abandoned. Each carries the date of its newest input, so staleness is visible. And the instruction files are written by hand and reviewed, because the measured problem with generated context is real.

The deeper treatment, including progressive-disclosure economics and the governance a skill library needs, is on the agent platform layer (R07).

Explore this topic

The agent platform layer (R07): skills as a capability format, progressive disclosure, signing and version pinning, and the measured limits
The catalogue and the install instructions