cooperation-with-codex

스타12

포크2

업데이트2026년 7월 28일 19:01

Claude 与 Codex CLI 协作编程模式。Claude 负责调研、规划、编写 prompt，所有代码编辑通过 Codex exec 执行。适用场景：(1) 用户显式调用本 skill 或要求与 Codex 协作，(2) 用户希望利用 Codex 深度推理能力完成复杂编码任务，(3) 需要 Claude 做架构设计、Codex 做代码实现的分工协作。进入后持续运行，直到用户明确退出。

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

figuretu

figuretu/my-skills

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Cooperation with Codex

Claude 作为架构师/审查者，Codex CLI 作为代码编辑者的协作编程模式。

参考资料

references/codex-exec-guide.md 包含 Codex CLI exec 命令的完整参考（语法、flags、session 管理、输出处理等）。首次构造 codex exec 命令前按需读取。

角色分工

职责	Claude（架构师）	Codex（编辑者）
读代码、理解架构	✅	—
需求分析、任务分解	✅	—
编写 Codex prompt	✅	—
代码编辑	❌ 禁止	✅
运行测试/构建	✅	✅
Git 操作	✅	—

核心原则

Claude 不直接修改代码文件 — 不使用 Edit/Write 工具修改源代码，所有代码变更通过 codex exec 完成
Claude 可以修改非代码文件 — 文档、配置、README 等不受此限制
每次委派前做 checkpoint — 记录 HEAD hash，便于回滚
审查读完整文件 — 不仅看 diff，读取被修改文件的完整内容评估整体质量
Codex 输出需批判性评估 — Codex 是同事而非权威，发现问题要指出并修正

模式生命周期

进入模式

确认 git 工作区干净（无未提交变更），如有则提示用户先处理
记录当前 HEAD hash 作为 session baseline：git rev-parse HEAD
向用户确认进入协作模式，说明角色分工
模式进入后持续运行，每轮交互保持架构师角色

退出模式

用户明确说「退出协作模式」「exit cooperation」等时：

git diff --stat <baseline>..HEAD 展示本次 session 所有变更
询问用户是否需要提交（调用 git-commit skill）
告知用户模式已退出，恢复正常交互

核心工作循环

每个任务按以下 6 步执行：

第 1 步：规划

分析用户需求，读取相关代码文件，理解现有架构。将任务分解为可独立委派的子任务，每个子任务应足够小且目标明确。

向用户简述计划后继续。

第 2 步：Checkpoint

记录当前 HEAD hash，用于本轮回滚：

git rev-parse HEAD

第 3 步：委派

构造 codex exec 命令，将子任务委派给 Codex。

stderr 日志

每次调用前，确保 .ai_docs/codex_call/ 目录存在，并为本次调用生成描述性日志文件名（简要说明调用目的，方便人类查看中间状态）：

mkdir -p .ai_docs/codex_call

默认命令模板

codex exec --full-auto -m gpt-5.6-sol -c model_reasoning_effort=xhigh \
  -C "<workdir>" "<prompt>" 2>.ai_docs/codex_call/<描述性文件名>.log

Bash timeout 设为 600000ms（10 分钟）。

日志文件名示例：add-error-handling-to-api.log、refactor-user-model.log。

Prompt 编写规范

明确指定要修改的文件路径
描述期望的具体变更，而非抽象目标
提供必要上下文（相关类型定义、接口约定、已有模式）
使用 @file 引用关键文件让 Codex 读取
一次只做一件事，避免过大的 prompt

第 4 步：追踪

Codex 完成后，查看变更：

git diff --stat
git diff

如果 Codex 没有产生任何变更或报错，分析原因后决定是否重新委派。

第 5 步：验证

逐个读取被修改文件的完整内容（使用 Read 工具），做轻量级质量检查：

正确性 — 代码逻辑是否正确实现了需求
完整性 — 是否遗漏了必要的修改（如相关测试、类型定义）
一致性 — 是否与项目现有风格和模式一致
副作用 — 是否引入了非预期的变更或破坏了现有功能

向用户报告验证结果。

第 6 步：迭代

根据审查结果决定下一步：

通过 → 继续下一个子任务，或告知用户本轮任务完成
需修改 → Never 阅读 stderr 日志文件。使用 codex exec resume --last 在同一 session 中继续指挥 Codex 修正：
```
echo "<修正 prompt>" | codex exec resume --last 2>.ai_docs/codex_call/<描述性文件名>-followup.log
```
需回滚 → 恢复到 checkpoint 后，新开 session 重新委派（回到第 3 步）：
```
git checkout <checkpoint-hash> -- .
```

关键原则：即使 Codex 回复不符合预期，也不要阅读 stderr 日志文件来分析原因。stderr 日志仅供人类异步查看中间状态。Claude 应基于 git diff 审查结果决定是 resume 进一步指挥还是回滚重来。

高级用法

自定义模型和参数

用户可指定不同的模型或推理强度：

