一个开发者让 Codex 找到合适的 Skill，另一个开发者却无法复现同样的流程，常见原因是安装范围、文件版本和依赖没有一起交代。个人觉得好用的方法，进入团队项目后，需要留下足够信息让别人继续使用。
find-skills 负责帮助挑候选。团队采用哪个版本、放在哪里、如何验证，应该在选定以后写进项目约定。
先以一个真实任务筛选
给 Codex 的搜索要求可以是：
为这个项目的代码审查寻找 Skill。先阅读项目规范和已有能力，再用 find-skills 搜索候选。说明任务范围、来源、依赖和与现有流程的重合部分。先推荐，不安装；最后给出适合团队共享的采用方式。
先用具体任务试候选，更容易看清它是否符合团队的输出习惯。例如，报告是否指出文件位置，能否区分必须修复的问题和可选建议，是否依赖团队没有接入的服务。
搜索入口可安装到个人环境，需有 Node.js 和 npm：
npx skills add https://github.com/vercel-labs/skills --skill find-skills -g -a codex -y
共享时说明安装范围
用户级安装方便个人跨项目使用，命令中的 -g 表示这个范围。项目级安装则适合把与当前仓库有关的工作方法放在项目里；安装时不要带 -g，并指定目标 Agent。
项目采用第三方 Skill 后，记录来源仓库、具体 Skill 名称、采用时对应的提交或文件校验值，以及必要依赖。如果把文件提交进项目，还应保留适用的许可与来源信息。
这份记录能解释“现在用的是什么”。只有一条指向默认分支的安装命令，后来执行时可能拿到不同内容；重现过去的行为，就需要能对上当时的文件。
不让个人配置进入共享资料
Skill 说明、公共规则和项目流程可以共享，个人密钥、服务账号与本机绝对路径需要另外处理。团队成员的电脑环境不一样，固定到某个人用户目录的脚本，在另一台电脑上可能无法执行。
让 Codex 阅读引用脚本时，顺便检查这些路径与依赖。不要只看 SKILL.md 的入口简介；真正执行的脚本可能在另一个目录。
同名 Skill 也要留意。项目和用户目录里都存在时，Codex 官方文档说明它们不会被自动合并。因此不能期待个人补充的一段规则自动进入团队版本。需要共同使用的要求，应该维护在明确的项目文件里。
更新也用一次任务验证
采用新版本前，先查看说明和脚本变化，再用同一份小任务比较输出。检查它是否仍能完成原来的工作、是否新增依赖，以及是否改变了写文件或外部操作的范围。
验证通过以后，再更新共享记录。若输出退化或无法运行，可以保留原文件继续使用，把问题和相关版本记下来。团队不必追着每次更新走，当前版本能否完成当前任务更重要。
项目中的技能发现与同名处理方式可查看 Codex 官方文档，安装范围与源地址写法可查看 Skills CLI README。