Back to Details

task-to-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Task to PR

从任务到PR

Review the tasks you were given. Decide the order and which tasks can run at the same time. Make a short plan.
Complete each task in two phases. Keep working without waiting for the user while any task can make progress.
Independent tasks may start together. Start a dependent task after every prerequisite has an open pull request, an independent 
/review
verdict of 
Approve
, and no known blocking finding. Stack dependent work on the prerequisite branch. If several unmerged prerequisites feed one task, stack those prerequisite branches in dependency order before branching the dependent task. When a prerequisite branch or pull request base changes, update every dependent branch to that reviewed state and repeat 
/test
and 
/review
. Retarget each stacked pull request to the default branch after its prerequisite merges, then repeat the proof against that base.
审核分配给你的任务。确定任务顺序以及可并行执行的任务。制定一个简短计划。
分两个阶段完成每个任务。在任何任务可以推进时，无需等待用户即可继续工作。
独立任务可同时启动。在所有前置任务都有一个已打开的pull request、独立
/review
的 verdict为
Approve
且无已知阻塞问题后，再启动依赖任务。将依赖工作堆叠在前置任务分支上。如果一个任务依赖多个未合并的前置任务，在为依赖任务创建分支前，需按依赖顺序堆叠这些前置任务分支。当前置任务分支或pull request的基础分支发生变化时，将所有依赖分支更新至该已审核状态，并重复执行
/test
和
/review
。当前置任务合并后，将每个堆叠的pull request重新定位到默认分支，然后针对该基础分支重复验证流程。

Phase 1: Build the code

第一阶段：构建代码

  1. Create or reuse a branch and worktree for the task. Start independent work from the latest default branch and dependent work from its reviewed prerequisite or stacked base.
  2. Write the code.
  3. Use 
    /test
    to prove the task works, affected failures are handled, and refactors preserve behavior.
  4. Commit and push the changes.
  5. Create or update one pull request on GitHub. Include a short summary and the current proof, then mark it ready for review.
  6. Move the ticket to the repository's review state, such as 
    In Review
    or 
    Review
    , when possible.
  7. Use 
    /review
    with a fresh subagent that did not write the code.
  8. Fix valid problems, then repeat 
    /test
    and 
    /review
    . Commit and push every reviewed fix before continuing.
  1. 为任务创建或复用一个分支和工作区。独立任务从最新的默认分支开始，依赖任务从其已审核的前置任务或堆叠的基础分支开始。
  2. 编写代码。
  3. 使用
    /test
    验证任务可正常运行、相关故障已处理，且重构未改变原有行为。
  4. 提交并推送更改。
  5. 在GitHub上创建或更新一个pull request。包含简短摘要和当前验证结果，然后标记为待审核状态。
  6. 尽可能将工单移至仓库的审核状态，例如
    In Review
    或
    Review
    。
  7. 使用未编写该代码的全新子代理执行
    /review
    。
  8. 修复有效问题，然后重复执行
    /test
    和
    /review
    。在继续之前，提交并推送所有经过审核的修复内容。

Phase 2: Pass the automated checks

第二阶段：通过自动化检查

  1. Use the GitHub CLI to wait for CI and automated code review when the repository uses them.
  2. Fix failures caused by your changes and valid review findings.
  3. If a fix needs a product or technical decision that the task does not contain, stop that task and report the missing decision.
  4. After changing code, repeat 
    /test
    and 
    /review
    .
  5. If you changed code, commit and push it. Update the pull request summary and proof when needed.
  6. Reply to every automated review finding. Say what you changed or why you made no change. Resolve the thread when it is fully addressed.
  7. Wait for the automated checks again.
  8. Repeat until all available checks pass and the automated review has no unresolved findings.
  9. Update the ticket with final proof and the pull request link when possible. Keep it in the repository's review state while the pull request is open.
If the user asked you to merge the pull requests, merge them in dependency order after their automated checks pass, the final 
/review
verdict is 
Approve
, required approvals are present, and no review thread is unresolved. Explicitly naming 
/codex-issue-coordinator
, or explicitly telling its coordinator that agents may merge, is a merge request for only the issues in its supplied batch. Automatic skill selection is not merge authority. After each prerequisite merges, retarget its dependents to the default branch, update them to that base, and repeat 
/test
, 
/review
, CI, and automated review before merging them. Never bypass repository rules. Wait until GitHub reports each pull request as merged before marking its ticket complete when possible. Otherwise, leave it open.
Continue with every task that can make progress. Stop when every task has a pull request with all available checks passing and no unresolved automated review findings. When merge was requested, stop only after every in-scope pull request is merged and its ticket is complete when possible. If no remaining task can move forward, explain what is needed.
  1. 若仓库启用了CI和自动化代码审核，使用GitHub CLI等待其完成。
  2. 修复由你的更改导致的故障以及有效的审核问题。
  3. 若修复需要任务中未包含的产品或技术决策，请停止该任务并报告缺失的决策需求。
  4. 修改代码后，重复执行
    /test
    和
    /review
    。
  5. 若修改了代码，提交并推送。必要时更新pull request的摘要和验证结果。
  6. 回复每一条自动化审核发现。说明你做了哪些更改或为何未做更改。当问题完全解决后，关闭该讨论线程。
  7. 再次等待自动化检查完成。
  8. 重复上述步骤，直到所有可用检查通过且自动化审核无未解决问题。
  9. 尽可能使用最终验证结果和pull request链接更新工单。在pull request处于打开状态时，保持工单处于仓库的审核状态。
若用户要求你合并pull request，需在其通过自动化检查、最终
/review
的verdict为
Approve
、获得必要的审批且无未解决的审核线程后，按依赖顺序进行合并。明确指定
/codex-issue-coordinator
，或明确告知其协调员代理可进行合并，仅针对其提供的批次中的问题发起合并请求。自动技能选择不具备合并权限。每个前置任务合并后，将其依赖任务重新定位到默认分支，更新至该基础分支，并在合并前重复执行
/test
、
/review
、CI和自动化审核。切勿绕过仓库规则。尽可能在GitHub报告pull request已合并后，再将对应工单标记为完成。否则，保持工单处于打开状态。
继续推进所有可进展的任务。当每个任务都有一个通过所有可用检查且无未解决自动化审核问题的pull request时，停止操作。若要求合并，则需在所有范围内的pull request均已合并且对应工单尽可能完成后，再停止操作。若剩余任务无法推进，请说明所需条件。