codex-issue-coordinator

Codex 问题协调器

使用一个 Codex 线程协调一批 GitHub 问题。为每个活动问题分配独立的工作线程、工作树、分支和拉取请求。工作线程保留实现上下文。GitHub 负责维护依赖状态。

明确指定 /codex-issue-coordinator，或明确告知协调器 Agent 可以合并，即授权范围内的工作线程在通过下方所有合并门槛后合并自己的拉取请求。仅凭隐式技能匹配不会授予合并权限：除非用户明确授权，否则请以禁止合并模式运行。 这两种模式都不授权部署、发布版本、破坏性操作、绕过分支保护，或更改所提供批次范围之外的内容。

请直接将必需技能的 SKILL.md 文件作为本工作流的指令读取。不要通过客户端会阻止的技能命令调用这些技能。

前置条件

1. 阅读仓库说明、父问题、原生子问题、已声明的依赖、项目看板、问题状态，以及关联的未关闭或已合并拉取请求。只有在拉取请求关闭或明确引用该问题，且其最终变更和证明符合问题范围时，已合并的拉取请求才能作为完成的依据。应据此协调问题和项目状态，而不是再次派发该问题。不要仅凭链接推断任务已完成。
2. 使用 Codex 线程工具。如果无法使用可见的 Codex 线程和由 Codex 管理的工作树，请停止。不要用隐藏的子 Agent 替代工作线程。
3. 派发前，将每个问题整理成完整任务。如果缺少的产品或技术决策可能影响行为、数据、安全性、兼容性、运维、成本或证明，则标记该问题需要人工输入。
4. 构建依赖关系图。将 GitHub 作为问题、拉取请求、审查和合并状态的持久可靠来源。若图中存在依赖循环，请停止并请求人工纠正。不要创建第二个本地跟踪器。
5. 默认最多同时安排两个活动工作线程。仅在用户要求或仓库规定更严格限制时采用其他上限。

协调者工作流

1. 将调用线程保留为协调者。如果批次有父议题，请将线程命名为 #<parent> Coordinator。每次开始或恢复协调者运行时，都要先使用 set_thread_pinned 将其置顶，然后再检查或派发工作线程。
2. 对同一议题复用现有的活动工作线程。创建新工作线程前，先检查状态不明确或已中断的工作线程。如果议题已有未关闭的拉取请求，请在该拉取请求的确切头部分支上创建或恢复其工作线程，并在提示词中包含分支和拉取请求 URL。否则，请在最新的远程默认分支上通过托管工作树创建 Codex 项目线程，并提供所需的新分支名称。
3. 将每个工作线程命名为 #<issue-number> <short title>。
4. 仅启动前置条件已合并的议题。独立议题可在工作线程数量限制内并行处理。此工作流中不要堆叠依赖分支。
5. 向工作线程提供完整议题 URL、依赖状态、仓库位置、已确定的分支和拉取请求状态，以及下方的工作线程约定。告知它使用 /task-to-pr，并传入协调者明确指定的合并或不合并模式。合并模式仅授予其处理该工作线程对应议题的权限。
6. 使用简洁的 wait_threads 快照监控工作线程。仅在工作线程需要帮助时使用 read_thread。通过 send_message_to_thread 发送决策或修正后的范围；不要从协调者线程修改工作线程的文件。
7. 某个议题受阻时，继续处理独立工作。在同一项检查或审查意见上连续失败三次后，暂停该议题，在 GitHub 上记录证据，并请求人工介入。
8. 在合并模式下，工作线程报告完成时，请确认 GitHub 显示拉取请求已合并、议题中包含最终证明，且议题已关闭。如果合并的拉取请求未关闭议题，请显式关闭议题。然后，在项目支持的情况下将议题标记为 Done，并归档工作线程。在不合并模式下，工作线程通过所有可由 Agent 完成的关卡后即停止；将议题留在 Review，记录任何待处理的人工批准或合并作为阻碍，并保留该线程以供后续使用。
9. 每次合并后刷新依赖关系图，并从更新后的远程默认分支派发新满足条件的议题。在不合并模式下，如果依赖议题只是在等待通过检查的前置拉取请求合并，请将这项人工合并依赖记录为阻碍。不要无限期等待，也不要从尚未合并的分支派发依赖议题。
10. 在合并模式下，只有当所有范围内议题都已合并、关闭，并在项目支持该状态时标记为 Done，或每个未完成议题都有需要人工处理的已记录阻碍时，才算完成。在不合并模式下，所有范围内议题都必须有已就绪且通过所有可由 Agent 完成的关卡的拉取请求，或有已记录的人工处理阻碍，方可结束。

Worker contract

每个 worker 负责一个 issue，并按以下顺序执行：

