刚开始使用 Codex 时，很容易产生一个疑问：是不是应该先把各种 Skill 全部安装一遍？
我的答案是：不需要。
Skill 的价值不在于数量，而在于它能不能把一类经常重复、容易遗漏或需要特定工具的工作，变成一条稳定的流程。装得太多，反而会让可选项变复杂，也可能让 Codex 在相似任务之间做出不必要的判断。
先理解 Skill 是什么
Skill 可以理解为一份“可复用的工作说明书”。它通常是一个目录，里面至少有一个 SKILL.md，还可以附带脚本、参考资料和模板资源。
SKILL.md 需要声明 name 和 description。其中 description 不只是给人看的简介，也是 Codex 判断“这项任务是否应该使用该 Skill”的重要依据。
Skill 和普通提示词的区别在于，它可以沉淀下来，并在不同任务中重复使用。比如“生成 PDF 时先检查字体，再渲染页面，最后做视觉复核”这样的要求，如果每次都临时说明，很容易遗漏；写进 Skill 后，就能成为稳定的工作流。
Codex 使用 Skill 时采用渐进式加载：先读取名称和描述，只有判断需要使用时，才继续读取完整的 SKILL.md。因此，Skill 更像一层按需加载的专业操作手册，而不是每次都塞进上下文的长提示词。
第一层：先用好内置 Skill
在安装任何东西之前，可以先运行 /skills 查看当前环境已经提供的能力，或者在提示词中使用 $ 选择 Skill。
很多常见能力本来就可能随 Codex 或插件提供，例如：
| 工作类型 | 优先关注的 Skill | 适合做什么 |
|---|---|---|
| OpenAI 产品与 Codex 文档 | openai-docs |
查找官方资料、核对当前行为、整理引用 |
| 文档处理 | documents |
创建、编辑和检查 Word 文档 |
pdf |
读取、生成、渲染和检查 PDF | |
| 表格 | spreadsheets |
创建、分析和验证 Excel 或 CSV 文件 |
| 演示文稿 | presentations |
创建和检查 PPT 或 Slides |
| 图片生成 | imagegen |
生成或修改位图素材 |
| 浏览器操作 | browser |
打开网页、填写表单、检查页面状态 |
| 创建自定义能力 | skill-creator |
把重复工作整理成新的 Skill |
这里的重点是“先查看，再安装”。不同的 Codex 运行环境、版本和插件集合可能不同，当前可用清单应当以 /skills 的结果为准。已经存在的内置 Skill 没有必要重复安装。
第二层：只安装真正高频的专项 Skill
如果某类工作每周都会重复，而且有明确的操作步骤，就值得安装一个专项 Skill。官方文档给出的本地安装方式是使用 $skill-installer，例如：
1 | $skill-installer linear |
安装完成后，Codex 通常会自动发现新 Skill。如果清单中没有出现，可以重启 Codex 再试一次。
可以按下面的思路选择：
经常做项目管理，再安装 Linear 一类的 Skill
如果日常工作包括创建需求、拆分任务、更新项目状态或整理迭代计划，项目管理 Skill 能把“查项目—确认上下文—创建任务—回写结果”串成固定流程。
偶尔只查一次任务时，直接描述需求通常更快；只有当这类工作反复出现，安装的收益才会超过学习和维护成本。
经常查外部资料，再安装对应的连接能力
需要持续访问 GitHub、Notion、Slack、日历或网盘时，重点往往不是一个孤立的 Skill，而是“Skill + 连接器”的组合。Skill 负责规定工作流程，连接器负责访问真实数据。
例如，代码审查流程可以规定先读取 PR 描述，再检查未解决评论，修改后运行测试，最后汇总风险；GitHub 连接器则负责真正读取仓库和 PR 内容。
经常做同一种交付物，再安装产物型 Skill
如果团队每周都要生成周报、会议纪要、技术方案或 PDF 报告，可以创建一个专属 Skill，固定标题结构、文件命名、引用规则和验收步骤。相比每次重新描述格式，这种 Skill 更容易保持一致性。
第三层：团队工作流放进仓库
个人习惯适合放在用户级目录，项目规则则应该跟着代码仓库走。官方文档建议，仓库范围的 Skill 可以放在 .agents/skills 下；这样团队成员进入同一个项目时，就能发现与该项目相关的工作流。
一个简单的目录可以这样组织：
1 | .agents/ |
例如，release-check 可以规定：
- 先读取项目的发布说明和变更范围；
- 检查测试、构建产物和版本号；
- 确认是否存在未提交的无关改动；
- 发布后检查线上状态，并记录回滚方式。
这种 Skill 的价值不在于让 Codex“更聪明”，而在于让团队少依赖口口相传的经验。新成员只要进入项目，就能获得一份可执行的发布清单。
第四层：需要共享时，考虑插件
Skill 文件适合本地创作和仓库内共享。如果希望把多个 Skill、连接器和 MCP 能力打包，供其他人或多个项目安装，插件通常是更合适的分发方式。
可以简单地这样区分：
| 需求 | 更合适的方式 |
|---|---|
| 只在当前项目使用 | 仓库中的 .agents/skills |
| 个人跨项目使用 | 用户级 Skill |
| 临时安装一个现成流程 | $skill-installer |
| 多个 Skill 一起分发 | 插件 |
| Skill 需要访问外部系统 | 插件 + 连接器或 MCP |
不要把“Skill”“插件”和“MCP”混成同一个概念。Skill 描述怎么做，插件负责打包和分发，MCP 或连接器提供访问外部系统的工具。三者组合起来，才能形成完整的自动化工作流。
一份够用的安装顺序
如果是刚开始使用 Codex，我建议按照下面的顺序准备：
- 运行
/skills，确认当前环境已有的内置能力； - 保留
skill-creator，把自己的重复工作沉淀下来； - 只有在确实高频时，使用
$skill-installer安装专项 Skill； - 对团队项目，把发布、测试、文档或审查规范放进仓库的
.agents/skills； - 需要跨项目和跨团队分发时，再把相关能力整理成插件。
这套顺序有一个好处：先解决真实问题，再决定是否需要增加系统复杂度。一个能稳定完成工作的 Skill，比十个从来没有真正触发过的 Skill 更有价值。
写 Skill 时，最重要的是 description
很多 Skill 不是不能用，而是无法在正确的时机被发现。一个好的 description 应该明确三件事：它解决什么问题、什么时候应该触发、什么时候不应该触发。
例如，下面的描述就比“帮助处理发布”更具体：
1 |
|
Skill 本身也应该保持专一。一个 Skill 同时负责写代码、做设计、发邮件和更新项目状态，看起来很强大，实际上很难稳定触发，也很难测试。把大流程拆成几个边界清楚的小 Skill，通常更容易维护。
安装前后都要注意安全
Skill 可以附带脚本，也可能调用外部工具。安装来自其他仓库的 Skill 时，至少要看清楚以下内容：
- 它会读取哪些文件；
- 是否会执行本地脚本或安装依赖；
- 是否会访问外部网络；
- 是否需要 GitHub、云平台或其他系统的写权限；
- 生成或修改文件后，是否有可复核的结果。
尤其不要因为 Skill 的说明写得很完整，就默认它值得信任。Skill 是工作流说明和工具调用的入口，权限边界仍然需要由使用者确认。
我的结论：安装最少，但沉淀最好
Codex 真正需要的，不是一张“所有人都必须安装”的 Skill 清单，而是一套与自己工作方式匹配的能力组合。
对个人开发者，先用内置 Skill，再补一个项目管理或文档类专项能力，通常已经足够。对团队，最值得投入的是把发布检查、代码评审、测试验收和文档规范写成仓库 Skill。对需要广泛复用的组织，再进一步使用插件完成打包和分发。
Skill 的终点不是“安装成功”，而是让一个任务能够被稳定触发、按明确步骤执行，并在最后留下可以检查的结果。能做到这一点，才算真正把经验变成了能力。