图 1：白底动效图。候选只有依次通过来源、许可证、运行时、副作用和任务验收，才进入安装决策；任一门禁失败都应回到“未验证”或“暂不建议”。
社区内容仍然有用，但只放在第一步。我会从 宝玉关于 Skill 与 SubAgent 上下文边界的讨论、Kaxil 的 Skill 工作流或代码维护 Skill 案例里发现“可能值得复用的工作流”，然后回到官方文档、固定源码和本地任务验证。社区经验负责提出假设，不负责替我下结论。
2. 五道门禁：不过门禁，不进入推荐
我现在不再一上来给 Skill 打 100 分，而是先做五项硬检查。这个顺序比权重更重要，因为有些问题不能靠其他高分抵消。
门禁一：能不能追到原始来源
至少记录四个字段：
只保存 skills.sh 页面不够。目录里可能是 fork、复制品，也可能只是指向另一个命令的薄入口。仓库首页同样不够，因为 main 会继续变化；文章中的事实应该能追到具体 commit 下的具体文件。
如果我无法判断谁维护它，或者只能找到二次转载，状态直接记为“来源未验证”。
门禁二：具体目录能不能合法使用
公开可读不等于开源，根目录的 LICENSE 也不一定覆盖每个 Skill 子目录。
这次检查 Anthropic Skills 固定 revision 时，frontend-design、skill-creator 和 webapp-testing 使用 Apache 2.0；docx、pdf、pptx、xlsx 目录则附有另一套使用条款。这个差异会直接改变我的行动：前者可以继续评估项目级使用，办公文档套件则优先使用宿主已经提供并配好依赖的能力，不随手复制目录。
许可证不清楚时，正确状态是“未验证”，不是“先装再说”。
门禁三：Skill 文件之外还依赖什么
我把依赖拆成四层：
例如 agent-browser 的核心能力不在那一个 SKILL.md 里，而在配套 CLI 和浏览器运行时；办公文档 Skill 可能依赖 LibreOffice、Pandoc、Python 或 Node 库；数据库 Skill 的文本可以读取，但最终 SQL 仍需要一个安全的数据库环境验证。
最小检查可以从这些命令开始：
没有输出不是小问题，它说明“Skill 可发现”和“运行时可执行”已经脱节。
门禁四：它会改变什么状态
阅读 SKILL.md 时，我会专门找这些词和行为：
-
全局安装、 -g、-y； -
网络请求、在线 reference、远程脚本； -
登录态、浏览器 profile、cookie、session； -
Git worktree、hooks、提交与分支操作； -
数据库 migration、生产数据、外部消息； -
遥测、日志、截图和临时文件。
副作用并不等于不能使用。真正的问题是：它有没有被写清楚，能不能限制在项目目录、测试账号、非生产数据和最小权限里。
门禁五：有没有一个可判定的真实任务
“成功安装”不是验收标准。第一次试用前，我会先写一张最小任务卡：
一个好 fixture 不需要大，但必须有明确输入、正确输出和失败信号。没有这张任务卡，“感觉它好像帮到了我”很难和真实收益区分。
3. 完整案例一：为什么 agent-browser 通过了
agent-browser 是这批候选里最能说明“三层验收”的例子。
3.1 热度只能把它送进候选池
2026-08-01 的 skills.sh 快照记录约 57.9 万次安装。这个数字让我愿意先看它，但没有进入推荐结论。
我真正审计的是 vercel-labs/agent-browser 固定 commit 下的 SKILL.md。这个 Skill 是一个很薄的发现入口：它要求通过 CLI 获取与当前版本匹配的核心工作流。换句话说，CLI 不是锦上添花，而是能力的一部分。
这一步得到的不是“值得安装”，而是一个依赖结论：
3.2 本机先暴露了运行时脱节
实验前，本机已经能找到 agent-browser Skill 目录，但 PATH 里没有对应命令。此时它只能被 Codex 发现，不能执行实际网页操作。
我没有直接做全局安装，而是在实验包中固定项目依赖：
然后用不会临时下载新版本的命令检查：
本机返回：
到这里仍然只证明运行时存在，还没有证明真实任务能完成。
3.3 用同一份 fixture 做任务验收
两套 CLI 使用相同输入，完成三项任务：
-
在每次请求都会更换 id 的中文表单中填写“林檎 / 人工智能”； -
等待文章列表在 350ms 后改变 DOM 顺序，再搜索并打开指定文章； -
在 1440×900 和 390×844 下截图并检查控制台。
约束也固定：每次页面变化后重新获取语义快照，不使用运行时生成的 id，失败最多重试一次，不能临时切换工具。
运行命令是：
单次记录如下：
这里必须把边界说清楚：只有一次运行，所以 31.575 秒和 6.051 秒不能推出普遍性能差距；输出字节更少也不能自动等于更省模型上下文。但两者都在固定 fixture 上完成了任务，这足以证明本轮“可完成”。
3.4 最终决定
agent-browser 进入“优先试用”，但决定不是“全局安装最新版”，而是：
-
Skill 和固定版本 CLI 一起使用； -
先放在项目级依赖； -
登录网站前确认 session、profile 和凭据保存位置； -
CLI 或 Skill 更新后重新跑 fixture； -
需要通用 E2E 和现有 Playwright 工程时，仍保留 Playwright 作为基线。
这就是“通过”的实际含义：不是证明它在所有网页上最好，而是证明它在我的版本、环境和任务里完成了一次闭环。
4. 完整案例二：为什么 grill-me 没通过
grill-me 是反过来的例子：热度很高，源码也很短，但短不等于边界清晰。
固定到 mattpocock/skills@2ab9580 的目标文件 后，可以看到它只有 7 行，真正的动作是：
“Run a
/grillingsession.”
翻译成中文就是：启动一次 /grilling 会话。
这句话本身没有错，但它暴露了审计关键点：当前文件不是完整访谈工作流，而是一块路牌。真正需要继续追踪的是：
/grilling
在哪个宿主里注册； -
安装 grill-me时是否同时安装这个命令； -
Codex 当前环境能否调用它； -
下游命令的 Prompt、依赖、副作用和许可证是什么； -
命令不存在时有没有降级路径。
本轮没有找到能让这条链路在当前 Codex 环境闭环的配套命令，因此它在“运行时依赖”门禁失败。我的决定是“暂不建议单独安装”，而不是评价访谈方法本身没有价值。
这个案例给我的实用提醒是：
以后看到“调用另一个 slash command”“运行某个脚本”“获取远程规则”时，我都会继续沿依赖链审计，直到找到真正执行工作的那一层。
5. 完整案例三：为什么 React Best Practices 只能条件试用
第三种情况既不是通过，也不是失败，而是证据还不够。
Vercel React Best Practices 固定 revision 的结构明显比薄包装完整：
它把规则按 waterfalls、bundle、server、client、rerender、rendering、JavaScript 和 advanced 分类，并给规则标注影响等级。这个结构适合按问题读取具体 reference，而不是把整套知识一次塞进上下文。
但结构优秀不等于已经证明效果。本轮只完成了源码审计，没有为它单独运行多组 React 性能任务，因此我不会把它写成“已实测推荐”。
我的使用边界是：
-
先判断页面有没有请求瀑布、客户端状态、重包、长列表或重复渲染； -
只读取相关类别和规则文件； -
每个 finding 必须绑定真实代码和机制； -
没有性能问题时，允许输出“不需要修改”； -
不默认加载 112 KB 的完整 AGENTS.md； -
在独立 Next.js fixture 上通过构建、行为和性能验收后，再升级为长期保留。
因此它进入“条件试用”。这个标签不是保守话术，而是在告诉读者：源码质量已经给出正面信号，任务收益仍然缺证据。
6. 三层验收：安装完成后还要检查什么
通过五道安装门禁后，我会在本机再做三层验收。它们回答的是三个不同问题，不能互相替代。
图 2：白底动效图。目录和 description 只让 Codex 找到入口；CLI、浏览器或解释器让工作流能够启动；只有 fixture 的断言通过，才算当前任务闭环。
第一层：可发现
按照 2026-08-10 核对的 OpenAI 文档，Codex 初始只需要 Skill 的名称、描述和路径来做发现，匹配后才读取完整 SKILL.md；初始 Skill 列表还受上下文预算限制，文档给出的上限是上下文窗口的 2%，并以 8,000 字符作为回退值。
这一层要检查：
-
Skill 是否放在 Codex 会扫描的目录； name
和 description是否能说明何时使用；-
新任务中能否通过 /skills或$skill-name明确触发； -
隐式任务是否会误触发或漏触发。
目录存在只能证明入口可能被扫描，不能证明内部命令能跑。
第二层：可执行
这一层检查 Skill 要求的工具是否真的存在，并固定版本：
如果依赖只存在于项目 node_modules，就用项目命令调用，不要因为 PATH 没有全局版本又安装一份最新版。最小启动还应该验证浏览器、解释器、端口和外部凭据，而不只是 --version。
第三层：可完成
最后才运行真实任务，并保存：
-
固定输入和 Prompt； -
工具与 Skill revision； -
命令数、重试、失败和耗时； -
产物、截图或代码 diff； -
验收命令与退出码； -
没有覆盖到的场景。
如果 Agent 中途换了另一套工具才完成，不能把成功归因给当前 Skill；如果只有截图、没有状态断言，也不能证明任务正确。
7. 12 个候选重新分档后的结果
下表不是通用排行榜，而是这次审计的行动记录。安装量只决定候选顺序，不进入最终结论；“已实测”和“仅源码审计”分开显示。
完整记录可以下载为 CSV。表里保留了对象类型、revision、许可证、依赖、副作用、本地状态和证据等级，读者可以直接复制后替换成自己的候选。
这里还需要区分两个名字：本文的 find-skills 指 Vercel 仓库中的候选；我本机另有一个名为 find-skill 的社区 Skill。它们不是同一个来源，也不能因为功能相似就共用审计结论。
8. 30 分钟完成一次安装前审计
如果只想把方法用到下一个 Skill，可以按下面的节奏执行。
0–5 分钟：先写任务，不要先安装
写清一个真实任务、输入和验收命令。例如：
没有真实任务，就无法判断 Skill 带来的是帮助还是额外流程。
5–10 分钟：追到原始文件
记录仓库、Skill 路径、commit、许可证和核对日期。再回答：
-
是维护者原始目录还是 fork？ SKILL.md
是完整工作流还是入口？ -
是否引用 references、scripts、在线 URL 或另一个命令？
10–20 分钟：检查边界和副作用
完整读取 SKILL.md，只沿它明确要求的路由继续读 reference。特别检查：
-
触发条件和不适用场景； -
输入、输出和停止条件； -
强制措辞与不可跳过流程； -
CLI、浏览器、Python、Node、系统程序； -
网络、凭据、会话、遥测和全局安装； -
写文件、Git、数据库和外部系统副作用。
20–25 分钟：固定版本并做最小启动
优先使用项目级安装。版本检查、--help、浏览器启动和最小输入都成功后，才标记“可执行”。不要在这一步接触生产账号和真实数据。
25–30 分钟：运行 fixture 并作出四档决定
只允许四种结果：
如果想保存一份更完整的检查项，可以下载安装前审计清单。
9. 哪些情况下根本不需要安装
不是每个好 Prompt 都需要变成长期 Skill。以下情况我通常直接停在发现阶段：
一次性任务，没有重复价值
如果指令只会使用一次，直接写进当前任务通常更便宜。Skill 会增加发现描述、版本、维护和误触发成本。
宿主已经提供同类能力
本机已经有 document、pdf、presentations、spreadsheets 或 skill-creator 等能力时，先确认宿主版本是否已经包含运行依赖和权限边界。重复安装同名社区版本，反而会让触发来源变得不清楚。
下游依赖无法追踪
只要出现“调用另一个命令”，却无法找到命令定义、安装方式和版本，就先停下。安装一个路牌不会获得目的地。
第一次试用就要求全局、静默、批量安装
-g -y 很方便，也会把未经验证的指令暴露给所有项目。第一轮应放在隔离项目，通过任务验收后再决定是否提升到用户级。
只能在生产数据上验证
数据库 migration、外部消息、真实账号和不可逆操作，不适合作为第一次 Skill 验收。先构造非生产 fixture，或者把状态保持为“未验证”。
10. 我最终保留的方法
这次审计后，我不会再问“这个 Skill 火不火”，而是按下面的顺序问：
热门、已安装和真正可用不是同一件事。热度把候选送到桌面，源码审计解释它会做什么，运行时检查证明它能启动，fixture 才证明它在当前任务里完成闭环。
系列下一篇继续拆 Superpowers：给 Codex 加上工程纪律，然后是 agent-browser 的语义快照实测和前端 Skill 三件套。关于 Skill 的目录、渐进式加载和 eval，可以回到 Codex Skills 入门与进阶篇。
参考资料
-
OpenAI：Build Skills -
OpenAI：Plugins -
skills.sh -
obra/superpowers@44c9b2d -
vercel-labs/agent-browser@da1237e -
vercel-labs/agent-skills@7c180d9 -
anthropics/skills@b29e7cf -
supabase/agent-skills@1207767 -
microsoft/playwright-cli@eee5a18
订阅智宅客
AI / 技术 / 数字生活方式，新文章第一时间送到邮箱。
