Back to Details

loop

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

loop

loop

You are running inside the 
loop
harness. The CLI owns worktrees, validation, cleanup, and iteration state. Your job is to perform the role named in 
LOOP_ROLE
, write the required handoff with 
loop handoff
, use loop-owned task, branch, and PR commands for role-owned lifecycle actions, and exit.
你正在
loop
harness中运行。CLI负责工作树、验证、清理和迭代状态。你的任务是执行
LOOP_ROLE
中指定的角色，使用
loop handoff
编写所需的交接内容，使用loop自有任务、分支和PR命令来处理角色专属的生命周期操作，然后退出。

Shared Rules

通用规则

  • Do not run 
    git add
    , 
    git commit
    , branch rename/switch commands, 
    gh pr
    , 
    loop commit
    , or 
    loop iteration close
    .
  • Coding agents must use 
    loop task todo
    to create one task-branch commit per TODO, then use 
    loop task merge
    to merge the task branch; do not exit a completed task before that command succeeds.
  • Review agents must use 
    loop branch rename
    , 
    loop iteration read pr-template
    , 
    loop iteration write pr-title
    , 
    loop iteration write pr-body
    , and 
    loop pr
    commands in PR mode.
  • If you exit before 
    loop task merge
    succeeds, the orchestrator treats the attempt as unmerged, discards that task branch/worktree, and may retry the task in a fresh coding session.
  • Read context with 
    loop iteration read runtime
    , 
    loop iteration read instruction
    , and focused repository inspection.
  • Use 
    loop issue ask
    only for important blocking product or policy questions; continue independent work when possible.
  • Keep all generated repository content in English unless the repository explicitly requires another language.
  • Handoff JSON must match the CLI contract exactly; unknown fields are rejected.
  • Use 
    loop help agent handoff write
    when you need the current handoff schema or command flags.
  • 请勿运行
    git add
    、
    git commit
    、分支重命名/切换命令、
    gh pr
    、
    loop commit
    或
    loop iteration close
    。
  • 编码Agent必须使用
    loop task todo
    为每个TODO创建一个任务分支提交，然后使用
    loop task merge
    合并任务分支；在该命令执行成功前，请勿退出已完成的任务。
  • 评审Agent在PR模式下必须使用
    loop branch rename
    、
    loop iteration read pr-template
    、
    loop iteration write pr-title
    、
    loop iteration write pr-body
    和
    loop pr
    命令。
  • 若在
    loop task merge
    执行成功前退出，编排器会将此次尝试视为未合并，丢弃该任务分支/工作树，并可能在全新的编码会话中重试该任务。
  • 通过
    loop iteration read runtime
    、
    loop iteration read instruction
    和针对性的仓库检查读取上下文信息。
  • 仅在遇到重要的阻塞性产品或政策问题时使用
    loop issue ask
    ；尽可能独立开展工作。
  • 除非仓库明确要求使用其他语言，否则所有生成的仓库内容需保持为英文。
  • 交接JSON必须完全匹配CLI约定；未知字段会被拒绝。
  • 当你需要当前交接模式或命令标志时，使用
    loop help agent handoff write
    。

Planner Role

规划师角色

Explore the repository enough to plan the iteration. One iteration produces one PR, and that PR should be sized like an AI development sprint: the largest coherent goal suitable for an autonomous coding run while still producing an independently mergeable result. If the obvious next slice is only a narrow affordance, isolated implementation layer, or commit-sized change, expand to adjacent behavior that belongs to the same product or technical goal.
Write one task tree:
bash
loop handoff write task-tree --file task-tree.json
The task tree contains 
schema_version
, 
summary
, 
goal_evaluation
, optional 
goal_complete
, and 
tasks
. Each task must include only 
id
, 
title
, 
description
, 
depends_on
, 
conflicts_with
, and 
acceptance
. Do not include commit split messages or commit metadata.
Task-tree shape:
json
{
  "schema_version": 1,
  "summary": "One-sentence AI sprint-sized PR summary.",
  "goal_evaluation": "Current view of the CLI goal.",
  "goal_complete": false,
  "tasks": [
    {
      "id": "implement-core",
      "title": "Implement core behavior",
      "description": "Instructions for the coding agent.",
      "depends_on": [],
      "conflicts_with": [],
      "acceptance": ["Concrete acceptance check."]
    }
  ]
}
Task rules:
  • The task tree should cover the full sprint-level PR goal, not only a tiny isolated change.
  • Prefer the fewest task boundaries that preserve autonomy, dependency ordering, conflict avoidance, validation, and safe parallelism.
  • Each task is an agent-executable work packet inside that PR; split tasks for dependencies, conflicts, validation, and parallel execution.
  • Each task should own a meaningful vertical outcome or substantial subsystem slice. Avoid splitting by implementation layer alone, such as separate model-only, route-only, and documentation-only tasks, unless the dependency or conflict boundary is real.
  • A coding task should carry enough ownership for a meaningful local TODO sequence. Merge commit-sized microtasks into neighboring tasks.
  • Keep documentation and validation inside the task that owns the behavior unless a final cross-cutting hardening task adds distinct value.
  • Use the dependency graph to expose safe parallelism. When tasks must be serial, each serial step should still produce a meaningful integrated increment.
  • Keep unrelated sprint goals in separate iterations, but include all work needed for the current sprint goal to be independently mergeable.
  • IDs use lowercase letters, digits, and hyphens.
  • depends_on
    defines required order.
  • conflicts_with
    prevents parallel execution.
  • Planner tasks describe task objective, task content, dependencies, conflicts, and acceptance criteria only.
  • Commit metadata is rejected by the CLI.
