装 Skill 最常见的方式，是看到一个好用的仓库，把 .claude/skills/ 下面的文件夹整个拷进自己的项目，提交，完事。
这一步你多半没觉得是在“装依赖”。但 Skill 是 Agent 会以你的权限执行的说明书和脚本：它可以让 Agent 跑 shell、联网、改文件。你拷进来的，是一段会被执行的东西，而且没有版本号、没有来源记录、没有任何渠道会在它出问题时通知你。
我的判断很简单：Skill 生态把 npm 之前的那套 copy-paste 时代又过了一遍，而这次被复制的是能动手的指令。你仓库里那份 Skill，源头修了你也不会知道。
证据来自 Fahd Seddik《Skill Constellations: Tracing the Supply Chain of Agent Skills on GitHub》（arXiv:2610.11169，2026-10-08）。之前的研究大多只拍一张快照：某个时刻哪些仓库里有哪个 Skill。这篇翻了 GitSkills 数据集里每一个 SKILL.md 的 git 历史，第一次拼出一张带日期、带方向的复制网络：谁先有，谁从谁那里拷，什么时候拷的。覆盖 GitHub 上 2,193,119 次 Skill 采用。作者用 1,534 个记录了来源的安装器文件夹做校验，重建出的日期 94.6% 落在真实记录的 7 天以内。
传播极度集中，而 Star 指错了方向
Skill 不是一个一个被挑选的。三分之一（33.3%）的采用来自整包、整批地复制别人的目录，单个挑着装的只有 8.1%。于是“被复制过的仓库更容易被继续复制”，传播高度集中：前 1% 的仓库贡献了 94.7% 的复制传播。一个叫 web-design-guidelines 的 Skill，经过 12 代转手，进了 972 个仓库。
那谁是这 1%？直觉是看 Star。数据说不对：Star 和一个仓库实际被复制多少次几乎不相关（Kendall τ = −0.10）。用 2026 年 4 月 1 日之前的数据排序，“当前被复制次数”能找到 27.8% 的后续传播，Star 只能找到 7.0%。在没有 Star 的头部源头里，66.4% 只是普通项目，不是什么知名合集。
落到安全审计上，差距更夸张：按作者的复制来源模型挑 100 个仓库审一遍，能拦下留出期里 14.9% 的高风险 Skill 采用；按 Star 挑最火的 100 个，只能拦下 0.5%。随便挑是 0.1%。
也就是说，大家用来判断“这个 Skill 靠不靠谱”的那个数字，跟这个 Skill 的影响面基本没关系。Star 还可以刷，论文专门提了这一点。
源头修了，副本不会跟
这是整篇里我觉得最该转给同事的一组数。
复制来的普通代码文件，上游出了安全修复，有 47%–84% 的情况会被采纳（引自另一项研究）。Skill 副本跟进源头后续修改的比例是 20.9%。一次修改能同步到持有同一版本的所有仓库，只有 11.1%；在整个观察期里曾经整体同步过的谱系只有 4.0%。一旦副本分散在多个所有者手里，一致更新几乎就消失了。
副本也不是一动不动。被改过的副本里，新增命令执行的（3.5%）是删掉命令执行的（1.2%）三倍左右。有意思的是，这些能力不是所有者自己写的：自己动手改，加权限和减权限差不多一样多；权限多出来，主要是因为换成了别人家另一个版本。
还有一层：大约三分之一的复制现在跨 Agent 平台。放在 .codex 目录里的 Skill，23.2% 提到的文件或工具只有 Claude Code 才有；.cursor 目录里是 14.7%。拷过去，不改，指望它在另一个 Agent 里照常工作。
需要说清楚的边界：论文的风险标记衡量的是能力（带可执行文件、预先批准工具、指示危险操作），不等于恶意；而且标记的召回率只有约 80.9%，所以风险数字是下限。数据只覆盖这个格式头十个月的公开 GitHub。
这为什么比 npm 那会儿更麻烦
npm 再乱，至少有 package.json 和 lockfile：你知道自己依赖了谁的哪个版本，npm audit 能告诉你哪个该升级。Skill 什么都没有。它就是一个 markdown 文件夹，拷过来那一刻就和源头断了线。
更麻烦的是执行方式。一个有漏洞的库，还得有代码路径调用到它；一个有问题的 Skill，是 Agent 读了就照着做，权限就是你的权限。论文给的窗口期其实不算短：一个新 Skill 第一周只到达最终采用者的 7.7%，一半要到第 56 天。问题是，按 Star 审计，这几周的窗口你也抓不住。
你现在可以做的三件事
第一，把你项目里的 Skill 当依赖盘点一遍，先看它们能干什么：
find . -name SKILL.md -not -path "*/node_modules/*" | while read f; do
echo "== $f"
grep -nE "^allowed-tools:|Bash\(|curl |wget |rm -rf|ssh |base64|chmod \+x" "$f"
ls "$(dirname "$f")" | grep -vE "^SKILL\.md$"
done除了 SKILL.md 本身，目录里多出来的脚本也要看，Agent 会执行它们。
第二，给每个拷来的 Skill 记下出处，并定期和源头 diff。 在 Skill 目录旁边放一行 source: owner/repo@commit path，然后：
curl -s https://raw.githubusercontent.com/OWNER/REPO/main/PATH/SKILL.md | diff -u .claude/skills/NAME/SKILL.md -源头改了什么、你落后了多少，一眼可见。记不清来源的 Skill，要么找回源头，要么当成你自己维护的代码来审。
第三，如果你是发布 Skill 的那一方， 别再写“把这个文件夹拷到你的项目里”。用带版本号的插件、marketplace 或 git submodule 这类“引用”方式分发，让修复有路可走。也别让给 Claude Code 写的 Skill 被原样塞进别的 Agent。
一句话：Skill 不是一段提示词，是一段会以你的权限执行的依赖。拷进来那一刻它就和源头断了线，你得自己把线接上。
The usual way to install an agent skill: you find a repo with a useful one, copy the folder under .claude/skills/ into your project, commit, done.
It probably doesn't feel like adding a dependency. But a skill is instructions and scripts that your agent runs with your permissions: it can run shell commands, reach the network and edit files. What you just copied is executable, and it comes with no version, no provenance and no channel that will ever tell you when it breaks.
My take is simple: the skill ecosystem is replaying the pre-npm copy-paste era, except this time what gets copied can act. When the source fixes your skill, you won't find out.
The evidence is Fahd Seddik, "Skill Constellations: Tracing the Supply Chain of Agent Skills on GitHub" (arXiv:2610.11169, 8 Oct 2026). Earlier studies mostly took a snapshot: which repos held which skill at one moment. This one walked the git history of every SKILL.md in the GitSkills dataset and built the first dated, directed copy network: who had it first, who copied from whom, and when. It covers 2,193,119 skill adoptions on GitHub. Checked against 1,534 installer folders that recorded their source, 94.6% of reconstructed dates land within seven days of the record.
Spread is concentrated, and stars point the wrong way
Skills aren't picked one at a time. A third of adoptions (33.3%) come from copying someone's whole directory in bulk or in bundles; only 8.1% are single picks. So repos that have been copied get copied more, and spread concentrates hard: the top 1% of repositories account for 94.7% of transmissions. One skill, web-design-guidelines, passed through 12 generations of copies into 972 repos.
Who's in that 1%? The instinct is to look at stars. The data says no: stars barely track how often a repo is actually copied (Kendall τ = −0.10). Ranked on data before 1 April 2026, current copy count finds 27.8% of later transmissions; stars find 7.0%. Among the top sources with no stars, 66.4% are ordinary projects, not famous collections.
For security audits the gap is brutal. Review the 100 repos the author's source-choice model ranks highest and you prevent 14.9% of later high-risk skill adoptions in the held-out period. Review the 100 most-starred and you prevent 0.5%. Random picks get 0.1%.
The number everyone uses to decide whether a skill is trustworthy has almost nothing to do with how far it spreads. And, as the paper notes, stars can be bought.
Fix the source, and the copies stay broken
This is the set of numbers I'd forward to a teammate.
Copied ordinary code files pick up upstream security fixes 47% to 84% of the time (per earlier work the paper cites). Skill copies follow a later edit at their source 20.9% of the time. Only 11.1% of changes reach every repo holding the same version, and only 4.0% of lineages ever update in sync. Once copies spread across several owners, consistent updates all but vanish.
Copies do drift. Among modified copies, about three times as many gain command execution (3.5%) as lose it (1.2%). And the extra power doesn't come from owners' own edits, which add and remove capabilities about equally. It comes from swapping in someone else's version.
One more layer: about a third of copies now cross agent platforms. Of skills sitting in .codex folders, 23.2% name files or tools only Claude Code has; in .cursor folders, 14.7%. Copied over, unchanged, expected to just work in another agent.
The honest limits: the paper's risk flags measure capability (bundled executables, pre-approved tools, risky instructions), not malice, and with a recall of about 80.9% the risk counts are lower bounds. The data covers the format's first ten months on public GitHub.
Why this is worse than early npm
However messy npm got, you had package.json and a lockfile: you knew whose code at which version you depended on, and npm audit told you what to upgrade. Skills have none of that. A skill is a folder of markdown, and the moment you copy it, the line to the source is cut.
Execution makes it worse. A vulnerable library still needs a code path that calls it; a bad skill is something the agent reads and follows, with your permissions. The paper's response window isn't even short: a new skill reaches 7.7% of its eventual adopters in week one and half by day 56. But if you audit by stars, you miss that window anyway.
Three things you can do now
First, inventory the skills in your project like dependencies, starting with what they can do:
find . -name SKILL.md -not -path "*/node_modules/*" | while read f; do
echo "== $f"
grep -nE "^allowed-tools:|Bash\(|curl |wget |rm -rf|ssh |base64|chmod \+x" "$f"
ls "$(dirname "$f")" | grep -vE "^SKILL\.md$"
doneLook at the extra scripts in each folder too, not just SKILL.md. The agent runs them.
Second, record where each copied skill came from and diff it against the source regularly. Put one line next to it, source: owner/repo@commit path, then:
curl -s https://raw.githubusercontent.com/OWNER/REPO/main/PATH/SKILL.md | diff -u .claude/skills/NAME/SKILL.md -You see what changed upstream and how far behind you are. A skill whose origin nobody remembers either gets its source tracked down or gets reviewed as code you now maintain.
Third, if you publish skills, stop saying "copy this folder into your project". Ship them as references with versions, such as a versioned plugin, a marketplace entry or a git submodule, so fixes have a path to travel. And don't let a skill written for Claude Code get dropped unchanged into another agent.
In one line: a skill isn't a prompt; it's a dependency that runs with your permissions. The moment you copy it, it's cut off from its source, and reconnecting it is your job.