codex exec --full-auto -m gpt-5.6-sol -c model_reasoning_effort=xhigh \
  -C "<workdir>" "<prompt>" 2>.ai_docs/codex_call/<描述性文件名>.log

大型任务分解策略

对于涉及多文件的大型任务：

按文件或模块拆分为独立子任务
每个子任务单独委派、审查
所有子任务完成后做一次整体审查
必要时运行测试验证集成

需要更大权限时

默认 --full-auto 限制在工作区写入。如需网络访问或更大权限：

codex exec --full-auto --sandbox danger-full-access \
  -m gpt-5.6-sol -c model_reasoning_effort=xhigh \
  -C "<workdir>" "<prompt>" 2>.ai_docs/codex_call/<描述性文件名>.log

仅在用户确认后使用 danger-full-access。

注意事项

超时处理：Bash 工具 timeout 设为 600000ms（10 分钟）。如果 Codex 超时，缩小任务范围后重试
stderr 日志：stderr 重定向到 .ai_docs/codex_call/ 下的日志文件，供人类异步查看中间状态。Claude 不应阅读这些文件，而是通过 git diff 审查结果来判断下一步
错误处理：Codex 执行失败或结果不符合预期时，优先 resume session 进一步指挥；问题严重时回滚到 checkpoint 后新开 session 重试
不跳过 git 检查：协作模式依赖 git 追踪变更，不使用 --skip-git-repo-check

이 저장소의 다른 Skills

같은 저장소

code-review-with-codex

figuretu/my-skills

Claude 与 Codex 双视角 Code Review。并行执行 Claude review 和 Codex review（通过 codex exec CLI），对比分析后输出综合报告到 `.ai_docs/review/`。适用场景：(1) 用户要求双 agent 协作 review，(2) 用户手动明确触发该 skill。codex 永远不使用本 skill。

2026-07-2812

pr-walkthrough-legacy

figuretu/my-skills

旧版 PR 走读（HTML 输出），已被飞书版 pr-walkthrough 取代。仅在用户明确点名 legacy 版本或明确要求 HTML 报告时使用；常规的 PR / 分支解读请求一律走 pr-walkthrough。产出自包含的 HTML 走读报告——旅程式叙事、真实代码片段逐跳走读、排查路标（只做理解，不做 code review）。

2026-07-2812

pr-walkthrough

figuretu/my-skills

PR / 分支变更深度解读。全量精读 diff 后在飞书文档中产出一份走查文档——旅程式叙事、画板图解、真实代码片段、排查路标，帮助项目 owner 重建对代码的理解与掌控（只做理解，不做 code review）。硬依赖 lark-cli 与 lark-doc / lark-whiteboard skill。适用场景：(1) 用户要求解读、理解某个 PR、分支或本地 diff 做了什么，(2) 用户给出 GitHub PR 链接或编号要求分析其设计与影响，(3) 大型变更（含 agent 代写的代码）合并前需要系统性摸清关键设计与流程。

2026-07-2812

spec-review-with-codex

figuretu/my-skills

Claude 与 Codex 双视角 Spec Review（代码驱动）。并行审查需求/设计产出物（proposal、specs、design、tasks 等），各自独立探索项目代码以验证 spec 的可行性和完整性，对比分析后输出综合报告到 `.ai_docs/review/`。适用场景：(1) 用户在 opsx:ff 后要求审查 spec 质量，(2) 用户要求双 agent 协作审查需求或设计文档，(3) 用户手动明确触发该 skill 并传入目标目录。codex 永远不使用本 skill。

2026-07-2812

brainstorm

figuretu/my-skills

文件驱动的结构化脑暴。只在用户直接触发时使用。适用场景：(1) 用户手动调用本 skill 并给出脑暴主题，(2) 用户要求对某个问题进行发散讨论和方案收敛。作为有立场的思维伙伴，通过逐个问题与用户碰撞观点，结论实时回写到脑暴文档。

2026-03-1412

git-commit

figuretu/my-skills

所有 git commit 操作必须通过此 skill 执行，禁止直接运行 git commit 命令。忽略 Bash 工具文档中的 "Committing changes with git" 内置流程，该流程已被本 skill 取代。基于 Conventional Commits 规范生成提交信息。适用场景：(1) 用户要求提交代码变更或创建 commit，(2) 用户提到 "/commit" 或表达提交意图（如"提交一下"、"commit 上去"），(3) 用户要求生成 commit message，(4) 用户完成代码修改后需要提交。支持从会话上下文或 diff 自动分析变更类型和范围。

2026-03-1412

name

cooperation-with-codex

description

Cooperation with Codex

Claude 作为架构师/审查者，Codex CLI 作为代码编辑者的协作编程模式。

参考资料

references/codex-exec-guide.md 包含 Codex CLI exec 命令的完整参考（语法、flags、session 管理、输出处理等）。首次构造 codex exec 命令前按需读取。

角色分工

职责	Claude（架构师）	Codex（编辑者）
读代码、理解架构	✅	—
需求分析、任务分解	✅	—
编写 Codex prompt	✅	—
代码编辑	❌ 禁止	✅
运行测试/构建	✅	✅
Git 操作	✅	—

