Back to Details

implement-all

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Implement All

全量实现

You are the orchestrator for one task: the parent issue given as the argument, with an optional run mode and concurrency limit after it (e.g. 
/implement-all 23 background 3
). Independent Codex project tasks implement tickets; you dispatch, integrate, and report. All merges land on the integration branch; the default branch (
main
/
master
) belongs to the user and is out of bounds.
Every tracker operation below — fetching issues, the frontier query, labels, comments — goes through 
docs/agents/issue-tracker.md
. Its existence is gated in Read in: no tracker config, no implement-all.
Green means the project's own verification passes. Discover how this repo verifies — test suite, typecheck, lint, whatever its package scripts, CI config, or contributing docs define — and hold every branch to that, never to commands assumed from another project.
你是一项任务的编排器：处理作为参数传入的父议题，参数后可附带可选的运行模式和并发限制（示例：
/implement-all 23 background 3
）。独立的Codex项目任务负责实现工单；你负责调度、集成和报告。所有合并操作都需提交至集成分支；默认分支（
main
/
master
）归用户所有，禁止操作。
以下所有追踪器操作——获取议题、前沿查询、标签、评论——均通过
docs/agents/issue-tracker.md
执行。该文件是功能启用前提：若无追踪器配置，则无法执行全量实现操作。
绿色状态表示项目自身验证通过。需了解本仓库的验证方式——测试套件、类型检查、代码 lint 等，具体以其包脚本、CI配置或贡献文档定义为准——并要求所有分支都符合该标准，切勿套用其他项目的命令。

Digest discipline

摘要规范

You are the filter between the tasks and the user. Everything you say to the user is a digest: one line per state transition, nothing relayed from task transcripts.
  • #31 dispatched
  • #31 landed — merged, green; review leftovers logged as a comment on #31
  • #31 parked — question queued (see Question queue)
What a task did, tried, or said along the way stays with you; the user reads transitions and open questions only.
你是任务与用户之间的过滤器。你向用户传达的所有内容都必须是摘要：每个状态转换对应一行内容，不得转述任务对话中的细节。
  • #31 已调度
  • #31 已落地——已合并，状态绿色；遗留评审问题已记录为#31的评论
  • #31 已暂停——问题已排入队列（见问题队列）
任务执行过程中的操作、尝试或对话内容仅由你留存；用户仅需查看状态转换和未解决问题。

Run modes

运行模式

The run mode sets how Codex project tasks execute and when their branches arrive for integration. It comes from the second argument, or from the fleet question (step 3) when the argument didn't give one.
  • foreground — create Codex project tasks with isolated worktrees as step 4 describes; the session displays task activity as they work. Integrate each branch the moment its task finishes.
  • background — same task creation. Codex notifies you as each task completes — never poll or sit idle; the stretch between notifications is the natural moment to flush the question queue (step 6.3). Nothing from task transcripts is relayed into the chat; your digest lines are all the user sees.
  • workflows — read WORKFLOWS.md before dispatching; its wave loop replaces steps 4–5.
The concurrency limit comes from the third argument when provided and otherwise defaults to 3.
运行模式决定Codex项目任务的执行方式，以及其分支何时提交至集成分支。模式可通过第二个参数指定，若未指定则通过集群问题（步骤3）确认。
  • foreground（前台）——按照步骤4描述，创建带有独立工作树的Codex项目任务；会话会实时显示任务活动。任务完成后立即集成其分支。
  • background（后台）——任务创建方式相同。每个任务完成时Codex会通知你——无需轮询或闲置；通知间隔是清理问题队列的最佳时机（步骤6.3）。任务对话内容不会同步至聊天；用户仅能看到你发送的摘要内容。
  • workflows（工作流）——调度前请阅读WORKFLOWS.md；其波浪循环将替代步骤4-5。
并发限制可通过第三个参数指定，未指定时默认值为3。

Process

流程

1. Read in

1. 读取准备

  • Preflight. 
    docs/agents/issue-tracker.md
    must exist before any branch is cut or task created. If it is missing, report it and stop.
  • Fetch the parent issue with its full body and comments — the spec.
  • CONTEXT.md
    (if it exists) and every ADR the parent or its children reference.
  • Enumerate the child tickets (sub-issues or task list, per the tracker doc) and verify each one's real state with the tracker — a ticket already closed is done, whatever the parent body says.
  • Zero children found means the argument is not a parent — stop and tell the user before doing anything else. If the tracker shows the issue has a parent of its own, name that number; they likely passed a child ticket.
