saga

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Saga

Saga is an autonomous, spec-driven development workflow for medium-to-large features that should be implemented mostly without human intervention, except at a few discrete touch points. You act as the orchestrator: you turn a rough prompt into an airtight spec, then delegate implementation to a fleet of worker subagents while keeping your own context window clean.

The whole method rests on one bet: if the spec defines every task with validation criteria tight enough to form a contract, then workers can execute in parallel and self-verify, and the saga succeeds with almost no human babysitting. The quality of the saga is therefore decided in Phase 1, before a single line is written.

Saga是针对中大型功能的自主、基于规格的开发工作流，开发过程基本无需人工干预，仅在少数特定节点需要人工参与。你将担任Orchestrator（编排代理）：把粗略的需求提示转化为严谨的规格，然后将开发任务委派给一组Worker Subagents（工作子代理），同时保持自身上下文窗口整洁。

整个方法基于一个核心假设：如果规格为每个任务定义的验证标准足够严格，形成一份「契约」，那么工作代理就可以并行执行并自我验证，Saga工作流就能在几乎无需人工看管的情况下成功完成。因此，Saga的质量由第一阶段决定，远在编写第一行代码之前。

Core principles

核心原则

Airtight contracts over good intentions. A task is only ready to delegate when its validation criteria are so explicit that meeting them leaves little-to-no possibility the task was done wrong. Ambiguity is the enemy; resolve it during planning, not during implementation.
No whitespace. During planning, make every requirement explicit. Do not leave decisions to a worker's discretion unless the user has explicitly granted that discretion. Workers should never have to guess what "done" means.
Protect the orchestrator's context. You are the long-lived coordinator. Push heavy reading, research, and implementation onto workers; receive compact reports back. Keep state on disk (in the saga directory's spec tree and
```
PROGRESS.md
```
) so your understanding survives compaction and you can re-read rather than re-hold. This maximizes time-to-compaction and keeps you coherent across the whole run.
Validation is first-class. Every task and the saga as a whole carries verification criteria defined up front, and a concrete method for checking them (computer use, interactive CLI, or tests). See
```
references/validation-strategies.md
```
.
A few human touch points, not zero. The human approves the spec (end of Phase 1), is consulted only when the spec genuinely cannot resolve a blocker (Phase 2), and does the final manual acceptance (Phase 3).

优先严谨契约，而非良好意愿。只有当任务的验证标准足够明确，达到符合标准就几乎不可能出错的程度时，才可以委派任务。模糊性是大敌；要在规划阶段解决模糊问题，而非开发阶段。
无模糊空间。规划阶段要明确所有需求，除非用户明确授权，否则不要让工作代理自行做决策。工作代理永远不需要猜测「完成」的定义。
保护编排代理的上下文。你是长期运行的协调者。将大量阅读、研究和开发工作交给工作代理；仅接收简洁的报告。将状态存储在磁盘上（Saga目录的规格树和
```
PROGRESS.md
```
文件中），这样你的理解不会因上下文压缩而丢失，后续可以重新读取而非一直保留在内存中。这能最大化上下文压缩的间隔时间，确保你在整个工作流中保持连贯。
验证是核心环节。每个任务和整个Saga工作流都预先定义了验证标准，以及具体的检查方法（计算机操作、交互式CLI或测试）。详见
```
references/validation-strategies.md
```
。
少量人工参与，而非零参与。用户需在第一阶段结束时批准规格；仅当规格确实无法解决阻塞问题时才会在第二阶段咨询用户；第三阶段由用户进行最终的人工验收。

The saga directory

Saga目录

Each saga lives in its own directory outside the repo, under

~/.sagas/

, so it survives across orchestrator sessions and can be resumed by a fresh agent. Name it uniquely from a slug of the feature plus a timestamp, e.g.

~/.sagas/dark-mode-20260609-0028/

. Confirm the exact path with the user and record it — it is the saga's stable identity.

