Agent Skills 怎么选

安装量最高的 Skill，不一定是我下一次任务最该安装的 Skill。

我在 Codex Skills 入门里解决了“Skill 是什么、怎么写”，在进阶篇里继续拆了 references、scripts 与 evals。这一篇不再重复格式，而是回答更现实的问题：面对 skills.sh、GitHub 和本机已经出现的一长串 Skills，怎样选出值得留下的那几个？

这次我审计了 12 个候选，补了两个零依赖编码 fixture、一个动态网页 fixture、一张 100 分评分表，并逐项检查本机运行时。得到的第一条结论有点扫兴，但很有用：

Skill 目录存在
≠ 运行时已经就绪
≠ 真实任务能够完成

证据说明

产品行为以 OpenAI Build skills 与 Plugins 为准；仓库事实固定到 commit；skills.sh 安装量只按 2026-08-01 的页面快照记录。X 帖子只用来观察实践者怎样组织上下文和工作流，不支撑产品能力、star 或性能结论。

一分钟概览

1. 先用热度找候选，再用源码、依赖、许可证和 fixture 决定是否安装。
2. Skill 的 SKILL.md 可能只是入口；真正能力可能在 CLI、在线 reference、另一个命令或外部服务里。
3. “可发现、可执行、可完成”要分别验收，不能互相替代。
4. 高质量 Skill 往往边界窄、来源清楚、reference 按需读取、失败路径明确。
5. 不要批量全局安装。先固定 revision，在隔离项目完成一次真实任务。

1. 热度只解决“先看谁”

skills.sh 很适合做发现入口。核对当天，find-skills、frontend-design、grill-me、React Best Practices、agent-browser 和 web-design-guidelines 都在排行榜前列。

但安装量并不回答这些问题：

• 它是原始 Skill，还是复制品、fork 或薄包装？
• 它的宿主是 Codex、Claude Code，还是依赖某个专用 slash command？
• SKILL.md 写的是完整工作流，还是要求运行一个本机不存在的 CLI？
• reference 是固定文件，还是每次联网获取最新规则？
• 公开仓库里的这个目录到底是什么许可证？
• 它在我的项目里能否完成任务，而不是只成功显示在列表里？

一个很典型的例子是热门版 grill-me。固定到 mattpocock/skills@2ab9580 后，它的 SKILL.md 只有 7 行，正文是“运行 /grilling 会话”。如果宿主没有这个命令，单独安装它不会获得排行榜摘要里那套完整访谈流程。

热度在这里没有错，只是它回答的是：

很多人曾经安装或关注什么？

而不是：

它在我的 Codex、项目和任务里是否闭环？

2. 后台打分，正文分档

评分由七项组成：

每个分数旁边还必须有证据状态：

• 已实测：在本文固定 fixture 上完成了真实任务。
• 仅源码审计：完整看过目标目录和依赖，但没有跑任务。
• 未验证：来源、运行时或许可证仍不清楚。

这三个标签比总分更重要。一个 90 分的“仅源码审计”候选，不应压过一个 85 分但已经在你的关键任务里稳定运行的 Skill。

我仍在下载表里保留 100 分制，因为它能迫使自己逐项填写证据；正文不再把 94 和 93 写成可测量的一分差距。这里采用四档决策：优先试用、条件试用、仅作发现、暂不建议。分档回答“下一步做什么”，分数只帮助我检查有没有漏项。

以 agent-browser 为例，它在采用信号和来源上得分高，但我真正把它放进“优先试用”，是因为固定 CLI 后完成了动态页面 fixture。若只有源码审计、没有运行时验收，即使总分不变，也只能进入“条件试用”。

3. 12 个候选的结果

下表是本轮的行动建议，不是通用排行榜。100 分制的完整分项仍可下载 CSV，方便按自己的任务重新加权。

分数相近，不代表机制相同。frontend-design 是一份视觉约束；React Best Practices 是分级规则库；agent-browser 是 CLI 的发现入口。把它们都叫“提示词”会错过真正的运行边界。

4. 按任务选，比按排行榜装更稳

开发工作流

• Superpowers：适合需求仍需澄清、需要计划、TDD、评审和最终验证的中等以上改动。小改动可能被强制流程拖慢。
• skill-creator：适合把已经稳定重复的做法沉淀成新 Skill。不要用它替代对任务本身的理解。
• Supabase Postgres Best Practices：结构清楚，reference 按主题拆分。即便规则正确，SQL 与 migration 仍应在非生产数据库验证。

浏览器任务

• agent-browser：页面会重排、动态生成 id，或模型需要紧凑语义快照时优先。
• Playwright CLI：通用 E2E、调试和现有 Playwright 工程更自然，也是很好的对照基线。
• webapp-testing：已经以 Python 写浏览器测试、需要 with_server.py 管理服务时再考虑。

