Skill Constellations: Tracing the Supply Chain of Agent Skills on GitHub

What it is

An MSR-style study of how agent skills (SKILL.md folders run by Claude Code, Codex, Cursor and similar with the user's permissions) propagate between GitHub repositories. It uses the GitSkills dataset (Zenodo DOI 10.5281/zenodo.21875637, released July 2026), with a released dataset (data-v1.0) and an interactive viewer. Skills first committed on or after 1 October 2025 in non-fork repositories are included.

How it works

• Dating and attribution. An adoption is a repo's first commit of a skill. A commit adding 10 or more SKILL.md files is a copy event if a single earlier adopter held at least half of its lineages. That adopter is the source.
• Source-choice model. A conditional logit over log(skills held), past copies, stars and age predicts which earlier adopter a copy event picks as its source. Bundle copies prefer already-copied sources (coefficient 1.64 on log past copies).
• Audit evaluation. Rankings use only the training period, with a temporal split at 1 April 2026 (also 1 March and 1 May). Auditing a repo removes its flagged skills and every descendant copy.

Findings you can act on

• Copying is mostly bulk catalog copying: 33.3% of adoptions are copies versus 8.1% individual. The top 1% of repos account for 94.7% of transmissions, and 64.2% of repos share no skill.
• Stars are a poor signal (Kendall τ = −0.10 against dated out-degree). Current copy out-degree captures 27.8% of later transmissions versus 7.0% for stars. PageRank and skills held perform comparably.
• Static out-degree misleads: only 7 of the top 20 by static out-degree stay in the top 20 once credited only for skills they held first.
• Fixes rarely propagate. Only 11.1% of changes to a clone group reach every copy, and only 4.0% of genealogies ever change consistently. Only 20.9% of skill copies follow a later edit of their source. For comparison, copied code files adopt upstream security fixes in 47–84% of cases. A single owner raises the odds of a consistent change 3.32-fold.
• Copies drift toward more capability. Modified copies gain command execution more than they lose it, and the gain comes from adopting other versions, not from owners' own edits.
• Audit payoff at 100 repos: the model prevents 14.9% of later high-risk adoptions, copy out-degree 16.8%, stars 0.5%, random 0.1%, and a hindsight bound 26.6%. The ordering holds at all three splits.
• Cross-platform leakage. About a third of copies between agent folders now cross platforms, and skills in other agents' folders often name Claude Code-only tools.
• Review window. Half of a skill's adopters arrive by day 56, but only 7.7% by day 7, so reviewers have weeks.

What to do

• Rank repos for review by current copy out-degree (dated, first-holder credit), not stars.
• Review within the first weeks of a new skill's life, and cover every agent folder (.claude, .codex, .cursor, .agents, .github).
• Update copied skills you depend on manually, since upstream fixes will not arrive on their own.
• Platform vendors: distribute versioned references rather than copies, and check that a skill names only tools of the agent loading it.

Caveats

• The copy-source rule names the recorded installer source only 26.7% of the time, because it credits the earlier holder of the most lineages, usually a catalog. Source-level measures describe distribution, not authorship.
• Date reconstruction agrees within seven days of installer records in 94.6% of 1,534 checked folders.
• Risk flags mark capability, not malice. Strict-flag precision is 98.3% and recall 80.9%, so risk counts are lower bounds.
• Even a hindsight ranking prevents only about a quarter of high-risk adoptions, since roughly half arrive as new skills.
• Data cover only the first ten months of the format on public GitHub. Repo-type and risk labels came largely from LLM labelling (Opus 5.5 and Sonnet 5.5) with manual resolution of disagreements.
• The fetched text was truncated mid-figure 4, so later details were not seen.