execute-chat

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Execute Chat

Protocol

协议

Step 0 — Readiness gate

步骤0 — 就绪检查

Judge the chat and verified evidence against two lenses without reopening settled points.

WHAT is clear (product lens):

Outcome: what changes for the user or system.
Scope: what is in and out.
Behavior: the user-visible behavior and material edge cases.

HOW is decided (tech lens):

Approach: chosen, with alternatives rejected for stated reasons.
Fit: follows the existing architecture and patterns; deviations are justified.
Decisions: data shapes, code locations, and affected interfaces are locked.
Evidence: load-bearing claims are verified against source.
Risks: mitigated or explicitly accepted.

Route by gap size:

All settled — confirm in one line each and proceed.
Small gaps — ask 1–3 targeted questions via
```
AskUserQuestion
```
, then proceed.
WHAT genuinely open — stop; confirm with the user, then invoke the
```
product-interview
```
skill via the Skill tool.
HOW genuinely open — stop; confirm with the user, then invoke the
```
tech-design
```
skill via the Skill tool.
Both open —
```
product-interview
```
first.

**Readiness:**
- WHAT: [settled — one line | gaps: …]
- HOW: [settled — one line | gaps: …]
- Proceeding | Asking | Routing to [skill]

无需重新讨论已确定的事项，从两个维度判断聊天内容和已验证的依据。

明确的内容（产品维度）：

成果： 用户或系统将发生的变化。
范围： 包含和排除的内容。
行为： 用户可见的行为及关键边缘案例。

确定的实现方式（技术维度）：

方案： 已选定的方案，且已说明拒绝其他备选方案的理由。
适配性： 符合现有架构和模式；如有偏差需说明理由。
决策： 数据结构、代码位置及受影响的接口已确定。
依据： 关键主张已对照源码验证。
风险： 已采取缓解措施或被明确接受。

根据缺口大小进行分流：

全部确定 — 每项用一句话确认后继续执行。
小缺口 — 通过
```
AskUserQuestion
```
提出1-3个针对性问题，然后继续执行。
产品维度存在未明确事项 — 停止执行；与用户确认后，通过Skill工具调用
```
product-interview
```
技能。
技术维度存在未明确事项 — 停止执行；与用户确认后，通过Skill工具调用
```
tech-design
```
技能。
两者均未明确 — 先调用
```
product-interview
```
。

**就绪状态：**
- 产品维度：[已确定 — 一句话概述 | 缺口：……]
- 技术维度：[已确定 — 一句话概述 | 缺口：……]
- 执行中 | 询问中 | 分流至[技能]

Step 1 — Plan from the chat

步骤1 — 从聊天内容生成计划

Create one task per agreed item; add nothing else.
Group tasks into dependency-ordered, file-disjoint waves; put consumers in later waves.
Review once after all waves unless the user objects. Review each wave when later work depends on its untested output or shared contracts.
Use
```
TaskCreate
```
for each wave, review, working gate, comments + durable docs, and commit. Do not create entries for build subagents or the done report.

**Plan:**
- Tasks: [n], waves: [wave → tasks, one line per wave]
- Review cadence: [at end | per wave] — [one-line reason]

为每个商定事项创建一个任务；不得添加其他内容。
按依赖顺序、文件不重叠的批次对任务进行分组；将依赖方放在后续批次中。
除非用户反对，否则在所有批次完成后进行一次审查。若后续工作依赖某批次未测试的输出或共享约定，则需对该批次进行审查。
对每个批次、审查、工作检查点、注释+持久化文档以及提交操作使用
```
TaskCreate
```
。不得为构建子代理或完成报告创建条目。

**计划：**
- 任务数：[n]，批次数：[批次 → 任务，每批次一句话]
- 审查节奏：[最终审查 | 逐批审查] — [一句话理由]

Step 2 — Build waves

步骤2 — 执行批次任务

Use the requested model; otherwise select one per logical task:

Sonnet — only when every condition holds:
- The edit is fully specified and follows an existing pattern.
- Assigned files are known and bounded.
- Behavior, architecture, and contracts require no unresolved choice.
- It touches no schema, migration, auth, security, concurrency, payments, destructive data, or public, shared, or external interface.
- The dispatch includes a verification check.
Opus — otherwise.
Grouped work: classify a subagent's full assignment; any Opus condition selects Opus.
Escalation: upgrade Sonnet to Opus when new scope, coupling, or ambiguity appears; never downgrade the task.

For each wave, launch one subagent per logical task in parallel. Give each subagent its task, file paths, and these rules:

