Your Agent Skills Are Copy-Pasted: What 2.19M Adoptions Reveal About the Supply Chain

In one sentence: your agent skill was probably copied — and never updated since

On October 8, Fahd Seddik of the University of British Columbia posted a paper on arXiv titled Skill Constellations: Tracing the Supply Chain of Agent Skills on GitHub (2610.11169). On October 10, the security publication Ground Truth covered it. The paper does something nobody had done before: it dug through the git history of every SKILL.md file on GitHub and reconstructed the "copy network" of agent skills — who copied from whom, and when. For the first time, there is a dated answer.

A quick primer, so we are talking about the same thing. An agent skill is a folder containing a SKILL.md file of instructions, plus scripts. AI coding agents like Claude Code and Codex read it and act on it — with your user permissions: running shell commands, hitting the network, modifying files, all of it. Installing a skill is therefore closer to "installing software" than to "bookmarking a page." You think you are saving a workflow write-up; in reality you are handing the agent a permission slip.

Now the scale: 2,193,119 skill adoptions, 259,596 repositories, 1,612,846 distinct skills. The most striking number: half of all SKILL.md files on GitHub are verbatim copies of another file. Half. Every other skill readme you stumble across on GitHub came out of a photocopier.

The paper calls the copy network of a single skill its constellation. A static snapshot can only tell you "which repositories hold this skill right now"; only git history can tell you "who held it first, who copied from whom, and how many hands it passed through." Every finding in the paper rests on that dated copy graph. Earlier security research mostly stayed at the snapshot level: counting which repositories hold a skill, or examining one or two skills at a time. This is the first time anyone made "spread itself" the research subject.

One more dimension the headline numbers hide: time. Those 2.19 million adoptions happened in under a year. The paper only includes SKILL.md files first committed on or after October 1, 2025 — the format itself is barely ten months old. Ten months, from zero to 250,000 repositories, 1.61 million distinct skills, half of all files verbatim copies. That expansion speed is rare in software-ecosystem history: npm took years to reach this scale. The skill ecosystem sprinted to this size with no package manager at all, running on copy-paste. The missing infrastructure is not a future risk; it is the already-existing present — nobody had just drawn it before.

How they "saw" the copying: the methodology deserves its own section

The methods section of this paper is readable — and borrowable — even for practitioners. The data source is GitSkills (released July 2026, archived on Zenodo), covering files named exactly SKILL.md with valid front matter, first committed on or after October 1, 2025, in repositories that are not forks. The authors then pulled the complete git history of every SKILL.md path from a clone of each repository's default branch.

Two definitions do the heavy lifting. First, a lineage: the versions of one skill linked by edits, whose first adoption is its origin. Second, a copy event: a commit that adds ten or more SKILL.md files counts as a copy when a single earlier adopter already held at least half of the existing lineages — and that earlier adopter is deemed the source. The ten-file threshold filters out "I wrote a few skills myself" and catches "I lifted the whole bundle from someone else."

The authors cross-validated against installer records: the inferred copy relationships line up with real installation logs, so this "guess who copied whom from git history" approach is not armchair theory. There is a careful caveat, too: the inferred source is a distribution source, not proof of original authorship — a repository can become influential by republishing other people's work without writing a single original instruction. That distinction matters, and it comes back in the section on stars.

The paper poses four research questions. In plain language: what does skill copying look like, and what drives it (RQ1)? Which repositories originate the spread, and do stars identify them (RQ2)? Where do high-risk capabilities sit in the copy network, and do fixes reach existing copies (RQ3)? Where should audits be aimed, and does network position beat popularity as a targeting signal (RQ4)? Here are the findings, in that order.

Copying beats original adoption: this supply chain was photocopied into existence

The statistics are blunt (Fig. 2a): of all skill adoptions, 33.3% arrived by copying, 8.1% by individual adoption, and the remaining 58.6% are origins. In other words, every third time a skill shows up in a new repository, it was copied outright rather than written by the owner.

And the copying is concentrated. A tiny minority of repositories does nearly all the spreading: the top 1% of repositories accounts for 94.7% of all transmissions (Fig. 2c). The paper gives a concrete example: the skill web-design-guidelines has 972 adopters, 490 of them reached through transmission chains, with the deepest chain running 12 generations (Fig. 1b). Picture it: a skill copied hand-to-hand 12 times — by the 12th repository, how much is left of the original? If any hand in the middle changed something, nobody downstream would ever know.

