Back to Details

orchestrate

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Orchestrate

编排

Keep every user-visible Codex chat moving as far as its current authority permits. Work as the coordinator; leave implementation inside each chat.
确保每个用户可见的Codex对话在其当前权限范围内尽可能推进。担任协调角色；具体实现交由各对话自行处理。

Chat boundary

对话边界

The inventory contains only user-visible Codex chats from the Codex task list.
Background implementation is outside this skill's inventory. This includes subagents, CLI 
exec
sessions, automation runs, approval guardians, shell processes, test runners, and other worker sessions. Do not instruct, classify, or report these sessions. Read their state only when it explains the status of a user-visible chat.
清单仅包含Codex任务列表中用户可见的Codex对话。
后台实现不在本技能的管辖范围内，包括子Agent、CLI 
exec
会话、自动化运行、审批守护进程、Shell进程、测试运行器及其他工作会话。不得对这些会话下达指令、分类或上报。仅当它们的状态能解释用户可见对话的状态时，才可读取其状态。

Sweep

巡检

  1. List every incomplete user-visible Codex chat.
  2. Read each chat's recent status and current run state.
  3. Inspect the current mergeability of each open pull request owned by a chat.
  4. Classify each chat:
    • Active: A command, check, or agent turn is running.
    • Idle and actionable: No work is running, and the next action is clear, safe, and within the task's existing scope and authority. A current failing check or pull request with merge conflicts is actionable.
    • Operator required: No safe work remains without an operator decision, approval, credential, clarification, or external action.
  5. Account for every incomplete user-visible chat before proceeding.
Elapsed time alone does not prove that a chat is idle. Inspect its current state.
  1. 列出所有未完成的用户可见Codex对话。
  2. 读取每个对话的最新状态和当前运行状态。
  3. 检查每个对话所属的未关闭pull request的当前可合并性。
  4. 对每个对话进行分类：
    • 活跃状态： 正在运行命令、检查或Agent轮次。
    • 闲置且可执行： 无工作正在运行，且下一步操作明确、安全，且在任务现有范围和权限内。当前存在失败检查或合并冲突的pull request属于可执行场景。
    • 需操作人员介入： 若无操作人员的决策、审批、凭证、澄清或外部操作，则无法进行安全工作。
  5. 在继续操作前，确保所有未完成的用户可见对话都已被处理。
仅耗时长短不能证明对话处于闲置状态，需检查其当前状态。

Advance actionable chats

推进可执行对话

Send one instruction to each idle and actionable chat. The instruction must:
  • State the next concrete action.
  • Preserve the chat's existing scope and authority.
  • Define an observable completion criterion.
  • Tell the chat to continue through subsequent safe steps.
  • Tell the chat to stop only at completion or a genuine operator dependency.
Do not repeat an unchanged instruction that the chat already received.
When one branch needs the operator but independent work remains, instruct the chat to complete the independent work first. Escalate only after the chat has exhausted safe progress.
向每个闲置且可执行的对话发送一条指令，指令必须满足：
  • 明确下一步具体操作。
  • 保留对话的现有范围和权限。
  • 定义可观测的完成标准。
  • 告知对话继续执行后续安全步骤。
  • 告知对话仅在完成任务或确实需要操作人员介入时停止。
不得重复发送对话已接收过的未更改指令。
当某个分支需要操作人员介入但仍有独立工作可做时，指示对话先完成独立工作。仅当对话已穷尽所有安全推进路径后，再进行上报。

Merge-conflicted pull requests

存在合并冲突的pull request

Treat a merge conflict as routine branch maintenance. When the owning chat is idle, immediately instruct it to:
  1. Update its branch from the pull request's current target branch with the repository's canonical branch-update and merge-conflict workflows.
  2. Resolve every conflict within the pull request's accepted scope and repository policy.
  3. Run the verification required for the changed conflict resolutions.
  4. Push the updated branch.
  5. Confirm that the pull request no longer reports merge conflicts.
The observable completion criterion is a pushed branch whose pull request reports no merge conflicts and whose required verification passes.
Escalate only when repository policy requires a halt, the conflict exposes incompatible accepted requirements, required access is unavailable, or safe conflict-resolution attempts fail.
将合并冲突视为常规分支维护工作。当所属对话处于闲置状态时，立即指示其执行以下操作：
  1. 使用仓库的标准分支更新和合并冲突处理流程，从pull request的当前目标分支更新自身分支。
  2. 在pull request的已接受范围和仓库政策内解决所有冲突。
  3. 对已修改的冲突解决方案运行必要的验证。
  4. 推送更新后的分支。
  5. 确认pull request不再显示合并冲突。
可观测的完成标准是：推送后的分支对应的pull request无合并冲突，且所有必要验证均通过。
仅在以下情况时才上报：仓库政策要求停止操作、冲突暴露了不兼容的已接受需求、所需权限无法获取，或安全冲突解决尝试失败。

Failing checks

失败的检查

