stage-chapters

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

stage-chapters

Generates a Stage chapter run for the current local git branch and opens it in a browser. Uses

stagereview prep

to compute the diff, then generates chapters and a prologue, and hands the result to

stagereview show

to launch the SPA.

为当前本地Git分支生成Stage章节运行实例，并在浏览器中打开。使用

stagereview prep

计算差异，然后生成章节和序言，再将结果交给

stagereview show

以启动SPA。

Prerequisites

前置条件

Run these checks before any other work. If either fails, stop with the error message — do not continue.

stagereview
is installed. Run

which stagereview

. If it exits non-zero, instruct the user:

stagereview is not installed. Run:

    npm install -g stagereview

Then retry /stage-chapters.

Stop.

The current directory is a git repo. Run

git rev-parse --is-inside-work-tree

. If it does not print

true

, stop with:

/stage-chapters must be run inside a git repository.

在开展任何工作前先进行以下检查。如果任一检查失败，输出错误信息后停止操作——不要继续执行。

已安装
stagereview
。运行

which stagereview

。如果返回非零退出码，请告知用户：

stagereview is not installed. Run:

    npm install -g stagereview

Then retry /stage-chapters.

停止操作。

当前目录是Git仓库。运行

git rev-parse --is-inside-work-tree

。如果未输出

true

，输出以下信息后停止：

/stage-chapters must be run inside a git repository.

Step 1 — Run prep

步骤1 — 运行prep

bash

PREP_FILE=$(stagereview prep)

stagereview prep

auto-detects the base ref (main/master), computes the merge-base, generates the diff (including uncommitted and untracked changes when present), filters out lockfiles/binaries, and formats hunks with line numbers for analysis. It writes a plain-text file and prints only the file path to stdout.