The directory holds a tree of spec files plus a progress log. Each level carries its own validation criteria, so detail scales with the size of the saga instead of bloating one file:

~/.sagas/<saga-name>/
├── SAGA.md                      # overview, environment, saga-level exit criteria, milestone index
├── PROGRESS.md                  # live, continuously-updated execution log and current state
└── milestones/
    ├── 01-<slug>/
    │   ├── MILESTONE.md          # milestone spec + milestone-level validation criteria
    │   └── tasks/
    │       ├── 01-<slug>.md      # task spec + task-level validation criteria
    │       └── 02-<slug>.md
    └── 02-<slug>/
        ├── MILESTONE.md
        └── tasks/ ...

SAGA.md

stays small — it indexes the milestones and holds only saga-wide content. Milestone and task specs hold the detail. This is what keeps your context clean: read only the spec for the milestone or task you are currently coordinating, and rely on

PROGRESS.md

for state rather than re-deriving it.

Use the templates and field definitions in

references/saga-spec-template.md

verbatim. Read it before drafting specs.

每个Saga都存放在仓库外部的独立目录中，路径为

~/.sagas/

，这样即使编排代理会话结束，Saga也能保留，并且可以由新的代理恢复。目录名称由功能缩写加上时间戳构成，确保唯一性，例如

~/.sagas/dark-mode-20260609-0028/

。请与用户确认准确路径并记录下来——这是Saga的稳定标识。

该目录包含一组规格文件以及进度日志。每个层级都有自己的验证标准，细节会随Saga的规模扩展，不会导致单个文件过于臃肿：

~/.sagas/<saga-name>/
├── SAGA.md                      # 概述、环境信息、Saga级验收标准、里程碑索引
├── PROGRESS.md                  # 实时更新的执行日志和当前状态
└── milestones/
    ├── 01-<slug>/
    │   ├── MILESTONE.md          # 里程碑规格 + 里程碑级验证标准
    │   └── tasks/
    │       ├── 01-<slug>.md      # 任务规格 + 任务级验证标准
    │       └── 02-<slug>.md
    └── 02-<slug>/
        ├── MILESTONE.md
        └── tasks/ ...

SAGA.md

保持简洁——它只索引里程碑并存储Saga全局内容。里程碑和任务的细节分别存放在对应的规格文件中。这是保持你上下文整洁的关键：仅读取当前协调的里程碑或任务的规格文件，依赖

PROGRESS.md

获取状态，而非重新推导。

请严格使用

references/saga-spec-template.md

中的模板和字段定义。起草规格前请先阅读该文件。

Phase 1 — Planning & spec generation (orchestrator + user)

第一阶段 — 规划与规格生成（编排代理 + 用户）

Goal: produce a comprehensive, unambiguous saga spec tree. This phase is fully collaborative with the user. It ends only when the user approves the spec.

When asking the user anything in this phase, always use the
ask_user_question
tool and provide concrete options (single- or multi-select) rather than open-ended questions. Set a

recommended_option_index

when there is a sensible default. Open-ended prose questions slow the user down and invite vague answers; options force crisp decisions.

目标：生成完整、无歧义的Saga规格树。此阶段完全与用户协作，仅在用户批准规格后结束。

在此阶段向用户提问时，务必使用
ask_user_question
工具并提供具体选项（单选或多选），而非开放式问题。如果有合理的默认选项，请设置

recommended_option_index

。开放式文字问题会拖慢用户速度并导致模糊的回答；选项则能促使用户做出明确决策。

1. Intake and frame

1. 需求接收与梳理

Restate the request as a one-paragraph problem statement and the rough shape of the feature. Identify the major unknowns you will need to close. Pick a unique saga directory path under

~/.sagas/

(feature slug + timestamp), confirm it with the user, and create it; everything below is written there.

将用户请求重述为一段问题说明，并描述功能的大致形态。找出需要明确的主要未知项。在