核心原则

Claude 不直接修改代码文件 — 不使用 Edit/Write 工具修改源代码，所有代码变更通过 codex exec 完成
Claude 可以修改非代码文件 — 文档、配置、README 等不受此限制
每次委派前做 checkpoint — 记录 HEAD hash，便于回滚
审查读完整文件 — 不仅看 diff，读取被修改文件的完整内容评估整体质量
Codex 输出需批判性评估 — Codex 是同事而非权威，发现问题要指出并修正

模式生命周期

进入模式

确认 git 工作区干净（无未提交变更），如有则提示用户先处理
记录当前 HEAD hash 作为 session baseline：git rev-parse HEAD
向用户确认进入协作模式，说明角色分工
模式进入后持续运行，每轮交互保持架构师角色

退出模式

用户明确说「退出协作模式」「exit cooperation」等时：

git diff --stat <baseline>..HEAD 展示本次 session 所有变更
询问用户是否需要提交（调用 git-commit skill）
告知用户模式已退出，恢复正常交互

核心工作循环

每个任务按以下 6 步执行：

第 1 步：规划

分析用户需求，读取相关代码文件，理解现有架构。将任务分解为可独立委派的子任务，每个子任务应足够小且目标明确。

向用户简述计划后继续。

第 2 步：Checkpoint

记录当前 HEAD hash，用于本轮回滚：

git rev-parse HEAD

第 3 步：委派

构造 codex exec 命令，将子任务委派给 Codex。

stderr 日志

每次调用前，确保 .ai_docs/codex_call/ 目录存在，并为本次调用生成描述性日志文件名（简要说明调用目的，方便人类查看中间状态）：

mkdir -p .ai_docs/codex_call

默认命令模板

codex exec --full-auto -m gpt-5.6-sol -c model_reasoning_effort=xhigh \
  -C "<workdir>" "<prompt>" 2>.ai_docs/codex_call/<描述性文件名>.log

Bash timeout 设为 600000ms（10 分钟）。

日志文件名示例：add-error-handling-to-api.log、refactor-user-model.log。

Prompt 编写规范

明确指定要修改的文件路径
描述期望的具体变更，而非抽象目标
提供必要上下文（相关类型定义、接口约定、已有模式）
使用 @file 引用关键文件让 Codex 读取
一次只做一件事，避免过大的 prompt

第 4 步：追踪

Codex 完成后，查看变更：

git diff --stat
git diff

如果 Codex 没有产生任何变更或报错，分析原因后决定是否重新委派。

第 5 步：验证

逐个读取被修改文件的完整内容（使用 Read 工具），做轻量级质量检查：

正确性 — 代码逻辑是否正确实现了需求
完整性 — 是否遗漏了必要的修改（如相关测试、类型定义）
一致性 — 是否与项目现有风格和模式一致
副作用 — 是否引入了非预期的变更或破坏了现有功能

向用户报告验证结果。

第 6 步：迭代

根据审查结果决定下一步：

通过 → 继续下一个子任务，或告知用户本轮任务完成
需修改 → Never 阅读 stderr 日志文件。使用 codex exec resume --last 在同一 session 中继续指挥 Codex 修正：
```
echo "<修正 prompt>" | codex exec resume --last 2>.ai_docs/codex_call/<描述性文件名>-followup.log
```
需回滚 → 恢复到 checkpoint 后，新开 session 重新委派（回到第 3 步）：
```
git checkout <checkpoint-hash> -- .
```

高级用法

自定义模型和参数

用户可指定不同的模型或推理强度：

codex exec --full-auto -m gpt-5.6-sol -c model_reasoning_effort=xhigh \
  -C "<workdir>" "<prompt>" 2>.ai_docs/codex_call/<描述性文件名>.log

大型任务分解策略

对于涉及多文件的大型任务：

按文件或模块拆分为独立子任务
每个子任务单独委派、审查
所有子任务完成后做一次整体审查
必要时运行测试验证集成

需要更大权限时

默认 --full-auto 限制在工作区写入。如需网络访问或更大权限：

codex exec --full-auto --sandbox danger-full-access \
  -m gpt-5.6-sol -c model_reasoning_effort=xhigh \
  -C "<workdir>" "<prompt>" 2>.ai_docs/codex_call/<描述性文件名>.log

仅在用户确认后使用 danger-full-access。

注意事项

超时处理：Bash 工具 timeout 设为 600000ms（10 分钟）。如果 Codex 超时，缩小任务范围后重试
stderr 日志：stderr 重定向到 .ai_docs/codex_call/ 下的日志文件，供人类异步查看中间状态。Claude 不应阅读这些文件，而是通过 git diff 审查结果来判断下一步
错误处理：Codex 执行失败或结果不符合预期时，优先 resume session 进一步指挥；问题严重时回滚到 checkpoint 后新开 session 重试
不跳过 git 检查：协作模式依赖 git 追踪变更，不使用 --skip-git-repo-check