Fig. 1a visualizes the whole repository network: 50 communities of at least 100 repositories (12 labeled by topic), and the outer ring — 64.2% "isolate" repositories that hold skills but don't participate in spreading them. The real distribution hubs hide in that small bright cluster in the middle. The first impression should be: the skill world is not "a thousand flowers blooming"; it is "a few sources plus countless photocopies."

The fix never arrives: this supply chain has no update channel

This is the paper's most sobering line for ordinary users: skill copies almost never change with their source. A fix at the source rarely reaches the copies already installed.

Think of it this way: a company photocopies its emergency procedure and posts it on every floor; six months later headquarters revises the procedure — the photocopies on the walls don't update themselves. That is exactly how agent-skill distribution works today: no registry, no versions, no provenance. npm has lockfiles and semver, pip has requirements.txt, even browser extensions auto-update. Skills have nothing. Installing a skill is fundamentally a copy-paste, and once pasted, the copy is cut off from its source.

For vibe coders, this means the pile of skills sitting in your repos and under ~/.claude/skills is very likely a set of frozen copies of some months-old version. Does it carry known issues? Did the author fix them later? Would you even know? The answer to all three is "no." Worse, a skill is not an ordinary document: it is instructions and scripts that your agent executes with your permissions. A frozen old skill is risky not because it is "outdated" but because it keeps running with old problems.

Modified copies: capabilities are copied in, not written

There is an easily missed finding about the copies that are not verbatim. Intuition says: if an owner modified their copy, they are maintaining it, and the edits make it better fit their needs. The data says otherwise: modified copies gain new capabilities mostly by adopting other versions — not through the owner's own edits.

That carries a lot of weight. It means skills don't evolve by "forking and growing apart" the way open-source software does after a fork; they evolve by "re-collaging." A repository's skill got stronger not because the owner wrote something new, but because the owner copied in a stronger version from elsewhere. In this evolution model, "maintained by the original author" barely exists — everyone is a republisher, republishing from other republishers.

One level deeper: high-risk capabilities (bundled executables, pre-authorized risky tool calls) distribute across this network by the same propagation logic, not by "who wrote them." A high-risk skill is dangerous not because some villain wrote it, but because some hub repository republished it and the copy chain carried it outward. Defending against "people who write bad skills" and defending against "hubs that redistribute them" are two completely different security strategies. This paper takes the second one.

Ground Truth's coverage flags a noteworthy extension: the same analysis applies to shipping bundles like Anthropic's knowledge-work plugins — skills combined with connectors, commands, and workflow components. The paper accuses no such bundle of wrongdoing; it simply poses a question everyone should answer: where did your skill come from? Is there a version reference? How do updates reach people who already installed it? What permissions does it get after installation? Official bundles don't get a pass either.

Stars can't find the hubs: everyone is auditing the wrong list

The paper's most counterintuitive finding concerns stars. The Kendall correlation between a repository's star count and its dated out-degree ("how often it gets copied") is -0.10 — essentially nothing. A heavily starred repository is no more likely to be a skill's distribution source; the real hub may be a project nobody ever starred.

The authors tested this with a simulated audit: auditing the 100 repositories ranked highest by their propagation model would intercept 14.9% of later high-risk skill adoptions; auditing the 100 most-starred repositories would intercept only 0.5%. A thirty-fold gap (Fig. 2e). Finer numbers: ranking by copy out-degree captures 27.8% of later transmissions versus 7.0% for stars; and of the unstarred top sources, 66.4% are ordinary projects (Fig. 2f) — not awesome-lists, not influencer repos, just ordinary projects.

This one is worth writing down for anyone doing security: people install skills by star count, and security teams build audit lists by star count — this paper says both are looking at the wrong metric. What deserves auditing is the hub nodes of the propagation network. Stars measure attention; the copy network measures how content actually flows. Those are different things.

A practical note: if your team wants to act on this today, you don't need the paper's model. List every skill's source repository in your team, rank them by "how often they get copied" instead of "how many stars they have" — the top few are your audit priority. Audit what? Three things: has it been updated recently, and what changed; do its declared permissions match its actual behavior; does its upstream have an upstream? Ten minutes of work that almost nobody does.

Before you panic: what the paper does not say matters as much as what it does

