3.8 Million SKILL.md Files, and Half of Them Are Exact Copies

A mining run against public GitHub in July 2026 found 3,797,117 files named SKILL.md across 282,200 public repositories, nine months after the format appeared. The authors deliberately kept every result, including files whose names merely contain the term, so they call that number a lower bound rather than a total. Of the files they collected, 50.5% are verbatim copies of something else in the set. Byte equality is the only test applied, which makes 50.5% a floor rather than a measure of how much copying goes on.

GitSkills is a dataset release from a group that studies software repositories, not an evaluation. Three pages plus an appendix, shipped as one self-contained SQLite database file. The authors run no model, execute no agent and score no task 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.

What the 3.8 million actually counts

Discovery matched the filename against GitHub's code-search application programming interface (API) and kept every hit, including files whose names merely contain the term and lowercase files that predate the format. That is a design decision rather than carelessness. Every row carries the exact filename, where in the repository the file sits, whether the front matter (the metadata block at the top of the file) parses, and the date of the first commit, 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 counts files whose names matched, and a stricter reading subtracts from there.

Pulling hard in the other direction is everything GitHub code search does not index. Its index reaches files under 384 kilobytes, 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. They also report GitHub's own result count for the query at roughly 349,000, against the more than 3.8 million a size-partitioned search actually returned, which is about ten times more. That gap is a fair warning about how badly a naive count of this artifact goes wrong.

Why 50.5% is a floor and not the real copy rate

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 only when their bytes match exactly. 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 copy checked into your own repository is pinned, which means it does not change underneath you when an upstream author rewrites it, and for a file 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.

Nobody knows whether the copying is spread thin or concentrated

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.

A long tail would mean the duplication is mostly repositories holding many projects at once, project scaffolding, catalogue mirrors and forks of small projects. Each distinct content gets copied a handful of times, and no single file sits 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 would mean something else. If a small set of contents accounts for most of the copying, then one weakness in one of them is already installed across tens of thousands of repositories, with no channel that reaches any of them. That weakness could be 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. It is a supply chain in every sense except the one that would let you patch it. It is also 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. What the security literature has actually measured about that, I have written up separately.

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 means thirty thousand mildly popular files or a few hundred templates carrying the whole format.

The one concentration number we have comes from a different set of files

A separate study that reads files without running them 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 those 138,133 files, which is 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 our own division are what we publish.

Two things stop that from settling the open question. Those 138,133 files are a small fraction of the size of the census, and the corpus 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. 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.

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 stage of the pipeline, under a match criterion that is not byte equality. Do not add the two duplication figures together, and do not average them; neither one corroborates the other. A pair of numbers that happen to land near each other is a coincidence rather than a replication.

The query that would settle this

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, and none are versioned across their copies. At that point the interesting question stops being how many skills exist and becomes which twenty of them everyone is running.

The census is also a picture of what state looks like when nothing has a write path. It gets duplicated, it does not get corrected, and no copy knows it has been superseded. That is the shape of the problem behind the skills question.

We build Synap, 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.