~/.sagas/

下选择一个唯一的Saga目录路径（功能缩写+时间戳），与用户确认后创建该目录；后续所有内容都将写入此目录。

2. Establish machine & runtime capabilities

2. 确认机器与运行时能力

You cannot define realistic validation criteria without knowing what can actually be tested on this machine and against this program. Determine, by inspecting the repo and environment first and asking the user only for what you cannot discover:

What kind of program is this? Web app, native GUI, TUI, CLI/library, backend service, etc. This dictates the validation method (see
```
references/validation-strategies.md
```
).
Is computer use available? Check whether a computer-use / browser-automation capability is available to you or to cloud workers. If GUI/web validation is needed but computer use is only available remotely, plan to route that validation through remote workers.
What is the test/build toolchain? Discover the test runner, build, lint, and typecheck commands (e.g. from README, CI config, package manifests, project rules). Confirm they run.
How is the program run/launched for manual or interactive verification?

Record these findings in

SAGA.md

under the environment section — workers and any future orchestrator rely on them.

如果不了解当前机器和程序的实际可测试能力，就无法定义合理的验证标准。首先检查仓库和环境，仅向用户询问无法自行发现的信息：

这是什么类型的程序？ Web应用、原生GUI、TUI、CLI/库、后端服务等。这将决定验证方法（详见
```
references/validation-strategies.md
```
）。
是否支持计算机操作？ 检查你或云端工作代理是否具备计算机操作/浏览器自动化能力。如果需要GUI/Web验证但仅远程支持计算机操作，则计划通过远程工作代理完成该验证。
测试/构建工具链是什么？ 找出测试运行器、构建、代码检查和类型检查命令（例如从README、CI配置、包清单、项目规则中获取）。确认这些命令可以正常运行。
如何启动程序以进行手动或交互式验证？

将这些发现记录在

SAGA.md

的环境部分——工作代理和未来的编排代理都会依赖这些信息。

3. Close every gap of ambiguity

3. 消除所有模糊点

Iterate with the user, via

ask_user_question

with options, until there is no whitespace left in the requirements: behavior, scope boundaries, edge cases, data shapes, error handling, non-goals, and acceptance bar. Batch related questions (max 4 per call). Stop only when the remaining decisions are either resolved or explicitly delegated to your discretion by the user.

通过

ask_user_question

工具并提供选项，与用户反复沟通，直到需求中没有模糊空间：包括行为、范围边界、边缘情况、数据结构、错误处理、非目标需求和验收标准。将相关问题批量提出（每次最多4个）。仅当剩余决策已解决或用户明确授权你自行决定时才停止。

4. Define the saga exit criteria

4. 定义Saga验收标准

Before decomposing, write the saga-level exit criteria: the concrete, checkable conditions that mean the entire feature is done and correct. These are the contract for the whole saga and the basis for Phase 3.

在拆解任务之前，先编写Saga级验收标准：即整个功能完成且正确的具体、可检查条件。这是整个Saga的契约，也是第三阶段的基础。

5. Decompose into milestones and tasks

5. 拆解为里程碑和任务

Break the work into milestones (coherent, independently meaningful chunks, ordered by dependency) and within each, tasks scoped so a single worker agent can complete one in one focused effort. For each task specify: scope, owned files/surfaces, dependencies on other tasks, and validation criteria + validation method. Shape the topology pragmatically around the feature's real dependencies — maximize tasks that can run in parallel within a milestone, and sequence milestones where later work depends on earlier work.

Write this out as the spec tree in the saga directory: the milestone index and saga exit criteria in

SAGA.md

, each milestone's detail and milestone-level validation criteria in its

MILESTONE.md

, and each task's detail and validation criteria in its own task spec file. Each task's validation criteria must be airtight per

references/validation-strategies.md

. If you cannot write airtight criteria for a task, the task is under-specified — split it or go back to the user.

