用 Codex 干活的人多少都遇到过这种事，同一个要求，你已经在对话里说过第五遍了。
提交前先跑一遍测试再写 commit message、这个项目的日志统一用结构化格式、改完接口记得同步更新 OpenAPI 文档。
每开一个新会话，它就跟没记住一样，你又得从头交代一遍，说一次两次还行，说到第十次，你会开始怀疑到底是谁在给谁打工。
这时候需要的不是把话说得更重，在 prompt 里写十遍 MANDATORY 也没用，而是把这件事从「每次口头交代」变成「一次性固化下来」。
Codex 的 Skill 就是干这个的。
Skill 到底是什么
Skill 是一个可复用的工作流封装，把一套固定的做事步骤写进一个文件，Codex 需要的时候自己去读、自己照着做。
它遵循的是一个叫 open agent skills 的开放标准，Claude Code 那套 Skill 用的也是同一套规范，所以概念是通的。
结构极简，就是一个文件夹加一个 SKILL.md：
my-skill/
├── SKILL.md # 必需：说明 + 元数据
├── scripts/ # 可选：可执行脚本
├── references/ # 可选：参考文档
└── assets/ # 可选：模板、资源
SKILL.md 里必须有两样东西：name（名字）和 description（描述）。最小的一个 Skill 长这样：
name: commit-checklist
description: 提交代码前的固定流程。当用户要提交、commit、准备 PR 时触发。
提交前按顺序执行：
1. 跑一遍测试套件，确认全绿
2. 检查有没有漏掉的 console.log 或调试代码
3. commit message 用祈使句，第一行不超过 50 字符
就这么简单！
把反复交代的那件事，写成几条祈使句，存下来，以后它自己会照着做。
它省的不只是打字，是上下文
你可能会想，这跟我把要求写进 AGENTS.md 有啥区别？
区别在**加载方式，**Codex 用的是一个叫 progressive disclosure（渐进式披露）的机制，一开始它只把每个 Skill 的名字、描述和文件路径读进上下文，并不读全文。
只有当它判断这次任务用得上某个 Skill，才会去读那个 Skill 的完整内容。
这个设计很关键。装一堆 Skill，平时它们几乎不占上下文，初始清单最多只吃掉模型上下文窗口的 2%，真正的详细步骤，只在用到的那一刻才加载进来。
说白了，AGENTS.md 是不管用不用都塞进去的全局说明，Skill 是按需取用的工具箱。
要固化的规矩越多，这个差别越明显。
三种方式把一个 Skill 造出来
Codex 给了三条路，从最省事到最可控排列。
第一种，演示给它看（Record & Replay）。 如果这套流程你自己门儿清、说起来费劲但做起来简单，直接操作一遍，Codex 会把你的步骤录下来、拆解出来，自动帮你起草一个 Skill。适合那种「我讲不清但我能做给你看」的活儿。
第二种，让它问你（$skill-creator）。 在 Codex 里输入 $skill-creator，它会问你这个 Skill 是干嘛的、什么时候该触发、要不要带脚本。你一句句回答，它帮你生成，默认是纯指令型（instruction-only），不带脚本，这也是官方推荐的默认选择。
第三种，手动写。 就是自己建个文件夹、写个 SKILL.md，跟前面那个例子一样，最直接，也最适合你已经想清楚要写什么的时候。
改完 Skill 不用重启，Codex 会自动检测变化，万一没生效，重启一下就行。
放哪儿它才找得到
Skill 有几个作用域，放的位置决定了谁能用到：
项目级放在 .agents/skills/。Codex 会从启动的当前目录一路往上扫到 Git 仓库根目录，团队协作的规矩就该放这——check 进仓库，所有人拉下来都能用。
用户级放在 $HOME/.agents/skills/。这是个人的，不管在哪个项目都跟着你走，像「commit message 风格」这种自己的习惯，放这里最合适。
还有机器级（/etc/codex/skills）和系统级（Codex 自带的，比如 skill-creator 本身就是内置的）。
同名 Skill 不会被合并，两个都会出现在选择器里，所以命名别撞。
怎么触发
装好之后，Codex 有两种方式用上它。
一种是显式调用：在 prompt 里直接点名，或者输入 $ 加 Skill 名，或者用 /skills 命令挑一个。想让它这次一定按某个流程走，就显式喊。
另一种是隐式调用：你不用管，Codex 看这次的任务跟哪个 Skill 的 description 对得上，自己就选了。
正因为隐式匹配全靠 description，写描述这件事就变得很重要。
description 要把「什么时候该用、什么时候不该用」讲清楚，关键的使用场景和触发词往前放。
因为 Skill 装多了，Codex 会先把描述缩短来省空间，把重点词前置，缩短之后它还能匹配得上。
几条写 Skill 的经验
官方给的最佳实践就几条，但都戳在点子上： 一个 Skill 只干一件事，别想着写个「万能助手」把十件事塞进去，那样触发匹配会很乱。 能用文字说清就别写脚本，只有当你需要确定性的行为、或者要调外部工具时，才上脚本。纯指令是默认选择。 步骤写成祈使句，输入输出都写明白。别写「可以考虑检查一下」，写「执行 X，得到 Y」。 写完拿几个真实 prompt 去测一下触发行为，确认它该触发的时候触发、不该触发的时候别乱触发。
写在最后
Skill 这东西的价值，不在于它有多高级，而在于它把你脑子里那些「每次都要交代一遍」的隐性规矩，变成了 Codex 能稳定复现的显性流程。 如果你是个人开发者，从最烦的那件事开始：把你这周对 Codex 重复次数最多的那个要求，写成一个用户级 Skill，十分钟的事，立刻回本。 如果你在团队里，把团队约定（提交规范、日志格式、接口文档同步）沉淀成项目级 Skill check 进仓库，比在群里贴一百遍规范管用，新人拉下代码就自动带着这套规矩干活。 判断标准很简单：一件事你教了 Codex 三遍以上，就别再教第四遍了，写成 Skill。
参考来源
- Codex Skills 官方文档：https://developers.openai.com/codex/skills
- open agent skills 标准：https://agentskills.io