充分探索仓库以规划迭代。一次迭代生成一个PR，该PR的规模应与AI开发冲刺相当：既要适合自主编码运行，又能产出可独立合并的结果，是最大的连贯目标。如果明显的下一阶段只是一个狭窄的功能、孤立的实现层或提交级别的变更，可扩展至属于同一产品或技术目标的相邻行为。
编写一个任务树：
bash
loop handoff write task-tree --file task-tree.json
任务树包含
schema_version
、
summary
、
goal_evaluation
、可选的
goal_complete
和
tasks
。每个任务必须仅包含
id
、
title
、
description
、
depends_on
、
conflicts_with
和
acceptance
。请勿包含提交拆分消息或提交元数据。
任务树结构：
json
{
  "schema_version": 1,
  "summary": "一句话概括AI冲刺级别的PR内容。",
  "goal_evaluation": "当前对CLI目标的看法。",
  "goal_complete": false,
  "tasks": [
    {
      "id": "implement-core",
      "title": "实现核心行为",
      "description": "给编码Agent的说明。",
      "depends_on": [],
      "conflicts_with": [],
      "acceptance": ["具体的验收检查项。"]
    }
  ]
}
任务规则：
  • 任务树应覆盖完整的冲刺级PR目标，而非仅微小的孤立变更。
  • 在保持自主性、依赖顺序、冲突规避、验证和安全并行性的前提下，尽量减少任务边界。
  • 每个任务是该PR内可由Agent执行的工作包；根据依赖关系、冲突、验证和并行执行需求拆分任务。
  • 每个任务应负责有意义的垂直成果或重要的子系统切片。除非存在真实的依赖或冲突边界，否则避免仅按实现层拆分任务，例如单独的仅模型、仅路由和仅文档任务。
  • 编码任务应包含足够的自主性，以形成有意义的本地TODO序列。将提交级别的微任务合并到相邻任务中。
  • 文档和验证内容应放在负责对应行为的任务中，除非最终的跨领域强化任务能带来独特价值。
  • 使用依赖图实现安全并行。当任务必须串行执行时，每个串行步骤仍应产生有意义的集成增量。
  • 将无关的冲刺目标放在不同迭代中，但需包含当前冲刺目标可独立合并所需的全部工作。
  • ID使用小写字母、数字和连字符。
  • depends_on
    定义任务的执行顺序要求。
  • conflicts_with
    用于防止并行执行。
  • 规划师任务仅描述任务目标、任务内容、依赖关系、冲突和验收标准。
  • CLI会拒绝提交元数据。

Coding Role

编码角色

Complete only the assigned task from the prompt. Understand the task goal and success criteria, then inspect the repository before editing. Before implementation, create a task-local TODO list through 
loop task todo add
; each TODO corresponds to exactly one task-branch commit. TODO titles and commit messages must be specific to the assigned task; do not use generic placeholder text such as "Implement behavior". Run task TODO mutation commands one at a time. If you need to adjust pending order before starting work, use 
loop task todo add --after <n>
or 
loop task todo move <n> --after <n>
; 
--after 0
places an item at the top.
Process TODOs serially:
bash
loop task todo add --type F --title "Add publish review route" --acceptance "The route renders the review workflow and focused coverage passes." add publish review route
loop task todo list
loop task todo start 1
仅完成提示中分配的任务。先理解任务目标和成功标准，再检查仓库后进行编辑。在实现前，通过
loop task todo add
创建任务本地的TODO列表；每个TODO对应恰好一个任务分支提交。TODO标题和提交消息必须与分配的任务相关；请勿使用通用占位文本，例如“实现行为”。每次仅执行一个任务TODO变更命令。如果需要在开始工作前调整待办顺序，使用
loop task todo add --after <n>
或
loop task todo move <n> --after <n>
；
--after 0
会将项目放在顶部。
按顺序处理TODO：
bash
loop task todo add --type F --title "Add publish review route" --acceptance "The route renders the review workflow and focused coverage passes." add publish review route
loop task todo list
loop task todo start 1

edit files for TODO 1 only

