Delegate To Chatgpt Pro

委派给 ChatGPT Pro

把 ChatGPT Pro 当作不可信但能力较强的外部高级工程师，把 Codex 当作唯一总负责人。外部结论、代码和“测试通过”声明都必须由 Codex 根据本地事实复核。

最简调用

用户只需选择本 Skill，然后直接描述想完成的需求，例如：

$delegate-to-chatgpt-pro 修复支付回调偶发重复入账的问题。

不要要求用户另外填写背景、任务模板或验收标准。Codex 必须先检查仓库和现有实现，自行补全工程背景、修改范围、约束、测试方案和可执行验收标准。只有登录验证、权限扩大、数据边界不明确或会改变产品方向的重大决策才询问用户。

默认浏览器固定为 Codex 内置浏览器 @Browser。用户无需在每次调用时重复说明，也不要因为 chatgpt.com 在 Chrome 中已有登录态就自动切换浏览器。

不可突破的边界

• 仅在用户明确要求使用网页版 ChatGPT Pro 时启动外部协作。
• 用户显式调用本 Skill，即授权 Codex 向当前登录的 ChatGPT Pro 发送完成任务所需的最小、已脱敏、非敏感代码上下文；无需为普通源码再次请求确认。若内容涉及商业敏感信息、个人数据、许可证限制或无法判断的授权边界，上传前说明目标网站、文件和数据范围并请求确认。
• 永不上传 .env、密钥、令牌、Cookie、私钥、数据库、用户数据、浏览器状态或其他凭据。即使仓库已经跟踪这些文件，也必须排除。
• 除非用户在本次请求中明确指定 Chrome，否则必须使用 Codex 内置浏览器 @Browser；不得使用按 URL 自动选择浏览器的入口，也不得静默切换到默认 Chrome。
• 不扩大用户权限。提交、推送、创建 PR、部署、迁移数据库和操作真实数据都需要本次请求中的明确授权。
• 不要求用户提供密码、Cookie、验证码、恢复码或 Passkey。出现登录、账号选择、验证码、两步验证或安全检查时暂停，把浏览器页面留给用户处理。
• 不以模型自报身份判断后端模型。记录界面中实际选择的模式即可。
• 不把 ChatGPT Pro 的模拟、推断或声称执行过的命令当成真实验收。

工作流

1. 建立本地事实

1. 读取适用的 AGENTS.md、CLAUDE.md、README、依赖清单和架构文档。
2. 检查当前分支、HEAD、Git 状态、未提交改动和必跑门禁。
3. 若仓库托管在 GitHub，使用 GitHub 连接器或 gh 只读解析当前分支对应的 PR，记录 canonical PR URL、base、远端 head OID、状态和检查结果；不要仅根据分支名拼接 URL。
4. 保留用户现有改动；不要为获得“干净基线”而重置或覆盖文件。
5. 根据用户的自然语言需求和仓库事实，自行整理目标、不可破坏的边界、交付物、测试方案和可执行验收标准。
6. 判断外部协作是否值得。简单、局部、可直接验证的任务由 Codex 完成，并说明使用 Pro 的额外收益有限。

2. 设计委派边界

• 默认只创建一个 Pro 对话。
• 只有任务能拆成相互独立的复杂工作流且并行收益明显时才创建多个对话，通常不超过三个。
• 每个对话只负责一个清晰结果，例如根因分析、迁移方案或独立安全审查；不要让多个对话同时修改相同文件。
• Codex 保留集成、冲突处理、最终实现选择和验收责任。

3. 选择最小上下文通道

GitHub PR 审查优先发送 canonical PR URL，不默认打包仓库。只有同时满足以下条件，才把 PR 链接视为完整审查上下文：

• 任务是审查已有 PR，而不是让 Pro 修改尚未发布的本地代码；
• 已只读确认 PR 的远端 head OID；
• 本地工作树干净，且本地审查目标 HEAD 与 PR head OID 完全一致；
• PR 页面能展示目标 base、完整 diff 和必要的检查结果。

发送时同时写明 PR URL、base、head OID 和审查目标，并要求 Pro 先确认它实际读取到了 PR 文件列表与 diff。不能访问私有 PR、只能看到登录页、读取到旧版本或无法确认 head OID 时，立即停止基于链接推断，改用最小脱敏源码包。

本地 HEAD 比 PR head 更新或工作树有未提交改动时，PR 链接只能作为基线。不得自动提交或推送来“补齐”PR，也不得声称 PR 包含本地差异。若用户要求审查当前本地状态，在发送 PR 链接的同时，附上只包含缺失提交或改动所涉及文件的最小脱敏源码包，并明确列出：

• PR head OID；
• 本地 HEAD 与 dirty 状态；
• PR 未覆盖的提交范围或工作树差异；
• 附件是完整目标文件还是补充差异。

没有可用 PR、PR 无法访问、任务需要未发布源码，或 Pro 必须产出补丁时，优先只发送任务所需文件，不发送整个仓库。运行：

python3 <skill-dir>/scripts/prepare_source_bundle.py \
  --repo /absolute/path/to/repo \
  --include path/to/relevant/module \
  --include AGENTS.md \
  --include README.md

--include 可重复使用；需要进一步缩小时使用可重复的 --exclude。

