Imported from yan-labs/yan-skills (
skillsmp/SKILL.md). Install upstream withnpx skills add yan-labs/yan-skills --skill skillsmp. Copyright stays with the author.
SkillsMP
搜 SkillsMP —— 目前最大的公开 Agent Skill 索引(1.6M+ 个 SKILL.md,来自 GitHub,覆盖 Claude Code、Codex、ChatGPT)。
要动手写一个新 Skill 之前,先来这里搜一遍。 别人写过的概率比你以为的高。
一句话 → 用哪个能力
用户不会说「跑 treasure.mjs --pages 5」。他会说下面左边那些话。
| 用户大概会这么说 | 从这里开始 |
|---|---|
| 「有没有现成的 skill 能做 X」「找个 skill」 | node scripts/search.mjs "X" --limit 20。命中少就换个说法再搜一次,别断言「不存在」 |
| 「我想写个做 X 的 skill」(动手前必答) | 先 search.mjs "X",看有没有人写过。这是本 Skill 存在的第一个理由 |
| 「这个领域已经有哪些 skill 了」「盘一下现状」 | node scripts/search.mjs "领域词" --pages 3 --json,存本地再过滤,别反复重搜(配额按天算) |
| 「找点好东西」「有没有小众但写得好的」「挖宝」 | node scripts/treasure.mjs "关键词" --pages 5 --top 15。它出全量候选 + 原始信号,sortKey 只是排序键、不是评分,也不替你丢行 |
| 「按星数给我排一下」 | 可以,但先读下面那条坑:stars 是仓库星数,不是这个 Skill 的。treasure.mjs --sort stars 换排法用的是同一批候选 |
| 「太多了,把大厂仓库的过滤掉」 | --max-stars N。没有默认值:不给就一条不过滤;给了也只标 aboveMaxStars 折叠,不删行,--json 里照样全在 |
| 「只要中文的 / 只要 DevOps 的 / 只要给开发看的」 | --lang zh · --category devops · --occupation software-developers |
| 「搜出来只有 5 个?」 | 那是 pagination.total 在骗人(totalIsExact:false,严重偏低)。翻页只认 hasNext |
| 「这个 skill 到底行不行」 | 打开它的 githubUrl 读一眼再下结论。description 是作者的营销文案,不是验证过的能力 |
它不做的事:装 Skill、写 Skill、评审 Skill 质量。它只把候选摆到你眼前。
目录
skillsmp/
├── SKILL.md ← 你在这里:怎么搜、怎么挖宝、两个必须知道的坑
├── .env.example ← 复制成 .env 填 API Key(可选;.env 已被忽略,绝不提交)
└── scripts/
├── search.mjs 直搜。可翻页、可按分类/职业/语言过滤,可 --json
└── treasure.mjs ★ 挖宝。故意不按星数排,理由见下。出全量候选 + 原始信号,
排序键只是排序键,不丢行也不下判决
先跑起来
不需要任何配置——匿名就能用(50 次/天、10 次/分钟):
node scripts/search.mjs "关键词" --limit 20
想要 500 次/天,就配一个 Key:
cp .env.example .env # 然后把 Key 填进去
Key 从 https://skillsmp.com/docs/api 生成。它是凭据,只放 .env,绝不进仓库
(仓库的 .gitignore 已经拦了 */.env,别绕过它)。
两个必须知道的坑
★ 不是这个 Skill 的星数,是它所在仓库的星数
这是本 Skill 存在的主要理由。API 返回的 stars 是包含该 Skill 的 GitHub 仓库
的星数。实测:某条结果报 240467,而它所在仓库的真实星数是 240743 —— 对得上,确认无疑。
后果很实际:
- 一个塞在超高星仓库里的 Skill(哪怕只是整包机翻的文档)自动继承那个星数;
- 一个作者单独开仓库、认真写的单一用途 Skill,只有个位数星。
实测搜 backlink 按星排序,前四条里三条来自同一个 28562★ 的笔记仓库,
讲的是笔记系统内部的双向链接,跟外链毫无关系。高星把语义对口的结果整个淹掉了。
所以:sortBy=stars 排出来的不是「最好的 Skill」,是「住在最红仓库里的 Skill」。
翻页要认 hasNext,别认 total
pagination.total 附带一个 totalIsExact: false,而且实测严重偏低——百万级索引里
搜 SEO 只报 total: 5。按 total 算页数会漏掉绝大部分结果。
唯一可靠的翻页依据是 hasNext,两个脚本都已经这么做了。
挖宝:找「写得好但没人知道」的
既然星数不是质量信号,就别用它排。treasure.mjs 采集四个跟仓库名气无关的信号:
node scripts/treasure.mjs "关键词" --pages 5 --top 15
node scripts/treasure.mjs "关键词" --pages 5 --sort stars --json # 换个排法,同一批候选
信号(signals 里的原始观测值) |
想法 |
|---|---|
stars / 独立性 |
所在仓库星数越低,越说明这个 Skill 靠自己站住,不是搭便车 |
repoCount / 专注度 |
同一仓库在本次结果里出现几条。一个仓库刷出几十条,通常是批量生成或整包翻译的文档堆 |
descLength + hasTriggerWording / 描述具体度 |
好的描述会写清什么时候该用(触发条件、场景、反例),而不是「帮你做 X」。这是分辨用不用心最单一有效的信号 |
ageDays / 新鲜度 |
长期没动的多半已经烂掉 |
同名同作者跨多语言的条目会被去重——那是整包机翻,一个仓库能刷满整页。 去重是唯一会减少候选数的一步,而且减了几条会报出来。
排序键不是判决,脚本也不替你丢行
| 规矩 | 落实在哪 |
|---|---|
sortKey 只是排序键,不是评分、不是质量结论 |
输出里叫 sortKey/sortKeyParts,权重是随手定的、没有实测支撑;--sort key|stars|updated|none 随时换排法或不排 |
| 原始信号照给,可回到搜索结果核对 | 每条候选带 signals,报告里要引用就引用它,不要引用 sortKey |
--max-stars 没有默认值 |
不给就一条不过滤。以前默认 5000 会在你没要求时静默扔行,「搜出来就这些」和「被扔了一半」在输出上完全同形 |
给了 --max-stars 也只折叠不删除 |
超标行标 aboveMaxStars: true,--json 里照样在,人读视图会明说折叠了几条并列出前十条 |
--json 出全量候选 |
candidateList 是全部候选,shown 只是默认视图选了谁 |
这是启发式排序,不是判决。 脚本只负责把候选排到你眼前;
要不要用,仍然得打开那个 SKILL.md 读一遍。
别把排序键当成质量结论报给用户,也别把「默认视图里没有」说成「没有这样的 Skill」。
过滤参数
两个脚本共用:
| 参数 | 说明 |
|---|---|
--pages N |
翻几页(search 默认 1,treasure 默认 5) |
--limit N |
每页几条,上限 100 |
--sort stars|recent |
search 的排序参数。先读上面那条坑再决定用不用 stars |
--sort key|stars|updated|none |
treasure 的排序参数。key 是默认的启发式排序键,none 保持原顺序 |
--max-stars N |
只有 treasure 有,无默认值。不给就不过滤;给了也只折叠不删除 |
--category <slug> |
如 data-ai、devops |
--occupation <slug> |
SOC 职业,如 software-developers |
--lang <code> |
en / zh / ja 等 ISO 码;mul 混合,und 判不出 |
--json |
输出 JSON 而不是表格 |
不支持通配符(*),也不支持空查询。
配额与报错
响应头一直在报剩余量,脚本会把它打在结尾。常见错误已经翻译成人话:
INVALID_API_KEY(Key 无效)、DAILY_QUOTA_EXCEEDED(当日用完)、
MISSING_QUERY(没给关键词)、INVALID_OCCUPATION / INVALID_LANGUAGE(slug 不认识)。
搜索结果尽量不要在一次任务里反复重搜同一个词——配额是按天算的,
匿名只有 50 次。需要反复查询时用 --json 存一份到本地再过滤。
汇报纪律
把搜到的 Skill 告诉用户时:
- 说清 ★ 是仓库星数,不要让用户以为那是这个 Skill 的受欢迎程度;
- 推荐之前至少读一眼它的
githubUrl,别只凭 description 就推荐—— 描述是作者自己写的营销文案,不是验证过的能力; - 命中很少时如实说命中很少。这个索引有 1.6M 条,搜不到通常意味着词不对, 换个说法再搜一次,而不是断言「不存在」。