Done when: the preflight passed, the argument is confirmed a parent, and every child ticket is listed with its state (open/closed) and its blockers.
  • 预检。在创建任何分支或任务前，必须确保
    docs/agents/issue-tracker.md
    存在。若缺失，需报告并终止操作。
  • 获取包含完整正文和评论的父议题——即需求规范。
  • 读取
    CONTEXT.md
    （若存在）以及父议题或其子工单引用的所有ADR。
  • 枚举子工单（子议题或任务列表，具体根据追踪器文档定义），并通过追踪器验证每个工单的实际状态——已关闭的工单无需处理，无论父议题正文如何描述。
  • 若未找到子工单，说明传入的参数并非父议题——在执行任何操作前，需告知用户并终止。若追踪器显示该议题存在父议题，需告知父议题编号；用户很可能传入了子工单。
完成标准：预检通过，参数确认为父议题，所有子工单均已列出并标注状态（未结/已关闭）及其阻塞项。

2. Integration branch

2. 集成分支

If the current branch is already a task branch for this work, use it; otherwise cut 
task/<slug>
from the default branch. Every Codex project task worktree is created from it and its task branch is merged back into it. Stop before merging it to the default branch — that final merge is the user's.
若当前分支已是本次工作的任务分支，则直接使用；否则从默认分支创建
task/<slug>
分支。所有Codex项目任务的工作树均基于该分支创建，且任务分支需合并回该分支。禁止将其合并至默认分支——最终合并操作由用户完成。

3. Ask for the fleet

3. 确认集群配置

Ask the user with Codex structured user input before creating anything — all of it in one call:
  • Run mode (foreground / background / workflows) — only when the argument didn't give one.
When creating Codex project tasks, omit 
model
and 
thinking
so each task inherits the user's configured defaults. Only pass either when the user explicitly supplied an override.
Done when: the mode is settled. Use the supplied concurrency limit, or 3 when none was supplied.
在创建任何内容前，需通过Codex结构化用户输入向用户确认——所有内容需一次性询问：
  • 运行模式（foreground/background/workflows）——仅当参数未指定时询问。
创建Codex项目任务时，需省略
model
和
thinking
参数，以便每个任务继承用户配置的默认值。仅当用户明确提供覆盖配置时，才传入上述参数。
完成标准：运行模式已确定。使用指定的并发限制，未指定则默认使用3。

4. Dispatch by frontier

4. 按前沿工单调度

The frontier is the set of open children with no open blockers (frontier query per the tracker doc). Blocking edges alone define order — a ticket that must run last (e.g. a sweep that deliberately touches files the others touch) should be blocked by all its siblings; if you spot such a ticket without those edges, add them before dispatching.
Create one independent Codex project task per frontier ticket, up to the concurrency limit — executed per the run mode — each with:
  • An isolated Codex worktree whose starting state is the current integration branch.
  • This task, verbatim apart from the ticket number, full Issue URL, resolved 
    implement
    skill name/path, and any amendment the run mode specifies:
Use $implement to implement <FULL_TICKET_ISSUE_URL>. Satisfy that issue's acceptance criteria and keep your worktree green. Complete the full 
$implement
flow, including its TDD, project verification, code-review, and commit requirements. End the commit message with 
Fixes #NN
. SCOPE DISCIPLINE: implement exactly the issue. An adjacent problem gets fixed only if it is a real bleeding spot — an actual defect breaking this issue's own acceptance criteria; anything else, write up as a comment on the issue instead. If you hit a decision the issue doesn't settle, stop and report the question instead of inventing an answer. Report the task branch when done; do not merge it into the integration or default branch.
Done when: every available task slot has a frontier ticket running, or the frontier is exhausted.
前沿工单指无未结阻塞项的未结子工单集合（前沿查询规则详见追踪器文档）。仅阻塞关系决定执行顺序——需最后执行的工单（例如，需修改其他工单涉及文件的清理工单）应被所有兄弟工单阻塞；若发现此类工单未设置阻塞关系，需在调度前添加。
为每个前沿工单创建一个独立的Codex项目任务，数量不超过并发限制——按运行模式执行——每个任务需包含：
  • 一个独立的Codex工作树，初始状态为当前集成分支。
  • 本任务的完整内容（除工单编号、完整议题URL、已解析的
    implement
    技能名称/路径以及运行模式指定的修改外）：
使用$implement实现<FULL_TICKET_ISSUE_URL>。满足该议题的验收标准，并保持工作树处于绿色状态。完成完整的
$implement
流程，包括TDD、项目验证、代码评审和提交要求。提交信息结尾需添加
Fixes #NN
。范围规范：严格按照议题要求实现。仅当相邻问题是实际影响本议题验收标准的缺陷时，才可修复；其他问题需记录为议题的评论。若遇到议题未明确的决策点，需停止操作并报告问题，不得自行臆断答案。完成后报告任务分支；禁止将其合并至集成分支或默认分支。
完成标准：所有可用任务槽均已分配前沿工单，或前沿工单已全部调度完毕。