If the user specifies a base branch (e.g., "generate chapters against

feature-a

"), pass

--base <ref>

to both

prep

and

show

bash

PREP_FILE=$(stagereview prep --base feature-a)

bash

PREP_FILE=$(stagereview prep)

stagereview prep

会自动检测基准分支（main/master），计算合并基准，生成差异（包含未提交和未跟踪的变更），过滤掉锁文件/二进制文件，并为分析添加行号格式化代码块。它会写入一个纯文本文件，并仅向标准输出打印文件路径。

如果用户指定了基准分支（例如“基于

feature-a

生成章节”），请在

prep

和

show

命令中都传入

--base <ref>

参数：

bash

PREP_FILE=$(stagereview prep --base feature-a)

... later ...

stagereview show --base feature-a "$AGENT_OUTPUT"


If `prep` exits non-zero, relay its stderr to the user and stop.

**Do not modify files in the working tree between running `prep` and running `show`.** Both commands independently snapshot the git state. If the diff changes between them, `show` will reject the chapters with a hunk coverage error because the hunks no longer match.

stagereview show --base feature-a "$AGENT_OUTPUT"


如果`prep`返回非零退出码，将其标准错误信息转发给用户并停止操作。

**在运行`prep`和`show`之间不要修改工作区中的文件**。两个命令会独立快照Git状态。如果期间差异发生变化，`show`会因代码块覆盖错误而拒绝章节，因为代码块不再匹配。

Step 2 — Read prep output

步骤2 — 读取prep输出

Read

$PREP_FILE

via the Read tool (or equivalent). For large diffs, use the Read tool's

offset

and

limit

parameters to read in chunks.

The file has two sections separated by headers:

=== COMMIT MESSAGES ===
—

git log --oneline

output for prologue context.

=== HUNKS ===
— formatted diff hunks with line numbers. Each hunk looks like:

=== File: src/app.ts (modified) | filePath: "src/app.ts", oldStart: 1 ===
=== Hunk @1: @@ -1,5 +1,6 @@ ===
1 1 | const a = 1;
2   |-const b = 2;
  2 |+const b = 3;
  3 |+const c = 4;
3 4 | const d = 5;

The two number columns are the old line number (left) and new line number (right). A blank column means the line doesn't exist on that side — additions have no old line number, deletions have no new line number. These numbers are used directly for

lineRefs

in key changes (see Step 3d).

commits.txt

contains

git log --oneline

output for prologue context.

通过Read工具（或等效工具）读取

$PREP_FILE

。对于大型差异，使用Read工具的

offset

和

limit

参数分块读取。

该文件包含两个由标题分隔的部分：

=== COMMIT MESSAGES ===
— 用于序言上下文的

git log --oneline

输出。

=== HUNKS ===
— 带行号的格式化差异代码块。每个代码块格式如下：

=== File: src/app.ts (modified) | filePath: "src/app.ts", oldStart: 1 ===
=== Hunk @1: @@ -1,5 +1,6 @@ ===
1 1 | const a = 1;
2   |-const b = 2;
  2 |+const b = 3;
  3 |+const c = 4;
3 4 | const d = 5;

两列数字分别是旧行号（左侧）和新行号（右侧）。空白列表示该行在对应版本中不存在——新增行没有旧行号，删除行没有新行号。这些数字直接用于关键变更中的

lineRefs

（见步骤3d）。

commits.txt

包含用于序言上下文的

git log --oneline

输出。

Step 3 — Cluster + narrate

步骤3 — 聚类 + 叙述

Using the hunks from

hunks.txt

, produce a

chapters

array. Each chapter groups related hunks into a coherent story beat, narrates them for a reviewer unfamiliar with this part of the codebase, and flags judgment calls that need human input.

使用

hunks.txt

中的代码块，生成一个

chapters

数组。每个章节将相关代码块分组为连贯的故事片段，为不熟悉该代码库的评审者进行叙述，并标记需要人工介入的判断点。

3a — Clustering rules

3a — 聚类规则

Group hunks by causal relationship — changes that set up or enable later changes belong together.

Spanning multiple files is expected and correct (e.g., schema + API + UI for one feature = one chapter).
Moves and refactors are a single chapter — when code is removed from one file and added to another (or a file is deleted and a similar one created), group the deletion and addition hunks together as one "Move/Refactor" chapter, not separate "Remove" and "Add" chapters.
Split only when changes are truly independent — a reviewer could understand one without knowing about the other.
Tests belong with their implementation chapter.
Config/dependency changes can be their own chapter if unrelated to a feature chapter.

Chapter ordering:

Foundation first: types, interfaces, schemas, utilities that others depend on
Core logic next: main implementation
Integration last: wiring, configuration, tests

Consider symbol dependencies between chapters — a chapter that introduces a type another chapter uses must come first.

Hunk ordering within a chapter:

Group all hunks from the same file together — do not interleave hunks from different files.
Within the same file, list hunks in ascending
```
oldStart
```
order (matching file layout).

按因果关系分组代码块——为后续变更做铺垫或提供支持的变更应归为一组。

跨多个文件是正常且正确的（例如，一个功能的Schema + API + UI = 一个章节）。
移动和重构属于单个章节——当代码从一个文件移除并添加到另一个文件（或删除一个文件并创建类似文件）时，将删除和添加的代码块归为一个“移动/重构”章节，而非分开的“移除”和“添加”章节。
仅当变更完全独立时才拆分——评审者无需了解另一部分即可理解当前部分。
测试应与其实现章节放在一起。
如果配置/依赖变更与功能章节无关，可以单独作为一个章节。

章节排序：

基础优先：类型、接口、Schema、其他模块依赖的工具类
核心逻辑次之：主要实现代码
集成最后：连接逻辑、配置、测试

考虑章节之间的符号依赖——引入其他章节使用的类型的章节必须放在前面。

章节内代码块排序：

将同一文件的所有代码块放在一起——不要交错不同文件的代码块。
在同一文件内，按
```
oldStart
```
升序排列代码块（与文件布局匹配）。

3b — Self-validation rules

3b — 自验证规则

Every hunk in the formatted diff must appear in exactly one chapter. No hunk may be omitted and no hunk may appear in more than one chapter.

Each hunk header in the prep output has the format:

=== File: <path> (<status>) | filePath: "<path>", oldStart: <N> ===

Use the

filePath

and

oldStart

values from these headers to build

hunkRefs

stagereview show

validates hunk coverage automatically — it will error with a list of missing or extra hunks if the chapters don't account for every hunk in the diff. If this happens, fix the chapters and retry.

格式化差异中的每个代码块必须恰好出现在一个章节中。不得遗漏任何代码块，也不得让代码块出现在多个章节中。

prep输出中的每个代码块标题格式如下：

=== File: <path> (<status>) | filePath: "<path>", oldStart: <N> ===

使用这些标题中的

filePath

和

oldStart

值构建

hunkRefs

。

stagereview show

会自动验证代码块覆盖率——如果章节未覆盖差异中的所有代码块，它会输出错误信息并列出缺失或多余的代码块。如果发生这种情况，修正章节后重试。

3c — Narration rules

3c — 叙述规则

Write each chapter as a story beat — a meaningful step that moves the branch forward, not a summary of files changed.

Title: action-oriented verb phrase, max 8 words (e.g., "Wire org ID through the API layer"). No filler like "Add support for".
Summary: 2–3 sentences covering what this chapter enables and why. Lead with impact, then connect to the broader purpose. When a chapter builds on a previous one, open with that causal link explicitly (e.g., "Now that X is in place…").
- Keep paragraphs short. Prefer splitting distinct points into separate short paragraphs (separated by a blank line) rather than writing one long dense paragraph. Each paragraph should convey a single idea.
- Markdown allowed:
```
**bold**
```
  for emphasis,
```
*italics*
```
  for nuance,
```
`backticks`
```
  for inline code references, and fenced code blocks when a short snippet (≤ 6 lines) helps illustrate the change.

将每个章节写成一个故事片段——推动分支前进的有意义步骤，而非变更文件的摘要。

标题： 面向动作的动词短语，最多8个单词（例如“将组织ID接入API层”）。不要使用“添加对...的支持”之类的冗余表述。
摘要： 2-3句话，说明本章实现的功能及其原因。先讲影响，再关联更广泛的目标。当本章基于前一章构建时，明确以因果关系开头（例如“既然X已就绪...”）。
- 段落要简短。将不同观点拆分为单独的短段落（用空白行分隔），而非写一个冗长的密集段落。每个段落应传达一个单一观点。
- 允许使用Markdown：
```
**粗体**
```
  用于强调，
```
*斜体*
```
  用于细微差别，
```
`反引号`
```
  用于内联代码引用，当短代码片段（≤6行）有助于说明变更时使用围栏代码块。

3d — Key change rules

3d — 关键变更规则

Key changes are judgment calls only a human reviewer can make — things that require product context, team conventions, or knowledge of the author's intent. Linters, type checkers, and code-review bots already cover correctness and style; skip anything they can catch. Ignore auto-generated files.

Return an empty array when nothing needs human input — do not invent items to fill the list. When a chapter is a straightforward rename, type fix, or mechanical refactor with no judgment calls,

keyChanges

should be

[]

Frame each item as a question.

Each key change includes

lineRefs

: one line range per distinct spot the question depends on. Most questions touch a single location, so use one range; only add more when the judgment genuinely spans related code in different places.

Reading line numbers from
hunks.txt
: Each diff line shows two number columns — old (left) and new (right). Use these numbers directly:

For
```
side: "deletions"
```
— use the old (left) column number as
```
startLine
```
/
```
endLine
```
.
For
```
side: "additions"
```
— use the new (right) column number as
```
startLine
```
/
```
endLine
```
.
Do not count lines yourself — read the numbers from the formatted output.

Keep ranges tight — point to the specific lines the question is about, not the entire hunk.

startLine

and

endLine

must both be positive integers with

endLine >= startLine

Good examples:

"Should
```
retryCount
```
reset when the user switches orgs?"
"Is a 60-minute session timeout appropriate for this user base, or would 30 minutes be safer?"
"Does this new index cover the query patterns the team actually uses in production?"

Bad examples:

"Check that the auth logic is correct." — vague, verifiable by reading the code
"The function now handles errors." — changelog item, not a question
"Make sure the tests pass." — CI catches this, not a human judgment call

关键变更是只有人工评审者才能做出的判断——需要产品上下文、团队约定或了解作者意图的内容。代码检查器、类型检查器和代码评审机器人已经覆盖了正确性和风格；跳过它们可以捕获的内容。忽略自动生成的文件。

当没有需要人工介入的内容时返回空数组——不要为了填充列表而编造条目。当章节是简单的重命名、类型修复或无判断点的机械重构时，

keyChanges

应为

[]

。

将每个条目表述为问题。

每个关键变更包含

lineRefs

：每个问题对应的一个或多个行范围。大多数问题只涉及一个位置，因此使用一个范围；只有当判断真正涉及不同位置的相关代码时才添加更多范围。

从
hunks.txt
读取行号：每个差异行显示两列数字——旧行号（左侧）和新行号（右侧）。直接使用这些数字：

对于
```
side: "deletions"
```
——使用旧（左侧）列号作为
```
startLine
```
/
```
endLine
```
。
对于
```
side: "additions"
```
——使用新（右侧）列号作为
```
startLine
```
/
```
endLine
```
。
不要自行计数行号——从格式化输出中读取数字。

范围要精确——指向问题涉及的具体行，而非整个代码块。

startLine

和

endLine

必须都是正整数，且

endLine >= startLine

。

好例子：

“当用户切换组织时，
```
retryCount
```
是否应该重置？”
“60分钟会话超时对该用户群体是否合适，还是30分钟更安全？”
“这个新索引是否覆盖了团队在生产环境中实际使用的查询模式？”

坏例子：

“检查认证逻辑是否正确。”——模糊，可通过阅读代码验证
“函数现在可以处理错误。”——变更日志条目，而非问题
“确保测试通过。”——CI会捕获此问题，无需人工判断

3e — Output format

3e — 输出格式

Produce an array of chapter objects. Each chapter:

jsonc

{
  "id": "chapter-1",    // unique within the run, e.g. "chapter-1", "chapter-2", …
  "order": 1,           // positive integer, 1-indexed
  "title": "Short imperative title",
  "summary": "Why this chapter matters to the reviewer.",
  "hunkRefs": [
    // one entry per hunk in the chapter
    { "filePath": "path/to/file.ts", "oldStart": 42 }
  ],
  "keyChanges": [
    // zero or more judgment-call questions
    {
      "content": "A judgment-call question for the reviewer.",
      "lineRefs": [
        {
          "filePath": "path/to/file.ts",
          "side": "additions",
          "startLine": 50,
          "endLine": 55
        }
      ]
    }
  ]
}

Do not invent
```
hunkRefs
```
— only use
```
(filePath, oldStart)
```
tuples that actually appear in the formatted hunks.
```
keyChanges[].lineRefs
```
must have at least one entry per key change.

生成章节对象数组。每个章节：

jsonc

{
  "id": "chapter-1",    // 本次运行内唯一，例如 "chapter-1", "chapter-2", …
  "order": 1,           // 正整数，从1开始索引
  "title": "简短的祈使句标题",
  "summary": "本章对评审者的重要性。",
  "hunkRefs": [
    // 本章中的每个代码块对应一个条目
    { "filePath": "path/to/file.ts", "oldStart": 42 }
  ],
  "keyChanges": [
    // 零个或多个判断性问题
    {
      "content": "给评审者的判断性问题。",
      "lineRefs": [
        {
          "filePath": "path/to/file.ts",
          "side": "additions",
          "startLine": 50,
          "endLine": 55
        }
      ]
    }
  ]
}

不要编造
hunkRefs
——仅使用格式化代码块中实际存在的
```
(filePath, oldStart)
```
元组。
```
keyChanges[].lineRefs
```
每个关键变更至少包含一个条目。

Step 4 — Generate prologue

步骤4 — 生成序言

After building the chapters, generate a prologue — a high-level overview of the entire change. The prologue helps reviewers orient themselves before diving into individual chapters.

Use

commits.txt

from the prep output for context.

Using the diff, chapters, and commit messages, produce a

prologue

object with the following fields:

构建章节后，生成序言——整个变更的高层概述。序言帮助评审者在深入单个章节前了解整体情况。

使用prep输出中的

commits.txt

获取上下文。

利用差异、章节和提交信息，生成包含以下字段的

prologue

对象：

motivation (string or null)

motivation（字符串或null）

One sentence a non-engineer would understand. What was broken, annoying, or missing — from a person's perspective. If the commit messages are generic and the diff doesn't make the motivation obvious, use

null

Good: "Dashboards would break during deploys, so people had to keep refreshing until things came back." Bad: "The API client had no retry logic for 503 errors." (too technical — no one outside the team knows what that means)

一句非技术人员能理解的话。从用户角度看，什么是破损的、令人烦恼的或缺失的。如果提交信息通用且差异无法明确动机，使用

null

。

好例子： “部署期间仪表板会崩溃，因此人们必须不断刷新直到恢复正常。” 坏例子： “API客户端没有针对503错误的重试逻辑。”——过于技术化，团队外的人不知道这意味着什么

outcome (string or null)

outcome（字符串或null）

One sentence a non-engineer would understand. What's better now. Same null rule as motivation.

Good: "Dashboards stay up during deploys now." Bad: "Added exponential backoff with a base delay of 100ms." (implementation detail)

一句非技术人员能理解的话。现在有什么改善。与motivation的null规则相同。

好例子： “现在部署期间仪表板保持可用。” 坏例子： “添加了基础延迟为100ms的指数退避机制。”——实现细节

keyChanges (array of 2–5 objects)

keyChanges（2-5个对象的数组）

Each object has:

```
summary
```
: 6–10 words describing what's different now. Outcome-focused, not action-focused.
```
description
```
: Capitalized sentence, 10–15 words of additional context.

Good:

summary: "Audit runs are now tracked in a database"

description: "Uses new Drizzle ORM schema with full history retention"

Bad:

summary: "Adds Drizzle ORM layer"

(action-focused — describe what changed, not what you did)

每个对象包含：

```
summary
```
: 6-10个单词，描述现在的不同之处。以结果为导向，而非动作导向。
```
description
```
: 首字母大写的句子，10-15个单词的额外上下文。

好例子：

summary: "审计运行现在在数据库中跟踪"

description: "使用具有完整历史保留功能的新Drizzle ORM Schema"

坏例子：

summary: "添加Drizzle ORM层"

——动作导向，描述变更内容而非你做了什么

focusAreas (array of 1–5 objects)

focusAreas（1-5个对象的数组）

Always provide at least 1 focus area. Even clean changes have spots worth a reviewer's attention.

Each object has:

type

: one of

security

breaking-change

high-complexity

data-integrity

new-pattern

architecture

performance

testing-gap

```
severity
```
: one of
```
critical
```
,
```
high
```
,
```
medium
```
(for problems) or
```
info
```
(for points of interest)
```
title
```
: 3–5 word noun phrase (e.g., "Unvalidated user input")
```
description
```
: WHY this was flagged + a declarative action for the reviewer. Use "confirm", "verify", or "check" to give the reviewer a specific task.
```
locations
```
: array of file paths where this applies

Good:

type: "security", severity: "high", title: "Unvalidated user input", description: "User-provided ID passed directly to database query — confirm input is validated and parameterized"

Bad:

description: "Worth understanding"

(no action, vague)

始终至少提供1个重点领域。即使是清晰的变更也有值得评审者关注的地方。

每个对象包含：

type

: 以下之一：

security

breaking-change

high-complexity

data-integrity

new-pattern

architecture

performance

testing-gap

```
severity
```
: 以下之一：
```
critical
```
,
```
high
```
,
```
medium
```
（针对问题）或
```
info
```
（针对关注点）
```
title
```
: 3-5个单词的名词短语（例如“未验证的用户输入”）
```
description
```
: 标记此内容的原因 + 给评审者的明确操作。使用“确认”、“验证”或“检查”给评审者具体任务。
```
locations
```
: 适用此内容的文件路径数组

好例子：

type: "security", severity: "high", title: "未验证的用户输入", description: "用户提供的ID直接传递给数据库查询——确认输入已验证且参数化"

坏例子：

description: "值得理解"

——无操作，模糊

complexity

Object with:

```
level
```
: one of
```
low
```
,
```
medium
```
,
```
high
```
,
```
very-high
```
```
reasoning
```
: brief explanation (e.g., "New DB schema plus multiple service changes")

包含以下字段的对象：

```
level
```
: 以下之一：
```
low
```
,
```
medium
```
,
```
high
```
,
```
very-high
```
```
reasoning
```
: 简短解释（例如“新数据库Schema加上多个服务变更”）

Style

风格

Talk like a coworker, not a changelog. No jargon, no filler phrases, no "this change introduces/implements/adds". Just say what happened and why it matters.

像同事一样交流，而非变更日志。不要使用行话、冗余短语，不要说“此变更引入/实现/添加了”。只需说明发生了什么以及为什么重要。

Step 5 — Write agent output

步骤5 — 写入Agent输出

Compute a unique temp path and write the JSON via a bash heredoc:

bash

AGENT_OUTPUT=$(mktemp "${TMPDIR:-/tmp}/stage-agent-output.XXXXXX")
cat > "$AGENT_OUTPUT" << 'AGENT_EOF'
{
  "chapters": [ ... ],
  "prologue": { ... }
}
AGENT_EOF

The trailing

XXXXXX

(with no suffix after) is required by macOS BSD

mktemp

. Using

cat

with a heredoc avoids tool-specific file-writing issues.

Field rules:

Field	Constraint
`chapters[].id`	Non-empty, unique within the run
`chapters[].order`	Positive integer (1-indexed)
`chapters[].hunkRefs[].oldStart`	Non-negative integer — the pre-image start line from the `oldStart` in the formatted hunk header ( `0` for new files)
`chapters[].keyChanges[].lineRefs`	Array with at least one entry
`lineRefs[].side`	`"additions"` (right side) or `"deletions"` (left side)
`lineRefs[].startLine` / `endLine`	Positive integers; `endLine >= startLine`
`prologue`	Optional object; omit entirely if not desired
`prologue.motivation`	String or `null`
`prologue.outcome`	String or `null`
`prologue.keyChanges`	Array of 2–5 objects with `summary` and `description`
`prologue.focusAreas`	Array of 1–5 objects
`prologue.focusAreas[].type`	One of: `security` , `breaking-change` , `high-complexity` , `data-integrity` , `new-pattern` , `architecture` , `performance` , `testing-gap`
`prologue.focusAreas[].severity`	One of: `critical` , `high` , `medium` , `info`
`prologue.complexity.level`	One of: `low` , `medium` , `high` , `very-high`

计算唯一的临时路径，并通过bash heredoc写入JSON：

bash

AGENT_OUTPUT=$(mktemp "${TMPDIR:-/tmp}/stage-agent-output.XXXXXX")
cat > "$AGENT_OUTPUT" << 'AGENT_EOF'
{
  "chapters": [ ... ],
  "prologue": { ... }
}
AGENT_EOF

末尾的

XXXXXX

（无后缀）是macOS BSD

mktemp

要求的。使用

cat

和heredoc避免工具特定的文件写入问题。

字段规则：

字段	约束
`chapters[].id`	非空，本次运行内唯一
`chapters[].order`	正整数（从1开始索引）
`chapters[].hunkRefs[].oldStart`	非负整数——格式化代码块标题中 `oldStart` 对应的原文件起始行（新文件为 `0` ）
`chapters[].keyChanges[].lineRefs`	至少包含一个条目的数组
`lineRefs[].side`	`"additions"` （右侧）或 `"deletions"` （左侧）
`lineRefs[].startLine` / `endLine`	正整数； `endLine >= startLine`
`prologue`	可选对象；如果不需要可完全省略
`prologue.motivation`	字符串或 `null`
`prologue.outcome`	字符串或 `null`
`prologue.keyChanges`	包含2-5个带 `summary` 和 `description` 的对象的数组
`prologue.focusAreas`	包含1-5个对象的数组
`prologue.focusAreas[].type`	以下之一： `security` , `breaking-change` , `high-complexity` , `data-integrity` , `new-pattern` , `architecture` , `performance` , `testing-gap`
`prologue.focusAreas[].severity`	以下之一： `critical` , `high` , `medium` , `info`
`prologue.complexity.level`	以下之一： `low` , `medium` , `high` , `very-high`

Step 6 — Display generated chapters

步骤6 — 显示生成的章节

Hand the file to

stagereview

bash

stagereview show "$AGENT_OUTPUT"

stagereview show

auto-detects the agent output format, independently computes the scope and "Other changes" chapter for filtered files, validates the JSON, inserts the run into the local SQLite database, boots a loopback HTTP server, and opens the browser.

The command blocks until the user presses Ctrl+C. If your harness requires non-blocking execution, run it in the background (e.g.,

run_in_background

in Claude Code). Invoke it as the final command in the workflow.

将文件交给

stagereview

：

bash

stagereview show "$AGENT_OUTPUT"

stagereview show

会自动检测Agent输出格式，独立计算过滤文件的范围和“其他变更”章节，验证JSON，将运行实例插入本地SQLite数据库，启动环回HTTP服务器，并打开浏览器。

该命令会阻塞直到用户按下Ctrl+C。如果你的执行环境需要非阻塞运行，请在后台执行（例如Claude Code中的

run_in_background

）。将其作为工作流中的最后一个命令调用。