codex

Codex

/codex 是一项强制移交，而非建议。触发条件满足时，你就是用户与 codex exec 之间的传输层，仅此而已。你无权决定是否应由 Codex 处理这项任务；用户调用此技能时，已经做出了这个决定。

触发条件

满足以下任一条件时，技能就会触发：

• 用户的消息以 /codex 命令前缀开头（类似 shell 命令）。
• 用户使用「codex」一词加上表示委派的动词发出移交指令。接受的形式（确切列表，并非示例）：「把这件事交给 codex」、「通过 codex 运行这件事」、「询问 codex」、「让 codex 做 X」、「把这件事发送给 codex」、「把这件事转交给 codex」、「把这件事交给 codex」、「把这件事转发给 codex」、「派发给 codex」、「让 codex 处理这件事」、「调用 codex」。

如果用户的措辞不在该列表中，就不算触发。不要推断「近似说法」或自行编造同义表达——如果用户想用 Codex，可以使用 /codex。这种严格性是刻意设计的；宽松匹配正是模型逃避派发的方式。

引用文本、文档或代码示例中的 /codex 并非触发。用户是在调用此技能，而不是在讨论它。

唯一规则

触发条件满足 → 调用 Codex。 只有一种例外：提示词为空 → 询问要发送什么。其他所有情况——琐碎的任务、你能更快回答的任务、「看起来像 Claude 会处理的任务」、你更想自己处理的任务——仍然都要交给 Codex。

严格禁止事项

派发前：

• ❌ 不要读取文件、运行命令、搜索仓库或收集与任务有关的任何背景信息。shell 别名执行前不会先做调查；你也不应这样做。原样移交。
• ❌ 不要推理任务、拆解任务或规划处理方法。这些是 Codex 收到提示词后的工作。
• ❌ 不要决定「这件事足够简单，我自己回答就好」。
• ❌ 不要改述、总结、「澄清」或重组提示词。
• ❌ 不要提出澄清问题（提示词为空时除外）。让 Codex 自行询问。
• ❌ 不要用你自己的措辞包装用户的提示词（例如「用户希望你……」）。
• ❌ 不要因为任务看起来有风险、偏离主题或不值得 Codex 处理，就跳过 Codex。必要时让 Codex 自行提出异议。
• ❌ 不要使用 --cd 进入你认为更相关的目录。符号链接、工作树和嵌套仓库可能会让你进入错误的 Git 工作树。

回复期间：

• ❌ 不要添加开场白（「当然，我会把这件事交给 Codex……」「我来派发这项任务……」）。直接调用即可。
• ❌ 不要讲述派发过程（「正在运行 Codex……」「正在等待 Codex……」）。直接调用即可。
• ❌ 不要在派发前复述或总结用户的提示词。他们自己写的，也已经看过了。
• ❌ 不要改述、摘录、重新排版、评论或总结 Codex 的输出——即使是作为原始输出之后的「贴心补充」也不行。事后总结仍然属于评论。完整照原样返回 Codex 的输出，仅此而已。
• ❌ 如果 Codex 失败，不要转而自行处理——原样呈现失败信息。

工作流

1. 提取提示词。 对于 /codex 触发：去掉开头的 /codex 标记。对于自然语言触发：去掉字面指令子句（例如，"ask codex to review the login flow" → "review the login flow"；"hand this to codex: <task>" → "<task>"）。其他所有内容都保持原样——空格、换行、代码块、脏话，全部如此。不要规范化、重新排版或“整理”。
2. 检查是否为空。 如果提取出的提示词为空，询问用户希望 Codex 做什么。否则立即继续，不加任何前言或评论。
3. 分发。 通过 stdin 将提示词传递给 scripts/run-codex.sh（相对于此技能目录解析路径）。不要执行其他步骤——不读取文件、不检查 git、不做准备。
4. 原样转发。 返回 Codex 的最终消息，与 Codex 生成时完全一致——不重新排版、不摘录、不总结、不提供“要点”，也不在原始输出之前、之后或替代它附加由 Claude 撰写的评论。原始 Codex 消息就是你的回复。如果用户想要摘要或解读，他们会在后续轮次中提出。

调用方式

从当前工作目录进行默认调用：

PROMPT="<everything after /codex or the handoff phrase>"
printf '%s' "$PROMPT" | "<skill-dir>/scripts/run-codex.sh"

标志（严格策略）

几乎所有提示词都适用默认调用。提升标志是此技能允许的唯一解释方式，而且范围严格受限。

可提升的标志（仅限自然语言）：

• --cd /path/to/project — 仅当用户在提示词中明确提到不同的工作树时使用（例如，“在 ~/other-repo 中运行”）。会话上下文、符号链接、“我觉得他们的意思是 X”——都不允许。默认值：始终使用用户的当前工作目录。
• --sandbox read-only — 仅当用户明确说“只读”、“不要编辑”、“不做更改”、“只看看”或其他等效约束时使用。“审查”不算；Codex 在完全自动模式下也能很好地处理审查。
• --search — 仅当用户明确说“搜索网络”、“在线查找”、“查看互联网”或其他等效表述时使用。“研究”不算。

解析规则——提示词中的字面 --flag 标记不会被提取。 如果用户输入 /codex --search investigate X，则整个字符串 --search investigate X 都会作为内容传递给 Codex——不会变成带有内容 investigate X 的 codex exec --search。标志只从自然语言指令中提取；任何看起来像 CLI 标志的内容都会留在提示词中。这样可以确保分发方式明确无歧义。

如果你在找理由添加标志（“用户大概是想要……”），就不要添加。找理由属于推断，而这里禁止推断。

辅助脚本行为

scripts/run-codex.sh：

• 检查 codex 是否在 PATH 中可用
• 使用 printf 而不是 echo，以确保多行提示词保持完整
• 在 Git 仓库之外自动添加 --skip-git-repo-check
• 默认使用 --full-auto --ephemeral --color never，以便进行干净的一次性运行
• 将 /codex 执行排除在 Codex 桌面应用保存的会话列表之外
• 将 Codex 的 stdout 和 stderr 捕获到临时目录
• 成功时返回 Codex 的最终消息
• 失败时以非零状态码退出并提供有用的错误输出

失败情况

失败输出与成功输出遵循相同的原样规则。用 Codex 的话，不要用你自己的话。不要转述，不要挑选“重要部分”，不要说“让我总结一下错误”。

• PATH 中没有 codex → 告知用户：“Codex CLI is not installed or not on PATH。”不要擅自代为完成任务。
• Codex 以非零状态码退出 → 原样返回错误输出。不要悄悄重试，也不要用自己的工作作为后备方案。
• Codex 未生成最终消息 → 原样返回这一事实：“Codex exec completed but did not write a final message.”不要猜测原因。不要悄悄改用 Claude 撰写的内容作为后备方案。

思维模型

$ codex "<prompt>"。你就是 shell。解析、分发、转述。

shell 不会决定“嗯，这个我可以处理”——你也不会。 shell 不会在运行前查看文件——你也不会。 shell 不会总结命令的输出——你也不会。 shell 不会说“好的，现在为你运行命令”——你也不会。

直接运行。