1. 阅读 issue、仓库说明、相关规范、代码、测试和依赖 pull request。条件允许时，将 issue 移至 In Progress。
2. 使用 Codex 管理的 worktree。如果 issue 已有未关闭的 pull request，则复用其确切的 head 分支和 pull request。否则，从更新后的默认分支创建符合仓库要求、关联该 issue 的分支。
3. 只实现该 issue。针对每项验收标准、受影响的失败路径、回归风险和明确列出的边缘情况，添加或更新测试。
4. 使用 /test。涉及浏览器的工作必须在真实浏览器中检查受影响的成功和失败流程、响应式宽度、键盘行为、控制台错误以及相关的请求失败。
5. 提交并推送通过测试的更改。如果尚无未关闭的 pull request，则创建一个草稿 pull request。附上简短摘要和当前验证证据。
6. 将 pull request 标记为可供审查，并将 issue 移至 Review。必须在请求独立审查或等待 GitHub 审查之前完成此操作。
7. 使用一个未参与实现此次更改的新 subagent 执行 /review。等待所需的 CI 和自动化审查。在合并模式下，还要等待仓库要求的所有批准。在不合并模式下，不要无限期等待人工反馈；将待处理的必要批准记录为人工阻塞项。
8. 处理所有有效且在范围内的审查意见。在审查线程中回复修复内容，或说明不做更改的依据。只有在线程问题完全解决后才将其标记为已解决。
9. 每次更改代码后，都要重新执行受影响的 /test 验证和新一轮 /review，提交并推送，更新 pull request 中的验证证据，并再次等待 CI 和自动化审查。持续迭代，直至通过对应模式的所有门槛；不要人为增加额外轮次，也不要无限期等待可选的人工反馈。
10. 在合并模式下，只有通过所有合并门槛后，才能使用仓库首选的方法合并 pull request。绝不使用管理员绕过功能。等待 GitHub 报告 pull request 已合并，记录最终验证证据，并确认 issue 已关闭。如果 pull request 未关闭 issue，则显式关闭。在不合并模式下，将通过检查的 pull request 保持打开，由人工合并。向协调者报告最终状态。

合并门槛

只有满足以下全部条件，worker 才能合并：

• pull request 已准备好接受审查，而非草稿。
• 已记录完整 issue 范围和验收标准的验证证据。
• 最终提交通过了针对性测试和要求执行的更广泛测试。
• 针对最终代码的新一轮 /review 结果为 Approve。
• 所有必需的 GitHub 检查均已通过。
• 所有可操作的自动化或人工审查线程均已解决。
• 已获得仓库要求的所有批准。
• pull request 可合并，且已基于要求的基准分支更新至最新状态。
• 没有尚未解决的安全、数据丢失、兼容性、运维或产品决策问题。
• pull request 只更改该 worker 负责的 issue。

如果某项门槛无法通过，则不要合并。记录阻塞项，并继续处理其他相互独立的工作。

Worker 提示词

采用以下格式并替换所有占位符：

Use /task-to-pr to complete <issue URL> in this Codex-managed worktree.

Your thread owns only this issue, branch, worktree, and pull request.
Branch state: <reuse PR head branch and PR URL, or create new branch name>.
Delivery mode: <merge after all gates pass, or leave the passing PR open>.
Read the issue and repository instructions as the source of truth.
Implement the smallest complete change and prove acceptance criteria, edge
cases, failure paths, and regressions.

After local proof passes, commit, push, open or update the pull request, and
mark it ready for review. Only then run fresh independent /review and wait for
CI and GitHub review. Address valid findings and repeat test and review after
every code change.

<If merge mode: The user explicitly authorized this /codex-issue-coordinator run to
merge this issue's pull request after every merge gate passes. Wait until
GitHub reports the merge, update and close the issue, and return the result.>
<If no-merge mode: Leave the passing pull request open for human merge and
return its URL and proof.>
Do not deploy, publish a release, bypass repository rules, or change unrelated
work.

返回内容

针对每个 issue，报告其 worker、pull request、门槛状态和阻塞项。说明哪些 issue 已完成，哪些需要人工处理。不要重复不会改变结果的 worker 日志。

边界

• 使用可见的 Codex 线程作为工作线程。只有在工作线程中执行独立的 /review 时，才使用全新的子 Agent。
• 同一个问题不得派发两个工作线程，也不得让两个工作线程共用同一个 worktree。
• 不得替换或重复创建该问题已有的拉取请求。应恢复处理该请求。
• 派发前，先核对已合并的拉取请求和已关闭的问题，但只有在其变更和验证证据符合问题范围后才可继续。
• 在此工作流中，不得基于尚未合并的拉取请求启动依赖工作。
• 不得仅仅因为某个无关的拉取请求阻塞了批次，就将其合并。
• 不得根据合并权限推断部署或发布权限。
• 在验证合并状态和问题的最终状态之前，不得归档工作线程。