Skill 是一套可复用的工作流程说明。

它解决的问题是：

有些任务你已经摸索出稳定做法了，不想每次重新写一大段提示词。

比如：

• 修 Bug 的标准流程。
• 发布前检查的标准流程。
• 做代码审查的标准流程。
• 排查构建失败的标准流程。

这些都适合沉淀成 Skill。

场景举例

你每次让 Codex 修 Bug，都会重复提醒：

先复现问题，不要直接改。

先判断影响范围。

只做最小修复。

改完后让 Codex 自己运行已有检查。

最后用中文汇报改了哪些文件、检查结果和风险。

如果每次都复制这段，很累，也容易漏。

Skill 可以把这套流程保存起来。

以后你只要说：

用 Bug 修复流程处理这个问题：登录页手机号输入 11 位后按钮仍然不可点击。

或者显式指定某个 Skill：

$bugfix-flow 修复登录页手机号校验问题。

Codex 就能按照那套流程工作。

Skill 和提示词的区别

| 项目 | 适合什么 |

| :--- | :--- |

| 当前提示词 | 这一次任务的目标、范围、验收 |

| Skill | 一类任务的固定流程 |

比如：

当前提示词：

这次只修登录页，不要改注册页。

Skill：

修 Bug 时先复现，再定位，再最小修复，再验证，再汇报。

一个是当前任务限制，一个是长期流程。

Skill 和 AGENTS.md 的区别

| 项目 | 适合什么 |

| :--- | :--- |

| AGENTS.md | 当前项目的规则 |

| Skill | 某类任务的流程 |

本项目使用 npm run build 做构建检查。

教程文案使用简体中文。

不要修改 dist 目录。

Skill 适合写：

如果这个流程跨多个项目都能用，更适合 Skill。

Skill 和 MCP 的区别

| 项目 | 作用 |

| :--- | :--- |

| MCP | 给 Codex 外部工具和资料 |

| Skill | 告诉 Codex 怎么按流程做事 |

比如：

• MCP 能查询 GitHub issue。
• Skill 规定“修 Bug 前先读 issue、总结复现步骤、确认影响范围”。

MCP 是能力，Skill 是流程。它们可以配合，但不是同一个东西。

Skill 的物理结构

一个 Skill 通常是一个目录。

目录里至少有：

SKILL.md

也可以有：

references/

scripts/

assets/

最小结构：

bugfix-flow/

SKILL.md

name: bugfix-flow

description: 修复 Bug 时使用。适合用户提供现象、复现步骤、错误日志或失败截图，并要求 Codex 做最小修复和验证。

Bug 修复流程

这里写 Codex 应该遵守的流程。

name 和 description 为什么重要

Codex 不会一开始把所有 Skill 的完整内容都塞进上下文。

它会先看到每个 Skill 的：

• 名称。
• 描述。
• 文件路径。

帮助写代码。

太泛了。更好的写法：

修复 Bug 时使用。适合用户提供现象、复现步骤、错误日志或失败截图，并要求 Codex 做最小修复、运行项目已有检查、用中文汇报风险。

这样 Codex 才知道什么时候该用。

触发方式

常见有两种：

| 方式 | 说明 |

| :--- | :--- |

| 显式触发 | 用户在提示词里点名或用 $skill-name |

| 隐式触发 | Codex 根据 description 判断当前任务适合某个 Skill |

新手建议先显式触发。比如：

$bugfix-flow 修复登录页手机号校验问题。

等你确定 Skill 描述写得足够准确，再依赖隐式触发。

什么时候适合做成 Skill

适合：

• 高频出现。
• 步骤稳定。
• 验收标准明确。
• 能跨多个任务复用。
• 不依赖当前一次任务的临时细节。

比如：

| 任务类型 | 是否适合 Skill |

| :--- | :--- |

| 修 Bug 标准流程 | 适合 |

| 发布前检查流程 | 适合 |

| 代码审查流程 | 适合 |

| 只把一个按钮改成蓝色 | 不适合 |

| 当前页面的临时文案要求 | 不适合 |

总结

读完后你应该能说清楚：