将工作拆解为里程碑（连贯、独立有意义的模块，按依赖关系排序），每个里程碑下再拆解为任务，任务的范围应确保单个工作代理可以在一次专注的工作中完成。为每个任务指定：范围、负责的文件/界面、对其他任务的依赖，以及验证标准 + 验证方法。根据功能的实际依赖关系合理设计拓扑结构——最大化每个里程碑内可并行执行的任务数量，对存在依赖的里程碑按顺序执行。

将这些内容写入Saga目录的规格树：

SAGA.md

中包含里程碑索引和Saga验收标准，每个里程碑的细节和里程碑级验证标准写入对应的

MILESTONE.md

，每个任务的细节和验证标准写入对应的任务规格文件。每个任务的验证标准必须符合

references/validation-strategies.md

中的严谨要求。如果无法为某个任务编写严谨的验证标准，则说明该任务规格不足——需拆分任务或再次咨询用户。

6. Get approval

6. 获取批准

Present the saga spec — walk the user through

SAGA.md

and the milestone/task specs — and ask them to approve or request changes (via

ask_user_question

). Do not begin Phase 2 until the user approves. This is the primary human checkpoint.

向用户展示Saga规格——引导用户查看

SAGA.md

以及里程碑/任务规格文件——并请求用户批准或提出修改（通过

ask_user_question

工具）。在用户批准前不要开始第二阶段。这是主要的人工检查点。

Phase 2 — Implementation & validation (worker fleet, looped)

第二阶段 — 开发与验证（工作代理集群，循环执行）

Goal: execute every task to its validation criteria, milestone by milestone, delegating to workers and keeping yourself lean. The user is involved here only if a blocker cannot be resolved from the spec.

目标：按照验证标准完成所有任务，逐个里程碑推进，将任务委派给工作代理并保持自身轻量化。仅当规格无法解决阻塞问题时才会让用户参与。

Orchestration mechanics

编排机制

Delegate, don't implement. Use
```
run_agents
```
to launch workers. You coordinate; you do not write feature code yourself. This is what protects your context.
Batch by parallelism. Within a milestone, launch all independent tasks as one
```
run_agents
```
batch (shared
```
base_prompt
```
, per-task
```
prompt
```
). Run dependent milestones in sequence. Use a Mermaid/DAG mental model from the task dependencies.
Isolate local workers. When workers modify the same repo, give each its own git worktree and branch. Follow the saga branch naming convention so every branch is traceable back to its saga directory, milestone, and task without consulting
```
PROGRESS.md
```
:
```
saga/<saga-name>/m<M>t<T>-<task-slug>
```
Example:
```
saga/dark-mode-20260609-0028/m1t2-setup-tokens
```
. Create with:
```
git worktree add ../saga-<saga-name>-m<M>t<T> -b saga/<saga-name>/m<M>t<T>-<task-slug> <base>
```
If your team or repo has a branch-prefix convention (e.g. a per-user prefix like
```
<username>/
```
, or a required prefix enforced by CI), prepend it consistently while keeping the
```
saga/<saga-name>/...
```
structure intact so branches stay filterable. Workers must never share a checkout or work on the user's current branch. Decide the merge strategy up front (typically: integrate each milestone's branches at the milestone boundary). Worker changes must be committed, pushed, or otherwise durably handed off before any worktree is removed.
To list all branches for a saga:
```
git branch --list '*saga/<saga-name>/*'
```
Remote workers for computer use. If a task's validation needs computer use and it is only available remotely, launch that worker (or its validation step) remotely with computer use enabled, and have it return a durable artifact (pushed branch, draft PR, or a compact patch/diff) rather than leaving work only in the remote environment.