必须至少提供一个 --include。只有用户明确授权发送整个 Git 可见工作树时，才改用显式 --all；--all 与 --include 不能同时使用。PR 已覆盖的文件无需在附件中重复发送，除非 Pro 无法访问 PR 或本地版本不同。

脚本必须成功完成密钥扫描后才能上传。扫描只是一层高置信度防护，不能代替 Codex 对文件清单、业务数据和自定义凭据格式的人工审查。记录其 JSON 输出中的：

• head_commit
• dirty
• archive
• archive_bytes
• sha256
• file_count

脚本因疑似密钥阻断时，不得绕过扫描。排除命中文件或改为发送更小的文本片段，然后重新生成。

4. 只使用 Codex 内置浏览器打开 ChatGPT

1. 默认必须显式调用 @Browser 对应的 Codex 内置浏览器。不要使用按 URL 自动选择浏览器的入口，不要使用系统默认浏览器，也不要打开 Chrome；工具支持显式绑定时选择 iab，不要调用 getForUrl(chatgpt.com) 一类自动路由逻辑。
2. 优先接管并复用内置浏览器中已打开的 chatgpt.com 标签页；没有可用标签页时，才在内置浏览器中新建标签页。
3. 只有用户在本次请求中明确说“使用 Chrome”“使用 @Chrome”或“使用我的 Chrome 登录态”时，才允许改用 Chrome。若内置浏览器不可用，告知用户并暂停，不得静默回退到 Chrome。
4. 内置浏览器使用独立浏览器资料，不应假设用户日常 Chrome 的登录状态会自动共享。
5. 确认当前页面是 chatgpt.com，且界面显示用户期望的 Pro 模式。
6. 若未登录或出现身份验证，暂停并让用户亲自完成。
7. 若内置浏览器不能自动上传文件，保留已生成的压缩包并请用户在该页面手动上传；不要切换浏览器或采用不安全的绕过方式。
8. 保存每个对话的可恢复链接。

5. 向 Pro 发任务

联系 Pro 前完整读取 task-brief.md，由 Codex 根据任务选择首次委派或 GitHub PR 审查模板，自行填写并发送任务说明、PR 链接和必要附件。不要把空白模板交给用户补充。

说明必须包括：

• 背景、目标和为什么现在修改；
• 当前架构、版本、HEAD 和不可破坏边界；
• 明确修改范围与排除范围；
• 交付物和验收标准；
• 必须考虑的测试；
• Pro 无法访问的本地或私有环境；
• 禁止声称已经执行的操作。

实现任务要求优先返回最小完整补丁、修改理由、测试建议、假设和未验证风险。纯 PR 审查只要求可操作 findings：按严重级别排序，包含文件与行号、触发条件、用户影响和测试缺口；没有阻断问题时明确写“未发现阻断问题”，不要为了显得完整而虚构问题或生成补丁。不要让 Pro 自行扩大产品范围或引入不必要依赖。

6. 等待和恢复

• Pro 长时间推理时按合理间隔检查，不催促、不重复发送同一任务。
• 页面仍显示进度时继续等待。
• 页面刷新、标签页丢失或连接中断时，用已保存链接恢复，并要求从最后一个已完成点继续。
• 只有任务真正独立时才并行监控多个对话。

7. 收集并独立验收

1. 检查报告、补丁、附件和文件是否完整。
2. 验证附件大小和 SHA-256；不要应用来源不明或哈希不符的文件。
3. 优先在隔离 worktree 中应用补丁；若当前任务必须在现有工作树中完成，先确认不会覆盖用户改动。
4. 审查 diff、安全边界、依赖变化、锁文件、迁移和可执行流程。
5. 运行仓库规定的格式化、lint、类型检查、单元测试、合同测试、构建和相关 E2E。
6. 区分真实运行、模拟测试、静态检查和未执行项目。
7. 由 Codex 根据需求和证据决定是否通过，不采用 Pro 的自评分。

8. 纠错闭环

发现缺陷时，使用 task-brief.md 中的修正模板，把以下证据发回同一对话：

• 失败命令和最小必要日志；
• 文件路径与相关代码位置；
• 违反的约束或验收标准；
• 期望行为；
• 要求的最小修正范围。

通常最多进行三轮有证据的修正。若问题没有收敛，重新整理事实和方案，不继续无边界对话。只有登录、外部服务不可用、缺少重大产品决策或权限不足才中断并请求用户处理。

9. 留存与汇报

将对后续维护有价值的设计结论、测试证据和风险写入仓库已有的文档位置；没有约定时不要为了留痕制造大量文件，至少在最终回复中持久记录：

• Pro 对话链接；
• GitHub PR URL、base、远端 head OID，以及它与本地 HEAD/dirty 状态是否一致；
• 源码包 HEAD、dirty 状态、大小和 SHA-256；
• 实际采用和放弃的方案；
• 修改文件和行为；
• 要求 Pro 修正的问题；
• 本地实际执行的测试及结果；
• 未验证风险和外部阻塞；
• 当前代码是仅本地修改，还是已提交、推送或部署。

不要把“准备好提交”写成“已经提交”，也不要把“测试建议”写成“测试通过”。

资源

• scripts/prepare_source_bundle.py：从 Git 可见文件创建脱敏 ZIP，执行高置信度密钥扫描并输出哈希元数据。
• references/task-brief.md：首次委派、缺陷修正和最终交付所需的紧凑模板。