前端

• frontend-design 解决视觉方向。
• React Best Practices 解决性能与组件实现。
• Web Design Guidelines 解决可访问性与 UX review。

三者不是互相替代，下一篇会用同一个 Next.js 页面完整对照。

文档

办公文档 Skill 很实用，但“仓库公开”不等于“统一开源”。在 Anthropic 仓库的固定 revision 中，frontend-design、skill-creator 和 webapp-testing 是 Apache 2.0；docx、pdf、pptx、xlsx 的目录许可证则把使用约束绑定到 Anthropic 服务协议。我的选择是优先使用宿主已经提供、依赖已经配好的 document/pdf/presentations/spreadsheets 能力，而不是随手复制第三方目录。

发现与研究

find-skills 的价值是缩小搜索面。它自己的说明也要求安装前检查采用量、来源和仓库；我会再加两条：固定 Skill 路径与 revision，并跑本地 fixture。目录只能发现候选，不能替读者承担质量判断。

5. 三层验收：本机最容易暴露真相

第一层：可发现

Codex 能看到 name、description 和路径。按照 OpenAI 当前文档，初始 Skill 列表受上下文预算约束，选中后才读取完整 SKILL.md。

这一层只能证明入口存在。

第二层：可执行

依赖命令必须真的存在：

Get-Command agent-browser -ErrorAction SilentlyContinue
Get-Command playwright-cli -ErrorAction SilentlyContinue
Get-Command browser-use -ErrorAction SilentlyContinue
Get-Command tldraw -ErrorAction SilentlyContinue

实验前，本机同时出现了下面的状态：

项目固定安装 agent-browser@0.33.1 与 @playwright/cli@0.1.17 后，两者才通过 --version 和最小启动检查。

第三层：可完成

我让两套浏览器 CLI 操作同一个隔离页面：

• 每次请求都换 id 的中文表单；
• 350ms 后改变 DOM 顺序的文章列表；
• 桌面/移动截图与控制台检查。

两者最终都以 19 条命令、0 重试、0 定位失败完成。这个结果只能证明它们在本 fixture 上闭环，不能证明某个工具在所有网站更快。

6. 这几类 Skill 我不会直接安装

只有入口，没有被审计的下游

grill-me 的热门版本会转交 /grilling。如果没有继续审计这个命令，安装等于只拿到路牌。

Skill 与 CLI 版本不绑定

旧说明可能仍在教已经改名的命令。agent-browser 当前用“薄入口 + agent-browser skills get core”解决这个问题：工作流由 CLI 按版本返回。代价是 CLI 从可选依赖变成了必要依赖。

每次联网获取规则，却不保存快照

web-design-guidelines 会在每次 review 前获取最新 command.md。这对时效性有帮助，却让今天和下周的结果不可直接比较。我的最低要求是保存日期、URL、上游 commit 和 SHA256。

许可证模糊

不要用根仓库 LICENSE 猜测子目录，更不要把 source-available 写成开源。许可证不清楚时，状态应该是“未验证”，不是“先装再说”。

要求全局、静默、批量安装

-g -y 很方便，也会让所有项目共享同一份未经验证的指令。第一轮应放在项目级隔离目录；通过真实任务后，再决定是否提升为用户级能力。

7. 社区经验该怎样用

宝玉关于 Skill 与 SubAgent 上下文边界的讨论提醒我不要把“复用说明”和“隔离任务上下文”混为一谈；Kaxil 的真实 Skill 工作流展示了组合使用的价值；代码维护 Skill 案例则提供了一个很具体的复用方向。

这些内容适合提出假设：

也许这个工作流值得沉淀；
也许上下文边界会改变结果；
也许日常维护比“一次生成”更适合 Skill。

但产品机制仍回到官方文档，仓库结论回到固定源码，本机收益回到 fixture。

8. 我最后保留的安装顺序

1. 先写清真实任务和验收命令。
2. 用排行榜、GitHub 与社区内容找 3-5 个候选。
3. 审计 SKILL.md、references、scripts、CLI、网络与许可证。
4. 固定 revision，项目级安装。
5. 验证可发现、可执行、可完成。
6. 记录输出、失败和上下文读取量。
7. 更新后重新验收，长期不用就移除。

如果只想带走一个文件，可以保存这份安装前审计清单。

下一篇继续拆 Superpowers：工程纪律与一次失败实验。后两篇分别实测 agent-browser 和前端 Skill 三件套。

参考资料

• OpenAI：Build skills
• OpenAI：Plugins
• skills.sh
• obra/superpowers
• vercel-labs/agent-browser
• vercel-labs/agent-skills
• anthropics/skills
• supabase/agent-skills
• microsoft/playwright-cli