委派任务，而非自行开发。使用
```
run_agents
```
启动工作代理。你负责协调；不要自行编写功能代码。这是保护你上下文的关键。
按并行性批量处理。在一个里程碑内，将所有独立任务作为一个
```
run_agents
```
批次启动（共享
```
base_prompt
```
，每个任务有单独的
```
prompt
```
）。存在依赖的里程碑按顺序执行。根据任务依赖关系采用Mermaid/DAG的思维模型。
隔离本地工作代理。当工作代理修改同一个仓库时，为每个代理分配独立的git工作树和分支。遵循Saga分支命名规范，这样无需查看
```
PROGRESS.md
```
就能将每个分支追溯到对应的Saga目录、里程碑和任务：
```
saga/<saga-name>/m<M>t<T>-<task-slug>
```
示例：
```
saga/dark-mode-20260609-0028/m1t2-setup-tokens
```
。创建命令：
```
git worktree add ../saga-<saga-name>-m<M>t<T> -b saga/<saga-name>/m<M>t<T>-<task-slug> <base>
```
如果你的团队或仓库有分支前缀规范（例如每个用户的前缀
```
<username>/
```
，或CI强制要求的前缀），请在保持
```
saga/<saga-name>/...
```
结构的前提下统一添加前缀，以便分支可被过滤。工作代理绝不能共享同一个检出目录或在用户当前分支上工作。预先决定合并策略（通常：在每个里程碑边界整合该里程碑的所有分支）。工作代理的修改必须在删除工作树之前提交、推送或以其他方式持久化移交。
列出某个Saga的所有分支：
```
git branch --list '*saga/<saga-name>/*'
```
远程工作代理处理计算机操作。如果某个任务的验证需要计算机操作且仅远程支持，则启动具备计算机操作能力的远程工作代理（或其验证步骤），并让它返回持久化的成果（推送的分支、草稿PR或简洁的补丁/差异），而非仅将工作留在远程环境中。

The per-task contract given to each worker

给每个工作代理的任务契约

Put shared rules in

base_prompt

(repo path, base branch, toolchain commands, coding standards, the validation method, how to report back) and the specific task in each per-worker

prompt

. Instruct every worker to:

Implement only its assigned task and owned files.
Self-validate in a loop against the task's validation criteria using the prescribed method (computer use / interactive CLI subagent / unit + integration tests). Iterate fix→validate until all criteria pass or it is genuinely blocked.
Create a durable handoff before cleanup. For local git worktree tasks, commit the validated changes to the task branch and make sure the branch is visible to the orchestrator. For remote tasks, push the branch, open a draft PR, or return a complete patch/diff; do not leave the only copy of the work in a remote checkout. If blocked with partial useful work, preserve it as a WIP commit or patch before reporting; if no partial work is worth preserving, say so explicitly.
Remove the worktree only after the durable handoff exists:
```
git worktree remove <worktree-path> --force
```
. The branch or patch persists; the worktree does not. Stale worktrees are unacceptable, but cleanup must never be allowed to discard the only copy of validated or useful partial work.
Report back compactly: branch name, commit hash or patch/pushed-branch artifact, changed files, the validation evidence (test output, screenshots, CLI transcript), and a clear pass/blocked status. Keep findings terse — you are protecting context.

See

references/validation-strategies.md

for choosing and applying the validation method and for what counts as sufficient evidence.

将共享规则放在

base_prompt

中（仓库路径、基础分支、工具链命令、编码标准、验证方法、反馈方式），每个工作代理的具体任务放在单独的

prompt

中。指示每个工作代理：

仅实现分配的任务和负责的文件。
循环自我验证：按照指定方法（计算机操作/交互式CLI子代理/单元+集成测试）对照任务的验证标准进行验证。反复执行「修复→验证」直到所有标准通过或确实遇到阻塞。
清理前创建持久化移交。对于本地git工作树任务，将验证通过的修改提交到任务分支，并确保编排代理可以看到该分支。对于远程任务，推送分支、打开草稿PR或返回完整的补丁/差异；不要将工作的唯一副本留在远程检出目录中。如果遇到阻塞但已有部分有用工作，请在反馈前将其保存为WIP提交或补丁；如果没有值得保留的部分工作，请明确说明。
仅在持久化移交完成后删除工作树：
```
git worktree remove <worktree-path> --force
```
。分支或补丁会保留；工作树则删除。不允许存在过时的工作树，但清理绝不能丢弃验证通过或有用的部分工作的唯一副本。
简洁反馈：分支名称、提交哈希或补丁/推送分支成果、修改的文件、验证证据（测试输出、截图、CLI记录），以及明确的通过/阻塞状态。保持反馈简洁——这是为了保护上下文。

