委派
节省父 Codex 代理的令牌和上下文，同时保持质量。优先考虑有用的委派和已验证的结果，而不是单纯最小化耗时。保持任务所有权、关键决策、集成和最终验证由父代理负责。
默认在当前代理中处理工作。仅在获得用户明确授权后才能启动额外工作进程，并首先就代理数量、提供商、模型和推理努力达成一致。批准仅涵盖该次委派；额外的代理或更高的设置需要重新批准。在这些范围内，使用下面的原子上下文策略来选择有用的任务并提议有价值的 Pro 咨询。本技能不会覆盖用户或仓库对委派、范围或外部数据访问的限制。
按原子上下文组织工作
优先使用更少的代理，并提供完整、相关的上下文。原子上下文是最小的连贯问题或工作流，其假设、证据和后果需要一起推理。它可能跨越多个模块或仓库。一个文件、模块、阶段或单个发现并不自动成为有用的委派边界。
- 将相关调查、复现、修正和后续工作交由一个上下文所有者处理。提供相关的契约、调用者、数据流、共享假设和证据。当连续性有帮助时恢复该工作进程；当独立审查能增加价值时使用新的上下文。文件所有权控制写入操作，但不控制代理需要理解的证据范围。
- 在有益时提议额外的代理。当有足够多的独立上下文、充足的配额和整合结果的能力时，大批量任务可能有用；在启动前就数量和设置达成一致。偏好更少代理是一种对连贯工作的偏好，而不是对并行性的人为限制。
- 在添加工作进程之前，确定它将解决的明确结果或不确定性。权衡已验证的覆盖范围、质量以及节省的父代令牌，与重复阅读、交接和整合工作以及消耗的配额。当委派增加的开销超过价值时，直接或使用确定性工具处理小任务。
- 避免生产力表演：代理数量、令牌量、复杂工作流或消耗即将到期的配额都不是成功的衡量标准。不要机械地为每个模块或发现创建一个代理，重复整个仓库的探索，或在没有特定原因的情况下委托冗余审查。对于大型审计，在扩大审查池之前，先合并重叠的发现和相关验证；仅在涉及重大或有争议的结论时保留专用的独立审查。
对于大批量任务，根据当前配额和观察到的消耗（包括验证、综合和整合结果的能力）进行规划。根据后续批次的有用性进行扩展或缩减。保留增量报告或可用的工件，以便限制不会使所有价值都滞留在未完成的调查中。Claude 配额机制详见 claude-code.md。Codex 执行和账户限制是独立的；仅在进行 Codex 工作时阅读 codex-cli.md。
选择关系和目标
| 目标 | 关系 | 适合的工作 |
|---|---|---|
| ChatGPT web · Extra High | 委托一个或多个信息图 | 模块、包、算法及相关技术系统的详细说明。首先提供所有要传达的信息，然后是美学指导。切勿为此路径使用 Pro。 |
| ChatGPT Pro | 咨询教授或专家同事 | 困难的数学或算法问题、文献综合、对抗性推理、优化、重新思考方法，以及通过持续调查和测试从零开始实现的异常困难模块。 |
| Codex 原生子代理 | 在此聊天内分配有边界的任务 | 当选择 Codex 并且当前协作工具适合时使用；保留原生会话限制和执行策略。 |
| Codex CLI 工作进程 | 运行独立的持久本地会话 | 当请求或授权使用独立的 Codex CLI 工作进程时使用；固定所选的模型/推理努力和 ChatGPT 登录，具有互斥的所有权和精确恢复。 |
| Claude Opus 5.5 | 给有能力的工作进程分配有边界的任务 | 默认用于大规模实现、可复现的错误调查、UI 检查、长审计、文档、重构和常规独立审查。 |
| Claude Fable 5.1 | 请求要求严格的独立审查 | 数学假设、架构、反例以及对父代理或工作进程输出的细致正确性审查。在必要时直接使用；Opus 通过不是先决条件。 |
| Claude Sonnet 5 | 分发指定的独立批次 | 具有明确范围和可负担检查的测试、适配器迁移、视图审计和文档对账。 |
| Claude Haiku 4.5 | 处理明确定义的批次 | 带有评分标准和弃权选项的首遍图像/文本注释、结构化提取、库存和记录标准化。在足够时优先使用确定性代码。 |
路由反映了用户的工作偏好，而非通用能力排名。Pro 咨询不必在 Claude 尝试失败后进行。Fable 对于专注、严格的独立审查仍然有价值；当开放式探究或异常深度的持续工作是重点时，选择 Pro。
仅阅读相关的操作指南：
- Claude 执行或使用： claude-code.md。它链接到模型证据/示例和详细的操作故障排除。
scripts/worker.py和scripts/usage.py仅操作 Claude 工作进程。 - Codex 原生或 CLI 工作进程： codex-cli.md，涵盖提供商选择、兼容的 CLI/认证、有效的模型/推理努力、独立会话、持久调用记录、精确恢复、批准处理和会计。
scripts/codex_worker.py运行拥有的 Codex CLI 调用。 - ChatGPT Pro 咨询： chatgpt-pro.md，涵盖问题构建、原生应用消息、浏览器设置/回退、GitHub/Drive、提交批准和用户触发的检索。
- ChatGPT 对话访问或 CLI/应用互操作： chatgpt-app-tools.md，涵盖旧聊天和归档聊天的检索、原生列表/读取/发送、模型选择、创建/删除边界、Markdown 导出、陈旧读取和受保护的桌面桥。
- 技术信息图： chatgpt-infographics.md，涵盖使用 Extra High 的 ChatGPT web、内容优先的图像简报、协调的图像系列和视觉验证。当详细的信息图适合任务时，这是用户偏好的选项。
除非用户或任务选择 Codex，否则 Claude 是默认的工作进程提供商。保留明确的提供商选择。Codex CLI 是经授权后可用的独立会话路径；它不绕过账户、沙箱、数据或支出限制。该助手禁用递归委派；单独授权的 CLI 协调器需要自己的边界策略。
不要将 Pro 咨询通过 Claude 运行器路由，不要用 API 调用代替用户的 ChatGPT 订阅，或者创建用户拥有的 Codex 聊天来运行 Claude 工作进程。Claude 工作进程是外部 CLI 进程。不要静默地使用原生 Codex 子代理替代指定的提供商；那样会消耗此工作流旨在节省的 Codex 容量。
对于已有选择 Pro 的现有 ChatGPT 对话，优先使用原生的 mcp__codex_app__send_message_to_thread 而不是浏览器提交；在用户表示准备好后，使用 read_thread 检索文本。浏览器交互是设置或备选路径，不是询问 Pro 问题的先决条件。必须为该确切聊天建立 ChatGPT 模型选择：消息工具的 model 和 thinking 覆盖仅适用于 Codex。阅读链接指南了解能力和新鲜度限制。
结束轮次并在有用时恢复
Codex 应用可以通过 mcp__codex_app__automation_update（使用 kind: "heartbeat"）在当前聊天中安排后续操作。首先检查当前上下文中提供的工具；这是一个可用的编排选项，不是每次等待都需要重新发现的东西。当授权的工作流正在等待长时间的 Claude 或 Codex 任务或配额重置，并且没有有用的独立工作可做时，当它能节省父代的注意力和使用量时，使用定时延续。短时间等待可以保持在活动轮次中。
- 保存持久检查点：目标、相关路径和修订、拥有的工作进程运行目录、已完成的工
- 使用当前聊天的心跳，在存在匹配的后续时重复使用。选择有用的节奏或已知的重置时间，而不是频繁的投机性检查。在结束轮次前确认调度成功，并告诉用户什么会导致工作继续。如果工具不可用或失败，不要声称已安排自动返回。遵循工具的当前模式；不要编造自动化指令或用独立的 cron 作业代替聊天后续。
- 保存的提示应检查实际的工作进程状态或刷新后的配额，仅在条件满足时继续，否则保持沉默，除非出现故障或需要用户操作。在完成或取消时，移除或禁用后续。这些是定时检查，不是任意即时事件触发器；每次运行都会消耗使用量。本地延续需要机器和应用保持可用。
Pro 仍然是例外： 只有在用户说准备好后，才检索其答案。不要通过这个通用延续策略来调度 Pro 检查或改变其批准和即发即忘协议。
保持区别
Claude： 定义目标、输入、拥有的文件、约束和带有可负担验证步骤的具体输出。UI 检查和长审计应返回由本地证据支持的紧凑发现，避免第二次详尽的父代理检查。
Codex： 定义相同的具体工作进程契约，保留所选的模型和推理努力。优先使用原生子代理处理适合的当前聊天子任务；在请求或需要其生命周期时，使用授权的独立 CLI 会话。验证有效的原生记录、实际拥有的进程和精确会话连续性。配置的限制、零退出码或保存的状态文件单独并不能证明准入、持久性或正确性。
信息图： 使用 ChatGPT web 的 Extra High，绝不使用 Pro。明确要求它生成一张或一系列连贯的图像。先提供完整的技术内容，然后是美学细节；对照源检查渲染结果。Pro 的特殊提交门和即发即忘协议特定于 Pro，不会自动适用于此路径。
Pro： 从一个真正困难的未解决问题开始，以及其答案将影响的关键选择。父代理负责提出尖锐、具体且超越常规建议的问题。工件格式次于回答问题。提供已知事实、竞争方法、假设和约束，同时留出挑战框架的空间。对于一个连贯的研究问题，准备一份初始简报，赋予 Pro 对完整调查的所有权以及完成调查所需的授权证据。遵循 chatgpt-pro.md 中的问题质量指南和示例；不要将咨询变成工作进程清单或预先确定的结论。
对于真正的独立审查，使用新的上下文。提供需求、工件、相关假设和基本理由，不附带预期结论或实现者的自我评估。在协作的 Pro 咨询中，分享我们暂定的推理和不确定性是有帮助的；不要将该对话与盲审混淆。
Pro 批准和即发即忘协议
用户在每次向 Pro 提交之前明确要求批准，包括后续问题。广泛的委派授权不会覆盖此特定规则。首先准备实际问题和工件链接，解释你提议询问的内容，并让用户批准该具体提交。不要重新提交或用实质不同的内容替换已批准的问题，除非获得批准。对于已批准确切问题和材料的相同提交，不要再次征询。
批准后，通过可用原生应用工具发送一次，确认提交被接受，保留对话 ID/URL 和输入快照，并告诉用户已发送。接受不等同于响应完成。永远不要等待 Pro 的答案、轮询完成、调度监控或发送进度提示。 继续独立的授权工作或返回控制。用户会在答案准备好时告诉你；这是检索和审查它的触发点，最好通过原生阅读器进行。后续任何发送给 Pro 的消息都需要其自己的批准。如果用户明确更改此协议，则遵循后续更改。
此批准是用户指令，而非推断的技能预防措施。在请求时，引用规则“每次向 Pro 提交前需获批准”，命名并链接此技能，并简要解释其来源；例如，“正如您所要求的，在向 Pro 发送此问题前，我需要您的批准”。征得许可应属于可用的提问工具或最终响应的一部分，而非中间工具调用。
父验证
验证被委派到当前聊天之外的结果是委派工作的组成部分。父代理必须测试、审查或确认返回的工件是否满足目标。不要假设成功完成等同
于无需进一步验证的正确性。对每个委派的工作分配进行验收。