Before the first write, resolve each target path and read its governing repository instructions and Claude path rules in
```
.claude/rules/
```
whose quoted
```
paths:
```
globs match it; use the intended path for a new file.
Edit assigned files only; report any needed extra file before editing.
Scope Git reads and mutations to assigned files; never run
```
git stash
```
,
```
git checkout -- .
```
,
```
git reset
```
, or another whole-tree mutation.
Read a committed baseline without changing shared state with
```
git show HEAD:<path>
```
.
Write a comment only for what the code cannot say: a constraint, assumption, or coupling.
Run the narrowest check that proves the assigned change, plus directly affected tests; reserve broader checks for Step 4.
Do not commit.
Return
```
{ files_changed, summary }
```
.

Accept each wave in order:

Read its actual working-tree diff:
```
git diff -- <reported files>
```
.
Add its
```
files_changed
```
to the running scope for later diffs and the docs pass.
If it needs another file, rerun that task serially with the file included.

使用指定的模型；否则为每个逻辑任务选择合适的模型：

Sonnet — 仅当所有条件满足时使用：
- 编辑内容已完全明确且符合现有模式。
- 分配的文件已知且范围明确。
- 行为、架构和约定无需进行未决选择。
- 不涉及 schema、迁移、认证、安全、并发、支付、破坏性数据或公共、共享、外部接口。
- 调度包含验证检查。
Opus — 其他情况使用。
分组工作： 对某个子代理的完整任务进行分类；只要满足任一Opus条件则选择Opus。
升级： 当出现新范围、耦合或歧义时，将Sonnet升级为Opus；不得降级任务。

对于每个批次，为每个逻辑任务并行启动一个子代理。为每个子代理提供其任务、文件路径及以下规则：

在首次写入前，解析每个目标路径并读取
```
.claude/rules/
```
中引用的
```
paths:
```
通配符匹配该路径的仓库规则和Claude路径规则；新文件使用预期路径。
仅编辑分配的文件；如需额外文件，需在编辑前报告。
将Git读取和变更范围限制在分配的文件内；切勿执行
```
git stash
```
、
```
git checkout -- .
```
、
```
git reset
```
或其他全树变更操作。
使用
```
git show HEAD:<path>
```
读取已提交的基线，不改变共享状态。
仅为代码无法表达的内容添加注释：约束条件、假设或耦合关系。
运行最窄范围的检查以验证分配的变更，加上直接受影响的测试；将更广泛的检查留到步骤4进行。
不要提交。
返回
```
{ files_changed, summary }
```
。

按顺序接受每个批次：

读取实际工作树差异：
```
git diff -- <reported files>
```
。
将其
```
files_changed
```
添加到后续差异和文档处理的运行范围中。
若需要其他文件，重新串行执行包含该文件的任务。

Fix-loop packet

修复循环数据包

Every

fix-verify-loop

invocation in Steps 3–4 passes:

Findings: Confirmed P0/P1 findings with their
```
validated_by
```
value and verdict evidence.
Artifact paths: The run's collected files. A finding or its evidence may identify another path, but editing it requires the fix-loop scope-expansion gate.
Criteria: Each finding's criterion plus the relevant settled WHAT and HOW facts from the readiness gate. A working-gate failure also includes the expected verification or live-test result.

步骤3-4中每次调用

fix-verify-loop

时需传递：

发现的问题： 已确认的P0/P1级问题及其
```
validated_by
```
值和判定依据。
工件路径： 本次运行收集的文件。某个问题或其依据可能指向其他路径，但编辑该路径需经过修复循环范围扩展检查。
判定标准： 每个问题的判定标准，加上就绪检查中已确定的相关产品维度和技术维度事实。工作检查点失败还需包含预期的验证或实时测试结果。

Post-fix review

修复后审查

After all fixes for one review or working-gate failure are accepted, union their returned

files_changed

<fix files>

and select one regression scope:

Scope	Use when	Action
Bounded	Every condition holds: at most 5 fix files and 400 changed lines in their working-tree diff from `HEAD` ; no schema, migration, auth, security, concurrency, payment, destructive-data, or shared-interface change; clear affected WHAT/HOW facts, callers, and consumers.	Invoke the `two-pass-review` skill via the Skill tool over `git diff HEAD -- <fix files>` , licensed to inspect affected callers and consumers.
Whole run	Any Bounded condition fails or its evidence is unclear.	Invoke the `two-pass-review` skill via the Skill tool over `git diff HEAD -- <run files>` .

Run this gate once per review or working-gate failure. Give the reviewer the addressed findings and initial-review evidence; ask only whether the fixes caused regressions. Reuse unaffected initial evidence. Resolve confirmed regressions with the same Fix-loop packet without another automatic post-fix review.