选择和应用验证方法以及确定足够证据的标准，请参阅

references/validation-strategies.md

。

The orchestration loop

编排循环

For each milestone, in order:

Launch the milestone's parallelizable tasks as worker(s). Immediately record each worker's addressable agent/run ID in
```
PROGRESS.md
```
alongside its task, branch, and worktree. Display names are not sufficient for resume; a fresh orchestrator needs the run ID to message an in-progress worker.
Collect reports as they arrive (read the worker's message content; don't rely on lifecycle success alone). Update
```
PROGRESS.md
```
in the saga directory with per-task status and evidence pointers.
Handle blocked tasks. If a worker can't meet its criteria, decide: re-scope and re-delegate to the same worker (it retains context), adjust the task in its task spec file, or — only if the blocker is a genuine spec gap or external decision — escalate to the user with options. Prefer not to escalate; the spec should usually have the answer.
Integrate and run milestone-level validation. Merge the milestone's branches into the integration branch, resolve conflicts, and verify the milestone holds together (run the relevant tests/validation across the integrated result). If any worker left a worktree behind despite instructions, remove it now (
```
git worktree remove <path> --force
```
) before proceeding.
Move to the next milestone.

Re-read the relevant spec files and

PROGRESS.md

from disk whenever you need state instead of holding it in context. Keep

PROGRESS.md

updated as you go — it is the source of truth a fresh orchestrator uses to resume the saga, so a stale log means a lost saga. If you sense your context filling, write a concise progress checkpoint to

PROGRESS.md

first.

按顺序处理每个里程碑：

将里程碑中可并行执行的任务作为工作代理启动。立即将每个工作代理的可寻址Agent/运行ID记录在
```
PROGRESS.md
```
中，与对应的任务、分支和工作树一起。显示名称不足以恢复任务；新的编排代理需要运行ID才能向正在执行的工作代理发送消息。
接收工作代理的报告（读取工作代理的消息内容；不要仅依赖生命周期状态）。在Saga目录的
```
PROGRESS.md
```
中更新每个任务的状态和证据指针。
处理阻塞的任务。如果工作代理无法满足验证标准，决定：重新调整范围并重新委派给同一个工作代理（它保留上下文）、修改任务规格文件中的任务内容，或者——仅当阻塞是真正的规格缺口或外部决策问题时——向用户提交选项进行升级处理。尽量避免升级；规格通常应包含解决方案。
整合并执行里程碑级验证。将里程碑的所有分支合并到集成分支，解决冲突，并验证里程碑的整体完整性（对整合结果运行相关测试/验证）。如果有工作代理未按指示删除工作树，请在此阶段删除（
```
git worktree remove <path> --force
```
）后再继续。
进入下一个里程碑。

每当需要状态时，从磁盘读取相关的规格文件和

PROGRESS.md

，而非保留在上下文中。持续更新

PROGRESS.md

——这是新编排代理恢复Saga的事实来源，过时的日志意味着Saga状态丢失。如果感觉上下文已满，请先向

PROGRESS.md

写入简洁的进度检查点。

Phase 3 — Final validation (orchestrator + user)

第三阶段 — 最终验证（编排代理 + 用户）

Goal: confirm the saga's exit criteria are met, then hand off to the user for manual acceptance.

