搜索 Skill 很快，决定装哪个却没有那么快。相近的名字会指向不同仓库，有的覆盖整套工作，有的只处理其中一步。把第一条结果直接装上，可能很快用起来，也可能直到执行时才发现依赖和目标不合适。
用 find-skills 时，可以把候选筛选交给 Codex，但筛选的依据要能看见。让它说明每个候选准备解决什么问题，比让它给一个没有解释的排名更有用。
先限定这次要交付什么
假设你要检查网站的表单：键盘能否完成操作、字段有没有说明、错误提示是否清楚。搜索词可以围绕界面审查和无障碍，而不用宽泛的“做网站”。
find-skills 的安装方式如下，运行前需要 Node.js 和 npm：
npx skills add https://github.com/vercel-labs/skills --skill find-skills -g -a codex -y
在终端试搜索：
npx skills find accessibility
或者直接告诉 Codex：
我需要审查这个网站的表单和键盘操作。使用 find-skills 查找候选，最多推荐三个。请逐项说明来源、任务范围、当前安装量、必要依赖和安装方式；先不要安装。
读说明，确认它会做什么
候选列表出现以后，第一件事是读 SKILL.md。简介里写“设计”，可能指生成新页面，也可能指审查已有界面；同样的关键词，操作方式差别很大。
以 Vercel 的 web-design-guidelines 为例，它的说明要求取得最新规则、读取待审查文件，再输出对应位置的发现。这个范围适合已有界面的代码审查。需要做一套全新视觉设计时，应另外核对候选是否覆盖设计与实现，不能仅凭名字带 design 就选中。
说明还可能引用其他文件、脚本或在线资料。这些部分决定它能否实际运行：本机有无需要的工具，网络能否访问规则来源，是否要求外部账号，以及会产生哪些文件改动。
安装量放在匹配之后
安装量适合用来了解一个 Skill 的使用面，仓库提交记录和 issue 可以帮助判断维护情况。数字高、更新频繁，都不意味着它一定适合你的任务。
更直接的筛选办法，是让 Codex 为每个候选写一个准备执行的第一步。如果候选声称能审查表单，第一步应该与表单文件、页面或相关规则有关。如果只能泛泛地介绍功能，就继续读说明，暂时不安装。
来源也要核实到具体仓库。相似名称可能是原项目、搬运副本或另一个实现；仓库名里的品牌词不能证明维护者身份。优先查看实际作者、README 和 Skill 文件的对应关系。
再决定安装范围
确认候选后，只装这次选中的 Skill，并指定 Codex。个人经常使用的流程可以放在用户级目录；需要项目成员共享的流程，可以考虑项目级安装。安装命令里的 -g 表示用户级，不加它时按项目范围安装。
安装完，继续执行原来的表单审查，并要求结果指向文件或可复现的页面行为。推荐理由在这一步才能被检验：它是否帮助发现了实际问题，报告是否足够具体，下一位维护者能否按结果找到对应位置。
Skills CLI 的 README列出了搜索和安装参数。候选数量可以少，判断过程需要清楚。