在完成一次审查或工作检查点失败的所有修复并接受后，将返回的

files_changed

合并为

<fix files>

，并选择一个回归检查范围：

范围	适用场景	操作
限定范围	满足所有条件：最多5个修复文件，且与 `HEAD` 相比工作树差异不超过400行变更；无schema、迁移、认证、安全、并发、支付、破坏性数据或共享接口变更；明确受影响的产品/技术维度事实、调用方和依赖方。	通过Skill工具对 `git diff HEAD -- <fix files>` 调用 `two-pass-review` 技能，允许检查受影响的调用方和依赖方。
全量运行范围	不满足限定范围的任一条件或依据不明确。	通过Skill工具对 `git diff HEAD -- <run files>` 调用 `two-pass-review` 技能。

每次审查或工作检查点失败后运行一次此检查。向审查者提供已处理的问题和初始审查依据；仅询问修复是否导致回归。复用未受影响的初始依据。使用相同的修复循环数据包解决已确认的回归，无需再次自动进行修复后审查。

Step 3 — Review

步骤3 — 审查

At the Step 1 cadence, invoke the
```
two-pass-review
```
skill via the Skill tool over
```
git diff -- <run files>
```
or the current wave's files.
Invoke the
```
fix-verify-loop
```
skill via the Skill tool with the Fix-loop packet for confirmed P0/P1 findings.
After every fix-loop run, add its returned
```
files_changed
```
—the authoritative path list—to the run's collected files before the next review, docs pass, or commit.
Resolve every fix-loop escalation and its staged changes with the user before continuing.
Fix P2 findings required by the agreed scope; dispatch non-small fixes to a build subagent and defer other P2/P3 findings.
Send out-of-scope findings to the done report's deferred list.
If the initial review produced fixes, run Post-fix review.

按照步骤1的节奏，通过Skill工具对
```
git diff -- <run files>
```
或当前批次的文件调用
```
two-pass-review
```
技能。
针对已确认的P0/P1级问题，通过Skill工具调用
```
fix-verify-loop
```
技能并传入修复循环数据包。
每次修复循环运行后，将返回的
```
files_changed
```
（权威路径列表）添加到运行收集的文件中，再进行下一次审查、文档处理或提交。
在继续执行前，解决所有修复循环升级及其暂存变更的问题。
修复商定范围内要求的P2级问题；将非小型修复分配给构建子代理，推迟处理其他P2/P3级问题。
将超出范围的问题添加到完成报告的推迟列表中。
若初始审查产生了修复，运行修复后审查。

Step 4 — Working gate

步骤4 — 工作检查点

Choose the smallest verification level that covers the current risk:

Level	When	Scope
Focused	During each task and finding fix.	The narrowest test that proves the change, plus directly affected tests.
Subsystem	After a coupled wave or fix group when later work depends on it or focused checks cannot prove the interaction.	The smallest relevant subsystem suite.
Full	Once after review fixes stabilize the run and known overlapping edits to the code or test corpus settle.	Every applicable project-wide verification command.

Early Full: escalate only for shared test infrastructure, order dependence, or a defect reproducible only in the full suite.
Harness exit: if test bodies pass but the harness fails to exit, stop trying equivalent runner modes unless a new hypothesis distinguishes the rerun; use Fix/Accept/Abort below and record harness debt only on Accept.

After Full passes, classify later edits:

Later edit	Required verification
Documentation or comments only	Reuse the Full evidence.
Local code with a clear blast radius	Always rerun Focused; add Subsystem only for a coupled local interaction; reuse the unaffected Full evidence.
Shared interface, test infrastructure, order/global state, multiple subsystems, or unclear blast radius	Rerun Focused and Full.

meta/workflows/automated-testing/automated-testing-instructions.md

exists, use it to test the implemented behavior when relevant.

If verification or live testing fails, ask the user whether to fix, accept, or abort:
- Fix → create a confirmed finding. Set
```
validated_by: "machine"
```
  only for an exact automated check and observed failure; otherwise set
```
validated_by: null
```
  . Invoke
```
fix-verify-loop
```
  with the Fix-loop packet; add its returned files to the collected scope; resolve every escalation and staged-change choice; run Post-fix review; rerun the working gate.
- Accept → carry the risk in the done report.
- Abort → stop.

选择覆盖当前风险的最小验证级别：

级别	适用场景	范围
聚焦式	在每个任务和问题修复期间。	验证变更的最窄范围测试，加上直接受影响的测试。
子系统级	在耦合批次或修复组完成后，若后续工作依赖于它，或聚焦式检查无法验证交互。	最小相关子系统套件。
全量	在审查修复稳定运行后，且已知的代码或测试 corpus 重叠编辑已确定时，运行一次。	所有适用的项目级验证命令。