Run the full saga-level exit criteria using the strongest available method (computer use for GUI/web, interactive CLI for TUIs, the full test/integration suite otherwise). Summarize the evidence against each exit criterion.
Present the user a concise completion report: what was built, how each exit criterion was validated, and exact steps for them to manually verify (how to run/launch, what to look for).
Loop in the user for manual acceptance via
```
ask_user_question
```
: accept, or report specific issues. If they report issues, capture them as new tasks, run a focused Phase 2 mini-loop (delegate → self-validate → integrate), and re-present. Repeat until the user accepts.

Only consider the saga complete when the user confirms acceptance.

目标：确认Saga的验收标准已满足，然后移交用户进行人工验收。

使用最可靠的方法运行完整的Saga级验收标准（GUI/Web应用使用计算机操作，TUI使用交互式CLI，其他情况使用完整的测试/集成套件）。总结每个验收标准的验证证据。
向用户提交简洁的完成报告：构建的内容、每个验收标准的验证方式，以及用户手动验证的具体步骤（如何启动程序、需要检查的内容）。
邀请用户进行人工验收：通过
```
ask_user_question
```
工具让用户选择接受或报告具体问题。如果用户报告问题，将其记录为新任务，运行一个聚焦的第二阶段迷你循环（委派→自我验证→整合），然后再次提交报告。重复此过程直到用户接受。

只有当用户确认接受后，才认为Saga工作流完成。

Resuming a saga

恢复Saga

Because the saga directory and

PROGRESS.md

live outside the repo and capture full state, a saga can be picked up by a fresh orchestrator at any time (after compaction, a new session, or a handoff). When asked to continue, resume, or pick up a saga, read
references/continuing-a-saga.md
and follow it.

由于Saga目录和

PROGRESS.md

存放在仓库外部并记录了完整状态，Saga可以在任何时候由新的编排代理接手（上下文压缩后、新会话中或移交后）。当用户要求继续、恢复或接手某个Saga时，请阅读
references/continuing-a-saga.md
并按照其中的步骤操作。

Practical notes

实用提示

Never commit or open PRs unless the user asks; follow the repo's version-control rules when you do.
Keep the spec tree current — if implementation forces a change to scope or criteria, update the relevant spec file rather than letting it drift.
For very large sagas (≈10+ concurrent workers), prefer remote execution so you don't exhaust the user's machine.
Don't expose internal worker agent IDs in user-facing summaries unless asked.

除非用户要求，否则不要提交或打开PR；如果需要，请遵循仓库的版本控制规则。
保持规格树更新——如果开发过程导致范围或标准发生变化，请更新相关的规格文件，而非让其与实际情况脱节。
对于非常大的Saga（约10个以上并发工作代理），优先使用远程执行，以免耗尽用户机器的资源。
除非用户要求，否则不要在面向用户的总结中暴露内部工作代理的ID。

Reference files

参考文件

```
references/saga-spec-template.md
```
— the saga directory layout and the exact templates for
```
SAGA.md
```
,
```
MILESTONE.md
```
, task specs, and
```
PROGRESS.md
```
. Read before drafting specs.
```
references/validation-strategies.md
```
— how to choose a validation method, write airtight criteria, and gather sufficient evidence. Read during Phase 1 (criteria) and Phase 2 (execution).
```
references/continuing-a-saga.md
```
— how a fresh orchestrator picks up an existing saga directory and resumes safely. Read when asked to continue/resume a saga.

```
references/saga-spec-template.md
```
— Saga目录布局以及
```
SAGA.md
```
、
```
MILESTONE.md
```
、任务规格和
```
PROGRESS.md
```
的精确模板。起草规格前请阅读。
```
references/validation-strategies.md
```
— 如何选择验证方法、编写严谨的验证标准以及收集足够的证据。第一阶段（标准定义）和第二阶段（执行）请阅读。
```
references/continuing-a-saga.md
```
— 新编排代理如何接手现有Saga目录并安全恢复工作。当用户要求继续/恢复Saga时请阅读。