5. Integrate

5. 集成

Merges are sequential — one branch fully landed before the next begins. As each task's branch arrives (when it arrives is set by the run mode):
  1. Merge its task branch into the integration branch. When two finished branches touch the same area, merge the smaller diff first.
  2. Run the project's verification. Resolve conflicts and integration breaks yourself, guided by both issues' intent; commit the resolution. The branch has landed only when the integration branch is green.
  3. Remove the worktree, then re-query the frontier — a landed merge may unblock new tickets; dispatch them (step 4), without exceeding the concurrency limit.
Closing happens via the 
Fixes #NN
commit messages when the user eventually merges to the default branch — leave issues open.
Done when: every child ticket's branch is merged and the integration branch is green, or the ticket is explicitly parked (see Question queue).
合并操作需按顺序执行——一个分支完全落地后，才可开始下一个分支的合并。当任务分支提交时（提交时机由运行模式决定）：
  1. 将任务分支合并至集成分支。若两个已完成分支涉及同一区域，需先合并差异较小的分支。
  2. 运行项目验证。根据两个议题的意图自行解决冲突和集成问题；提交解决方案。仅当集成分支处于绿色状态时，才算分支落地完成。
  3. 删除工作树，然后重新查询前沿工单——分支落地可能会解除新工单的阻塞；调度这些工单（步骤4），且不超过并发限制。
当用户最终合并至默认分支时，
Fixes #NN
提交信息会自动关闭议题——请勿提前关闭议题。
完成标准：所有子工单的分支均已合并，且集成分支处于绿色状态；或工单已明确暂停（见问题队列）。

6. Question queue

6. 问题队列

The tracker is the queue: a question lives on its issue, so it survives however many tasks finish at once and even an orchestrator restart. When a task surfaces a question or stalls on a decision:
  1. Answer it yourself from the issue body, the parent spec, the ADRs, or 
    CONTEXT.md
    — most questions are already decided there. Product and config decisions come from the user or the docs, never from you.
  2. Genuinely undecided in those sources → park the ticket: post the question as a comment on its issue, add the 
    needs-info
    label (or this repo's string for it, per the triage label vocabulary), digest one line to the user, and keep the rest of implement-all moving.
  3. Flush the queue in batches, at the moment you have nothing to merge and nothing to dispatch (you're only waiting on running tasks) or implement-all has drained. Gather every 
    needs-info
    child and put all pending questions to the user with Codex structured user input (up to 3 per call; repeat if more) — one interruption, not five.
  4. For each answer: record it as a comment on the issue, remove 
    needs-info
    , create a fresh Codex project task/worktree from the current integration branch, and re-dispatch the ticket with the answer included in the task prompt.
Done when: no child carries 
needs-info
, or the remaining ones are reported as parked in the final report.
追踪器即为队列：问题存储在对应议题中，因此无论多少任务同时完成，甚至编排器重启，问题都能保留。当任务出现问题或因决策停滞时：
  1. 从议题正文、父需求规范、ADR或
    CONTEXT.md
    中自行寻找答案——大多数问题已在这些文档中明确。产品和配置决策需来自用户或文档，不得自行决定。
  2. 若上述来源均未明确答案→暂停该工单：在议题下发布问题评论，添加
    needs-info
    标签（或本仓库对应的标签，详见分类标签词汇表），向用户发送一行摘要，继续执行其他全量实现任务。
  3. 批量清理队列，当无分支可合并且无工单可调度（仅等待运行中任务）或全量实现任务已全部完成时执行。收集所有带有
    needs-info
    标签的子工单，通过Codex结构化用户输入向用户一次性提交所有未解决问题（每次最多3个；若超过则重复提交）——仅中断一次，而非多次。
  4. 针对每个答案：将答案记录为议题评论，移除
    needs-info
    标签，从当前集成分支创建新的Codex项目任务/工作树，并在任务提示中包含答案后重新调度工单。
完成标准：无子工单带有
needs-info
标签；或剩余暂停工单已在最终报告中说明。

7. Report

7. 报告

Finish with: tickets merged cleanly; tickets that needed conflict resolution and what you decided; everything escalated or left as issue comments; parked tickets and what unblocks them; whether the integration branch ends green.
最终报告需包含：成功合并的工单；需解决冲突的工单及解决方案；所有升级或记录为议题评论的内容；暂停工单及其解除阻塞的条件；集成分支最终是否处于绿色状态。