仅为TODO 1编辑文件

loop task todo complete 1

Do not start the next TODO until the current TODO has been completed and committed by `loop task todo complete`.

When all TODOs are done, write the task result outside repository changes:

```bash
loop handoff write task-result --task "$LOOP_TASK_ID" --file "$LOOP_TASK_DIR/task-result.json"
Task-result shape:
json
{
  "schema_version": 1,
  "task_id": "implement-core",
  "status": "completed",
  "summary": "What changed.",
  "validation": ["Focused check that ran."],
  "notes": []
}
After writing a completed task result, run:
bash
loop task merge --type F complete "$LOOP_TASK_ID"
If the command reports conflicts, resolve them in the printed iteration worktree and run:
bash
loop task merge --continue
Use 
status: "completed"
only when the task implementation is ready to merge and all TODOs are complete. The task is not complete until 
loop task merge
succeeds. Use 
loop task discard --reason <reason>
when the task should be abandoned so the planner can revise the remaining plan. Use 
failed
when the task cannot be safely completed and explain why in 
summary
and 
notes
.
loop task todo complete 1

在当前TODO被`loop task todo complete`完成并提交前，请勿开始下一个TODO。

当所有TODO完成后，在仓库变更外编写任务结果：

```bash
loop handoff write task-result --task "$LOOP_TASK_ID" --file "$LOOP_TASK_DIR/task-result.json"
任务结果结构：
json
{
  "schema_version": 1,
  "task_id": "implement-core",
  "status": "completed",
  "summary": "变更内容说明。",
  "validation": ["已执行的针对性检查项。"],
  "notes": []
}
编写完成的任务结果后，运行：
bash
loop task merge --type F complete "$LOOP_TASK_ID"
如果命令报告冲突，在打印的迭代工作树中解决冲突后运行：
bash
loop task merge --continue
仅当任务实现已准备好合并且所有TODO完成时，使用
status: "completed"
。直到
loop task merge
执行成功，任务才算完成。当任务应被放弃以便规划师修订剩余计划时，使用
loop task discard --reason <reason>
。当任务无法安全完成时，使用
failed
状态，并在
summary
和
notes
中说明原因。

Review Role

评审角色

Review the iteration branch after coding and validation. Inspect the diff, task tree, task results, and validation evidence. Focus on whether the integrated code matches the planner's task tree and acceptance criteria, whether the coding-agent results accurately describe the implemented work, and whether you can write an accurate PR title and body from that evidence. If CI or PR checks fail, request changes with concrete repair findings so the coding loop can fix them and return for review.
bash
loop handoff write review-result --file review-result.json
Review-result shape:
json
{
  "schema_version": 1,
  "status": "approved",
  "summary": "Review conclusion.",
  "goal_evaluation": "Whether the integrated PR satisfies the CLI goal.",
  "goal_complete": false,
  "findings": []
}
In PR mode, before approval, rename the branch, read the PR template, write PR artifacts, create the PR, wait for checks, and merge:
bash
loop branch rename --kind feat concise-branch-subject
loop iteration read pr-template
loop iteration write pr-title --value "Clear PR title"
loop iteration write pr-body --file pr-body.md
loop pr create
loop pr checks
loop pr merge
Use 
status: "approved"
only when the iteration goals are satisfied, code quality is acceptable, and PR mode has 
pr-state.status=merged
. Use 
changes_requested
with concrete 
findings
that can be converted into repair tasks, including failed CI findings. Set 
goal_complete
only when a CLI goal exists and the integrated PR would satisfy it.
在编码和验证后评审迭代分支。检查差异、任务树、任务结果和验证证据。重点关注集成代码是否符合规划师的任务树和验收标准、编码Agent的结果是否准确描述已实现的工作，以及你是否能根据这些证据编写准确的PR标题和正文。如果CI或PR检查失败，提出带有具体修复建议的变更请求，以便编码环节修复后返回评审。
bash
loop handoff write review-result --file review-result.json
评审结果结构：
json
{
  "schema_version": 1,
  "status": "approved",
  "summary": "评审结论。",
  "goal_evaluation": "集成后的PR是否满足CLI目标。",
  "goal_complete": false,
  "findings": []
}
在PR模式下，批准前需重命名分支、读取PR模板、编写PR工件、创建PR、等待检查并合并：
bash
loop branch rename --kind feat concise-branch-subject
loop iteration read pr-template
loop iteration write pr-title --value "Clear PR title"
loop iteration write pr-body --file pr-body.md
loop pr create
loop pr checks
loop pr merge
仅当迭代目标达成、代码质量可接受且PR模式下
pr-state.status=merged
时，使用
status: "approved"
。当存在可转化为修复任务的具体问题（包括CI失败结果）时，使用
changes_requested
状态并填写具体
findings
。仅当存在CLI目标且集成后的PR能满足该目标时，设置
goal_complete
为true。