Treat a failing check on the chat's current pull-request head as actionable work. Ignore superseded failures from older heads. When the owning chat is idle, immediately instruct it to:
  1. Inspect the failing check's current logs and reproduce the failure locally when the repository provides a stable local seam.
  2. Classify the cause as branch-local, base-owned, transient infrastructure, or an external dependency.
  3. Fix every branch-local cause within the chat's accepted scope. Use the repository's existing diagnosis, development, and test workflows when they apply.
  4. Run the narrow regression first, then the required verification for the changed code.
  5. Commit and push the repair to the existing branch without expanding scope or creating a new pull request.
  6. Recheck the current pull-request head and continue until its required checks pass.
For a transient infrastructure failure, use bounded safe retries and scoped recovery before escalating. For a base-owned failure, update from the current target branch when repository policy permits, verify the merged result, and push it. The observable completion criterion is a current pull-request head with the repaired check and all required checks passing.
Escalate only when the failure needs an operator decision, new authority, unavailable credentials, destructive recovery, an incompatible accepted requirement, a human-owned review action, or an external service that still fails after bounded safe recovery. Report the exact check, current-head evidence, attempted recovery, and one operator action.
将对话当前pull-request头部的失败检查视为可执行工作。忽略旧头部已被取代的失败情况。当所属对话处于闲置状态时，立即指示其执行以下操作：
  1. 检查失败检查的当前日志，若仓库提供稳定的本地接口，则在本地复现失败情况。
  2. 将失败原因分类为分支本地问题、基准分支问题、临时基础设施问题或外部依赖问题。
  3. 在对话的已接受范围内修复所有分支本地问题。适用时使用仓库现有的诊断、开发和测试流程。
  4. 先运行窄范围回归测试，再对修改后的代码运行必要的验证。
  5. 将修复提交并推送到现有分支，不得扩大范围或创建新的pull request。
  6. 重新检查当前pull-request头部，持续操作直到所有必要检查通过。
对于临时基础设施失败，在上报前先进行有限次安全重试和范围化恢复。对于基准分支问题，若仓库政策允许，从当前目标分支更新，验证合并结果后推送。可观测的完成标准是：当前pull-request头部的检查已修复，且所有必要检查均通过。
仅在以下情况时才上报：失败需要操作人员决策、新权限、无法获取的凭证、破坏性恢复、不兼容的已接受需求、人工评审操作，或经过有限次安全恢复后仍失败的外部服务。上报时需说明具体检查项、当前头部证据、已尝试的恢复措施，以及所需的一项操作人员操作。

Operator boundary

操作人员介入边界

Operator attention is required when progress depends on:
  • A material product, design, or scope decision.
  • New authority or an approval the chat does not already have.
  • Credentials or access that the chat cannot obtain safely.
  • A destructive or difficult-to-recover action.
  • Conflicting accepted requirements.
  • A human-owned review response or resolution.
  • A blocker that remains after the chat exhausts its safe recovery paths.
Do not make these decisions for the operator.
当推进工作依赖以下情况时，需要操作人员关注：
  • 重要的产品、设计或范围决策。
  • 对话当前未拥有的新权限或审批。
  • 对话无法安全获取的凭证或访问权限。
  • 破坏性或难以恢复的操作。
  • 相互冲突的已接受需求。
  • 人工评审的回复或决议。
  • 对话穷尽所有安全恢复路径后仍存在的阻塞问题。
不得替操作人员做出这些决策。

Report

上报

After advancing actionable chats, report every user-visible chat that currently requires operator attention.
Use the chat's exact title. When the current client supports Codex deep links and the inventory provides the chat ID, render that title as 
[Exact chat title](codex://threads/<thread-id>)
. Otherwise, render the exact title as plain text. Link the relevant issue, requested change, review, check, or other source when available.
ChatBlockerWork completedOperator action required
Exact chat titleConcrete reason progress stoppedFurthest safe state reachedOne specific decision or action
Include unchanged operator dependencies until they are resolved. If none require attention, report that briefly.
Optionally summarize newly resumed chats separately:
ChatInstruction sent
Exact chat titleConcrete next action and completion criterion
在推进可执行对话后，上报所有当前需要操作人员关注的用户可见对话。
使用对话的确切标题。若当前客户端支持Codex深度链接且清单提供对话ID，则将标题格式化为
[Exact chat title](codex://threads/<thread-id>)
；否则以纯文本形式显示确切标题。若有相关问题、请求的变更、评审、检查或其他来源，需添加链接。
ChatBlockerWork completedOperator action required
Exact chat titleConcrete reason progress stoppedFurthest safe state reachedOne specific decision or action
未解决的操作人员依赖项需持续上报，直到问题解决。若没有需要关注的项，简要说明即可。
可选择单独汇总新恢复的对话：
ChatInstruction sent
Exact chat titleConcrete next action and completion criterion

Recurring orchestration

周期性编排

When recurring monitoring is requested:
  1. Complete one full sweep immediately.
  2. Advance every presently actionable idle chat.
  3. Report current operator dependencies from user-visible chats.
  4. Create or update one five-minute heartbeat that repeats this skill's sweep.
Keep one monitor for this purpose. Update it instead of creating a duplicate.
当请求周期性监控时：
  1. 立即完成一次完整巡检。
  2. 推进所有当前可执行的闲置对话。
  3. 上报用户可见对话当前的操作人员依赖项。
  4. 创建或更新一个五分钟的心跳任务，重复执行本技能的巡检操作。
为此仅保留一个监控任务，更新现有任务而非创建重复任务。