文档中的上下文预算具体限制什么？
Codex 会先读取一个精简的 Skill 列表，其中包含名称、描述和文件路径。OpenAI 文档说明，默认预算最多为模型上下文窗口的 2%；如果上下文窗口未知，列表最多 8,000 个字符。这两种单位不同，不要把 8,000 个字符误读成 8,000 个 token。
已安装 Skill 较多时，Codex 会先缩短描述；集合很大时，初始列表可能省略部分 Skill 并显示警告。这是发现列表的预算，并不是已安装 Skill 数量的公开上限。
已安装、可发现、被选中，是三个不同阶段
安装 Skill 是把它的文件夹放进 Codex 支持的位置。Codex 会先根据 Skill 元数据判断是否相关；选中某个 Skill 后，再读取该 Skill 完整的 SKILL.md 指令。被选中的指令会影响当前任务的上下文和行为，但不会因为文件夹存在，就自动把所有 Skill 的完整内容都加载进每次对话。
你可以通过 /skills 查看并显式选择，也可以在任务中用 $skill-name 指定。自动匹配依赖 description，因此描述应简短、具体，并把触发任务和适用边界写在前面；列表被缩短时这一点尤其重要。
| 阶段 | Codex 需要什么 | 对你的实际影响 |
|---|---|---|
| 已安装 | 支持位置中的 Skill 文件夹 | 它可供使用，但不会因此参与每一个任务。 |
| 初始列表 | 受预算限制的名称、描述和路径 | 列表很长时，职责重复或描述过长的 Skill 更难被发现。 |
| 为任务选中 | 该 Skill 的完整指令 | 当前选中 Skill 的指令会影响这次运行的上下文与行为。 |
实用起点：一到三个职责不同的角色
这是编辑建议，不是 OpenAI 限制，也不是经过对照测试得出的性能基准：先为一个经常重复的工作流选一个 Skill；只有当不同阶段确实需要不同职责时，再考虑组成两到三个的小集合。以前端任务为例，可以分别是视觉方向、设计规范检查和浏览器行为验证。
不要因为示例列出三个就把三个都装上。合适的组合取决于项目、你对来源的信任程度，以及是否有人检查产物。很少使用、和其他 Skill 职责重复，或要求超出任务需要的访问权限，都可能是暂不安装的理由。
列表出现警告，或找不到某个 Skill 时
先确认 Skill 位于 Codex 支持的位置，且名称和描述元数据有效。然后检查是否有重复职责、特别冗长的描述，或已经不再使用的 Skill。把核心触发词和任务边界写在描述开头，让描述被缩短时仍有用。
Codex 还提供 skills.max_context_tokens 配置，用于调整初始列表预算，上限为 10,000 tokens。这属于进阶选项，不代表应该保留每个包：增大预算会占用更多会话上下文；移除重复项通常能让列表更清晰。修改前请查阅当前配置文档。
一个简单的精简规则
只有当你能说明某个 Skill 对应的重复任务、它增加的独立产物，并且能审查它的来源与权限时，才把它留在组合中。先从少量开始，根据真实使用情况添加或移除，不必追求某个数量。
适合的确切数量因人而异。上下文大小、描述长度、配置、安装位置和具体任务都会影响发现与使用。官方文档说明了预算行为，但没有承诺一个普遍可靠的最大 Skill 数量或质量门槛。