Careful readers will notice the authors' restraint, and Ground Truth spent serious column inches on these qualifications — worth relaying:

First, the risk labels flag capabilities, not malice. On a 200-skill manually labeled sample, the strict flag hit 98.3% precision and 80.9% recall. But it flags capabilities like "bundled executables" or "pre-approved risky tools" — a useful automation script and a malicious script can both execute commands. The label means "worth a closer look," not "there's a bad actor here." The authors call their risk counts a lower bound: unflagged does not mean safe.

Second, the 14.9% vs 0.5% is a simulated audit, not a real interception. The authors simulated "what if we had audited these repositories" against a held-out later period; no live intervention was ever deployed. The paper itself admits new skills outside the known graph still account for a substantial share of later risky adoptions. The simulation proves "network-ranked beats star-ranked" — not "this stops attacks."

Third, the scope is public GitHub's first ten months of the format, excluding forks. Your private pile of skills, and everything passed around inside company intranets, is not on this map.

So the paper is not saying "skills contain viruses." It is saying "non-malicious structural risk": even if everyone is a good actor, a copy chain with no versions and no update channel keeps fixes from reaching users on its own. Our earlier coverage of SkillCloak was about malicious skills; this is the other side — a good skill written by good people, copied 12 hands deep, is just as easily a frozen version carrying old problems. Structural risk is harder to defend against than malice, because it doesn't need villains to exist.

Four suggestions for vibe coders

1. Before installing a skill, check where it came from — not how many stars it has. The paper ships an interactive viewer (fahdseddik.github.io/Skill-Constellations); the code and data are open too (the Skill-Constellations GitHub repo, data release data-v1.0). Next time you install a skill from some awesome-list, spend two minutes checking its source repository and update status — if the source hasn't moved in three months, think twice. Star count is noise here; the paper stamped it with a -0.10 correlation.

2. Team-shared skills must be versioned. The paper's advice to platforms boils down to: distribute versioned references, not copies. That maps directly onto Tencent Cloud's just-open-sourced TeamAI — skills in a git repo, distributed via a push → review → pull flow (covered separately on this site). Personal skills can be copied casually; team skills must be managed like dependencies: pinnable versions, receivable updates, reviewable changes. Tools like TeamAI are valuable precisely because they add the missing "update channel" to the copy chain. Amusingly, TeamAI makes in-team skill sharing easier, while this paper warns that easier sharing means longer copy chains and fixes that never arrive — read the two stories together for the complete picture: sharing skills is a genuine need, but sharing must carry versions.

3. Put skills on your mental "dependency list." Periodically check ~/.claude/skills and the skills directories in your projects for frozen copies untouched for months. Everyone runs npm audit; there is no handy skill-audit tool yet, but the manual review habit can start now. The minimum bar: you can say where each skill came from, which version it is, and when the author last updated it. If you can't, don't let it run with your shell permissions.

4. If you distribute skills yourself — tutorials, awesome-lists, skill collections — you are a node in the propagation network. The data says the top 1% of repositories contributes 94.7% of transmissions, and many "hubs" don't know they are hubs. When you republish a skill, attach the source link and version; when the source updates, sync your copy. That's not charity; it's currently the only working "update channel" this supply chain has: humans.

What npm spent a decade solving, skills haven't started

Compare skills today with npm's early days and history rhymes. Early npm was also a copy-paste world; then came the registry (recording provenance), semver (version expectations), lockfiles (pinning the dependency tree), and audit (scanning known vulnerabilities). The skill ecosystem in 2026 is still in the copy-paste era: no registry for provenance, no pinnable versions, no channel that delivers fixes.

The paper's closing suggestion is restrained: platforms should distribute versioned references rather than copies. In plain words: stop making users copy folders; give skills a "name@version" like npm packages — install the reference, deliver updates through a channel. Until that day comes, every vibe coder's stopgap is the four suggestions above: check the source, demand versions, review regularly, and cite the source when you republish.

The phrase "supply chain security" gained a new meaning in the agent world of 2026: we used to worry about npm package poisoning; now we must worry about the pile of markdown we let our agents read — possibly 12th-hand photocopies of an original that changed long ago. The paper is titled "Skill Constellations"; finishing it, all I see is that behind every star drags an invisible photocopy chain. And the length of that chain decides how close you are to the risk.