# Half of the Published Skill Files Are Copies of the Other Half

Nine months after the SKILL.md format appeared, a mining run against public GitHub returned 3.8 million SKILL.md files (3,797,117) as filename matches across 282,200 public repositories in July 2026, and because the authors deliberately retained files that merely contain the term, they call the count a lower bound. Of those collected files, 50.5% are verbatim copies, which is byte-identical only and therefore a floor rather than a measure.

[GitSkills](https://arxiv.org/abs/2608.10906) is a dataset release from a mining-software-repositories group rather than an evaluation. Three pages plus an appendix, shipped as a self-contained SQLite file, with no model run, no agent executed and no task scored anywhere in it. Nothing in the paper says whether a single one of these files works. What it does establish is the physical shape of the ecosystem at population scale, which nothing else currently does, and that is why both of its headline numbers are about to travel a long way. Both are easy to carry wrongly. Every figure below, with its caveat attached, also sits in [The Agent Skills Evidence Base](https://www.maximem.ai/research/agent-skills).

## What a filename match is counting

Discovery matched the filename against the GitHub code-search API and kept every result, including files whose names merely contain the term and lowercase files that predate the format. That is a design decision rather than carelessness, because every row carries the exact basename, the location class, front-matter validity and a first-commit date, so an analyst who wants a stricter population can impose one afterwards. It does mean that 3.8 million is not a count of skills. It is a count of files whose names matched, from which a stricter reading subtracts.

Pulling harder in the other direction is everything GitHub code search does not index. Its index reaches files under 384 KB, on default branches only, in repositories with fewer than 500,000 files, and those constraints are what make the census a lower bound rather than a count. Repositories that have gone quiet drop out as well, and forks surface only once they have accumulated more stars than the parent. Private and enterprise repositories are invisible altogether. The authors say plainly that the dataset should be read as a lower bound on the population, and they also put GitHub's own reported result count for the query at roughly 349,000 against more than 3.8 million retrieved by a size-partitioned search, roughly an order of magnitude out, which is a fair warning about how badly a naive count of this artifact goes wrong.

## Why half is a floor rather than an answer

Content hashing is the entire method behind 50.5%, and the arithmetic under it is that 3,797,117 collected files collapse to 1,877,981 distinct contents under exact content hashing. Two files count as copies when their bytes match exactly, so a copy that survives with one path changed, a heading renamed, a table reflowed, a trailing newline added or a project name substituted registers as distinct content and gets counted as an original. Everything a human reader would recognise as reuse with edits falls outside the figure. Half is what the strictest available definition of copying produces, and the true reuse rate is higher by an amount nobody has measured.

Reading that duplication as waste is the first mistake on offer. A skill is a folder of markdown that an agent reads, and copying that folder into a repository is the distribution mechanism working as designed rather than a hygiene failure; a vendored copy is pinned, which means it does not change underneath you when an upstream author rewrites it, and for an artifact that gets injected into an agent's instruction stream, pinning has an argument in its favour that pulling from a live registry does not. The package-manager comparison everyone reaches for cuts in both directions. A registry buys deduplication and updates, and it also creates an update channel that somebody else can push through.

Quality is the second mistake, and GitSkills measures none of it. Every question about whether these files help an agent do anything is listed in the paper as future work, and the authors note that a taxonomy of skill purposes does not yet exist. A duplication rate describes how the ecosystem propagates. It says nothing about what is propagating.

## The question that decides what the number means

What the paper does not answer, and says so directly, is the shape of the copying. The research agenda poses it as a question: "How concentrated is reuse: a long tail of rarely copied contents, or a small set of widely copied templates?"

Those two worlds produce the same 50.5% and behave nothing alike.

Long tail means the duplication is mostly monorepos, scaffolding, catalogue mirrors and forks of small projects, with each distinct content copied a handful of times and no single file sitting inside a large share of the world's agent context windows. Risk stays diffuse under that reading. A weak skill degrades its own neighbourhood and stops there, and the correct response to the census is roughly nothing.

Templates mean something else. If a small set of contents accounts for most of the copying, then one weakness in one of them, whether that is a description the model cannot route on, a hardcoded path, a stale command, or an instruction that quietly widens what the agent is permitted to touch, is already installed across tens of thousands of repositories with no channel that reaches any of them. That is a supply chain in every sense except the one that would let you patch it, and it is the reading the same authors have in mind when they ask whether modified copies of widely reused skills introduce command execution or network access absent from the original, which they call the analog of a supply-chain attack in an ecosystem without a registry. I have written up what the security literature has actually measured about that [separately](https://www.maximem.ai/research/agent-skills/agent-skill-security).

Nobody has run the query. It is a group-and-count over the content-hash column of a file the authors have already archived, and it would take an afternoon; until someone does it, the honest position is that the ecosystem is half copies and we do not know whether that is thirty thousand mildly popular files or a few hundred templates carrying the whole format.

## One concentration measurement, from a different corpus

A separate [static-analysis study](https://arxiv.org/abs/2608.08453) works over 138,133 deduplicated public SKILL.md files and reports a concentration figure of its own, for that corpus rather than for the population: the largest single repository contributes 17,284 of 138,133 files (12.5%). One repository, an eighth of a deduplicated corpus. The paper prints 12.9% for that fraction, and 17,284 divided by 138,133 is 12.5%, so the fraction and the division are what we publish.

Two things stop that from settling the open question. That corpus is a small fraction of the size of the census and was assembled with different queries and a registry API alongside GitHub, so it is a different population. It is also deduplicated by content hash before the concentration is computed, which measures where distinct skills are authored rather than how far any of them travel, and travel is what the open question is about. That same corpus is where the conformance picture comes from, and its rules-violation rate is a different argument, [which I have kept separate](https://www.maximem.ai/research/agent-skills/how-to-write-a-skill-md).

Worth naming one more trap while the numbers are in the air. A second corpus in this literature reports its own duplication rate, over a different population, at a different pipeline stage, under a match criterion that is not byte equality. The two duplication figures should not be added, averaged, or read as corroborating each other, and a pair of numbers that happen to land near each other is a coincidence rather than a replication.

## What would settle it

Two columns in the released dataset answer the question that matters: the content hash and the file occurrence it belongs to. Group the occurrences by content hash, sort the group sizes, and look at the head of the distribution. If the top thousand contents cover a small slice of the 3.8 million, the ecosystem is a long tail and the duplication rate is a curiosity about how developers scaffold projects. If they cover a large slice, then a small number of markdown files are shaping the behaviour of a very large number of agents, none of them are signed, none of them are versioned across their copies, and the interesting question stops being how many skills exist and becomes which twenty of them everyone is running.

We build [Synap](https://www.maximem.ai/), which is a memory layer for agents, so the census above is somebody else's data and the register it is checked against is published in the open.

---

Source: [https://www.maximem.ai/research/agent-skills/agent-skills-ecosystem-data](https://www.maximem.ai/research/agent-skills/agent-skills-ecosystem-data)