提前全量验证： 仅在共享测试基础设施、顺序依赖或仅在全量套件中可复现的缺陷情况下升级。
测试框架退出： 若测试用例通过但框架无法退出，除非有新假设区分重新运行，否则停止尝试等效运行模式；使用下方的修复/接受/终止选项，并仅在接受时记录框架债务。

全量验证通过后，对后续编辑进行分类：

后续编辑	所需验证
仅文档或注释	复用全量验证依据。
具有明确影响范围的本地代码	始终重新运行聚焦式验证；仅在存在耦合本地交互时添加子系统级验证；复用未受影响的全量验证依据。
共享接口、测试基础设施、顺序/全局状态、多个子系统或影响范围不明确	重新运行聚焦式和全量验证。

若

meta/workflows/automated-testing/automated-testing-instructions.md

存在，相关时使用它测试已实现的行为。

若验证或实时测试失败，询问用户是修复、接受还是终止：
- 修复 → 创建已确认的问题。仅当通过精确自动化检查观察到失败时，设置
```
validated_by: "machine"
```
  ；否则设置
```
validated_by: null
```
  。调用
```
fix-verify-loop
```
  并传入修复循环数据包；将返回的文件添加到收集范围；解决所有升级和暂存变更选择；运行修复后审查；重新运行工作检查点。
- 接受 → 在完成报告中记录该风险。
- 终止 → 停止执行。

Step 5 — Comments and durable docs

步骤5 — 注释与持久化文档

Invoke the

durable-docs-update

skill via the Skill tool inline with:

scope — the run's collected
```
files_changed
```
(Mode C, caller-supplied);
change content — the working-tree
```
git diff HEAD -- <those files>
```
;
context — what the chat agreed this work was for.

通过Skill工具内联调用

durable-docs-update

技能，并传入：

scope — 本次运行收集的
```
files_changed
```
（模式C，调用方提供）；
change content — 工作树中
```
git diff HEAD -- <those files>
```
的差异；
context — 聊天中商定的本次工作目的。

Step 6 — Final gate and commit

步骤6 — 最终检查与提交

Read the final scoped diff and confirm every review and docs decision is resolved.
Run only applicable checks whose Step 4 evidence was invalidated; reuse evidence under the post-Full table.
Commit all files changed by this run.

读取最终范围的差异，确认所有审查和文档决策已解决。
仅运行步骤4中依据已失效的适用检查；复用全量验证后的表格中的依据。
提交本次运行变更的所有文件。

Step 7 — Repository instructions

步骤7 — 仓库指令

After the commit, read and follow

meta/workflows/execution/execution-instructions.md

if it exists.

提交后，若存在

meta/workflows/execution/execution-instructions.md

，则读取并遵循其中的内容。

Step 8 — Done report

步骤8 — 完成报告

**Execute-chat complete:**
- Shipped: [one line]
- Waves: [n] · review: [clean | P0/P1 fixed: …]
- Verified: [commands + results] · live: [PASS | user-confirmed | not applicable]
- Commit: [hash]
- Deferred: [one line each | none]

(Write

None — nothing deferred

when the deferred list is empty.)

**Execute-chat 执行完成：**
- 交付内容：[一句话概述]
- 批次数：[n] · 审查状态：[无问题 | 已修复P0/P1级问题：……]
- 验证情况：[命令 + 结果] · 实时测试：[通过 | 用户确认通过 | 不适用]
- 提交哈希：[hash]
- 推迟处理事项：[每个事项一句话 | 无]

（当推迟列表为空时，填写

无 — 无推迟处理事项

。）

Rules

规则

The chat is the spec. Execute only agreed work; defer new ideas.
Keep the ledger current.
```
TaskUpdate
```
each entry to
```
in_progress
```
when work starts and
```
completed
```
when it lands.
Verify diffs, not reports. Read each actual diff before accepting a wave, review fix, or docs pass.
Parent role. The parent plans, dispatches, verifies, adjudicates, and reports; it writes only small confirmed fixes and inline docs.

聊天内容即为规范。 仅执行已商定的工作；推迟处理新想法。
保持任务记录更新。 工作开始时将每个条目通过
```
TaskUpdate
```
更新为
```
in_progress
```
，完成落地后更新为
```
completed
```
。
验证差异，而非报告。 在接受批次、审查修复或文档处理前，读取实际差异。
父代理角色。 父代理负责计划、调度、验证、裁决和报告；仅编写小型已确认修复和内联文档。