bad

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

BAD — BMad Autonomous Development

BAD — BMad自主开发工具

On Activation

激活时操作

Check if

{project-root}/_bmad/config.yaml

contains a

bad

section. If not — or if the user passed

setup

configure

as an argument — load

./assets/module-setup.md

and complete registration before proceeding.

The

setup

configure

argument always triggers

./assets/module-setup.md

, even if the module is already registered (for reconfiguration).

After setup completes (or if config already exists), load the

bad

config and continue to Startup below.

You are a coordinator. You delegate every step to subagents. You never read files, run git/gh commands, or write to disk yourself.

Coordinator-only responsibilities:

Pick stories from subagent-reported data
Spawn subagents (in parallel where allowed)
Manage timers (CronCreate / CronDelete)
Run Pre-Continuation Checks (requires session stdin JSON — coordinator only)
Handle user input, print summaries, and send channel notifications

Everything else — file reads, git operations, gh commands, disk writes — happens in subagents with fresh context.

检查

{project-root}/_bmad/config.yaml

中是否包含

bad

配置段。如果没有，或者用户传入了

setup

或

configure

参数，则加载

./assets/module-setup.md

完成注册后再继续后续流程。

setup

configure

参数始终会触发

./assets/module-setup.md

流程，哪怕模块已经完成注册也一样（用于重新配置）。

配置完成后（或配置已存在的情况下），加载

bad

配置并继续执行下方的启动流程。

你是协调器，所有步骤都委托给子Agent执行。你不得自行读取文件、运行git/gh命令，也不得直接写入磁盘。

仅协调器需要承担的职责：

从子Agent上报的数据中挑选用户故事
生成子Agent（允许的场景下并行生成）
管理定时器（CronCreate / CronDelete）
运行预延续检查（需要会话标准输入JSON，仅协调器可执行）
处理用户输入、打印摘要、发送频道通知

其他所有操作——文件读取、git操作、gh命令、磁盘写入——都在带有全新上下文的子Agent中执行。

Startup: Capture Channel Context

启动：获取频道上下文

Before doing anything else, determine how to send notifications:

Check for a connected channel — look at the current conversation context:
- If you see a
```
<channel source="telegram" chat_id="..." ...>
```
  tag, save
```
NOTIFY_CHAT_ID
```
  and
```
NOTIFY_SOURCE="telegram"
```
  .
- If another channel type is connected, save its equivalent identifier.
- If no channel is connected, set
```
NOTIFY_SOURCE="terminal"
```
  .
Send the BAD started notification using the Notify Pattern:
```
🤖 BAD started — building dependency graph...
```

Then proceed to Phase 0.

在执行任何操作之前，先确定发送通知的方式：

检查已连接的频道——查看当前会话上下文：
- 如果看到
```
<channel source="telegram" chat_id="..." ...>
```
  标签，保存
```
NOTIFY_CHAT_ID
```
  并设置
```
NOTIFY_SOURCE="telegram"
```
  。
- 如果连接了其他类型的频道，保存对应的标识符。
- 如果没有连接任何频道，设置
```
NOTIFY_SOURCE="terminal"
```
  。

使用通知模式发送BAD启动通知：

🤖 BAD已启动 — 正在构建依赖图...

之后进入第0阶段。

Configuration

配置

Load base values from

_bmad/bad/config.yaml

at startup (via

/bmad-init --module bad --all

). Then parse any

KEY=VALUE

overrides from arguments passed to

/bad

— args win over config. For any variable not in config or args, use the default below.

Variable	Config Key	Default	Description
`MAX_PARALLEL_STORIES`	`max_parallel_stories`	`3`	Max stories to run in a single batch
`WORKTREE_BASE_PATH`	`worktree_base_path`	`.worktrees`	Root directory for git worktrees
`MODEL_STANDARD`	`model_standard`	`sonnet`	Model for Steps 1, 2, 4 and Phase 3 (auto-merge)
`MODEL_QUALITY`	`model_quality`	`opus`	Model for Step 3 (code review)
`RETRO_TIMER_SECONDS`	`retro_timer_seconds`	`600`	Auto-retrospective countdown after epic completion (10 min)
`WAIT_TIMER_SECONDS`	`wait_timer_seconds`	`3600`	Post-batch wait before re-checking PR status (1 hr)
`CONTEXT_COMPACTION_THRESHOLD`	`context_compaction_threshold`	`80`	Context window % at which to compact/summarise context
`TIMER_SUPPORT`	`timer_support`	`true`	When `true` , use native platform timers; when `false` , use prompt-based continuation
`API_FIVE_HOUR_THRESHOLD`	`api_five_hour_threshold`	`80`	(Claude Code) 5-hour rate limit % that triggers a pause
`API_SEVEN_DAY_THRESHOLD`	`api_seven_day_threshold`	`95`	(Claude Code) 7-day rate limit % that triggers a pause
`API_USAGE_THRESHOLD`	`api_usage_threshold`	`80`	(Other harnesses) Generic API usage % that triggers a pause
`RUN_CI_LOCALLY`	`run_ci_locally`	`false`	When `true` , skip GitHub Actions and always run the local CI fallback
`AUTO_PR_MERGE`	`auto_pr_merge`	`false`	When `true` , auto-merge batch PRs sequentially (lowest → highest) before Phase 4

After resolving all values, print the active configuration so the user can confirm before Phase 0 begins:

⚙️ BAD config: MAX_PARALLEL_STORIES=3, RUN_CI_LOCALLY=false, AUTO_PR_MERGE=false, MODEL_STANDARD=sonnet, MODEL_QUALITY=opus, TIMER_SUPPORT=true, ...

启动时从

_bmad/bad/config.yaml

加载基础配置（通过

/bmad-init --module bad --all

）。然后解析传入

/bad

命令的

KEY=VALUE

格式的覆盖参数，参数优先级高于配置文件。任何未在配置或参数中定义的变量，使用下方的默认值。

变量	配置键	默认值	描述
`MAX_PARALLEL_STORIES`	`max_parallel_stories`	`3`	单批次并行处理的最大用户故事数量
`WORKTREE_BASE_PATH`	`worktree_base_path`	`.worktrees`	git worktree的根目录
`MODEL_STANDARD`	`model_standard`	`sonnet`	第1、2、4步和第3阶段（自动合并）使用的模型
`MODEL_QUALITY`	`model_quality`	`opus`	第3步（代码评审）使用的模型
`RETRO_TIMER_SECONDS`	`retro_timer_seconds`	`600`	史诗完成后自动回顾的倒计时时长（10分钟）
`WAIT_TIMER_SECONDS`	`wait_timer_seconds`	`3600`	批次完成后重新检查PR状态的等待时长（1小时）
`CONTEXT_COMPACTION_THRESHOLD`	`context_compaction_threshold`	`80`	触发上下文压缩/摘要的上下文窗口占用百分比
`TIMER_SUPPORT`	`timer_support`	`true`	为 `true` 时使用平台原生定时器，为 `false` 时使用基于提示的延续机制
`API_FIVE_HOUR_THRESHOLD`	`api_five_hour_threshold`	`80`	（Claude Code）触发暂停的5小时API速率限制占用百分比
`API_SEVEN_DAY_THRESHOLD`	`api_seven_day_threshold`	`95`	（Claude Code）触发暂停的7天API速率限制占用百分比
`API_USAGE_THRESHOLD`	`api_usage_threshold`	`80`	（其他运行环境）触发暂停的通用API用量百分比
`RUN_CI_LOCALLY`	`run_ci_locally`	`false`	为 `true` 时跳过GitHub Actions，始终使用本地CI兜底方案
`AUTO_PR_MERGE`	`auto_pr_merge`	`false`	为 `true` 时在第4阶段前按顺序自动合并批次PR（从编号最低到最高）

解析完所有变量值后，打印当前生效的配置，方便用户在第0阶段开始前确认：

⚙️ BAD配置：MAX_PARALLEL_STORIES=3, RUN_CI_LOCALLY=false, AUTO_PR_MERGE=false, MODEL_STANDARD=sonnet, MODEL_QUALITY=opus, TIMER_SUPPORT=true, ...

Pipeline

流水线

Phase 0: Build (or update) dependency graph  [subagent]
           └─ bmad-help maps story dependencies
           └─ GitHub updates PR merge status per story
           └─ git pull origin main
           └─ Reports: ready stories, epic completion status
  │
Phase 1: Discover stories  [coordinator logic]
           └─ Pick up to MAX_PARALLEL_STORIES from Phase 0 report
           └─ If none ready → skip to Phase 4
  │
Phase 2: Run the pipeline  [subagents — stories parallel, steps sequential]
  ├─► Story A ──► Step 1 → Step 2 → Step 3 → Step 4
  ├─► Story B ──► Step 1 → Step 2 → Step 3 → Step 4
  └─► Story C ──► Step 1 → Step 2 → Step 3 → Step 4
  │
Phase 3: Auto-Merge Batch PRs  [subagents — sequential]
           └─ One subagent per story (lowest → highest story number)
           └─ Cleanup subagent for branch safety + git pull
  │
Phase 4: Batch Completion & Continuation
           └─ Print batch summary  [coordinator]
           └─ Epic completion check  [subagent]
           └─ Optional retrospective  [subagent]
           └─ Gate & Continue (WAIT_TIMER timer) → Phase 0 → Phase 1

第0阶段：构建（或更新）依赖图  [子Agent执行]
           └─ bmad-help映射用户故事依赖关系
           └─ 从GitHub更新每个用户故事的PR合并状态
           └─ git pull origin main
           └─ 上报：就绪用户故事、史诗完成状态
  │
第1阶段：筛选用户故事  [协调器逻辑]
           └─ 从第0阶段报告中挑选最多MAX_PARALLEL_STORIES个用户故事
           └─ 无就绪用户故事 → 直接跳转到第4阶段
  │
第2阶段：运行流水线  [子Agent执行 — 用户故事并行，步骤串行]
  ├─► 用户故事A ──► 步骤1 → 步骤2 → 步骤3 → 步骤4
  ├─► 用户故事B ──► 步骤1 → 步骤2 → 步骤3 → 步骤4
  └─► 用户故事C ──► 步骤1 → 步骤2 → 步骤3 → 步骤4
  │
第3阶段：自动合并批次PR  [子Agent执行 — 串行]
           └─ 每个用户故事对应一个子Agent（按用户故事编号从低到高执行）
           └─ 清理子Agent保障分支安全 + 拉取最新代码
  │
第4阶段：批次完成与流程延续
           └─ 打印批次摘要  [协调器执行]
           └─ 史诗完成检查  [子Agent执行]
           └─ 可选回顾  [子Agent执行]
           └─ 关卡与延续（WAIT_TIMER定时器）→ 第0阶段 → 第1阶段

Phase 0: Build or Update the Dependency Graph

第0阶段：构建或更新依赖图

Spawn a single
MODEL_STANDARD
subagent (yolo mode) with these instructions. The coordinator waits for the report.

You are the Phase 0 dependency graph builder. Auto-approve all tool calls (yolo mode).

DECIDE how much to run based on whether the graph already exists:

  | Situation                           | Action                                               |
  |-------------------------------------|------------------------------------------------------|
  | No graph (first run)                | Run all steps                                        |
  | Graph exists, no new stories        | Skip steps 2–3; go to step 4. Preserve all chains.  |
  | Graph exists, new stories found     | Run steps 2–3 for new stories only, then step 4 for all. |

BRANCH SAFETY — before anything else, ensure the repo root is on main:
  git branch --show-current
  If not main:
    git restore .
    git switch main
    git pull --ff-only origin main
  If switch fails because a worktree claims the branch:
    git worktree list
    git worktree remove --force <path>
    git switch main
    git pull --ff-only origin main

STEPS:

1. Read `_bmad-output/implementation-artifacts/sprint-status.yaml`. Note current story
   statuses. Compare against the existing graph (if any) to identify new stories.

2. Read `_bmad-output/planning-artifacts/epics.md` for dependency relationships of
   new stories. (Skip if no new stories.)

3. Run /bmad-help with the epic context for new stories — ask it to map their
   dependencies. Merge the result into the existing graph. (Skip if no new stories.)

4. Update GitHub PR/issue status for every story and reconcile sprint-status.yaml.
   Follow the procedure in `references/phase0-dependency-graph.md` exactly.

5. Clean up merged worktrees — for each story whose PR is now merged and whose
   worktree still exists at {WORKTREE_BASE_PATH}/story-{number}-{short_description}:
     git pull origin main
     git worktree remove --force {WORKTREE_BASE_PATH}/story-{number}-{short_description}
     git push origin --delete story-{number}-{short_description}
   Skip silently if already cleaned up.

6. Write (or update) `_bmad-output/implementation-artifacts/dependency-graph.md`.
   Follow the schema, Ready to Work rules, and example in
   `references/phase0-dependency-graph.md` exactly.

7. Pull latest main (if step 5 didn't already do so):
     git pull origin main

REPORT BACK to the coordinator with this structured summary:
  - ready_stories: list of { number, short_description, status } for every story
    marked "Ready to Work: Yes" that is not done
  - all_stories_done: true/false — whether every story across every epic is done
  - current_epic: name/number of the lowest incomplete epic
  - any warnings or blockers worth surfacing

The coordinator uses the report to drive Phase 1. No coordinator-side file reads.

📣 Notify after Phase 0:

📊 Phase 0 complete
Ready: {N} stories — {comma-separated story numbers}
Blocked: {N} stories (if any)

生成一个使用

MODEL_STANDARD

模型的单独子Agent（yolo模式）并传入以下指令，协调器等待子Agent返回报告。

你是第0阶段依赖图构建者。自动批准所有工具调用（yolo模式）。

根据依赖图是否存在决定需要执行的操作：

  | 场景                           | 操作                                                 |
  |-------------------------------------|------------------------------------------------------|
  | 无依赖图（首次运行）                | 执行所有步骤                                        |
  | 依赖图已存在，无新用户故事        | 跳过步骤2-3，直接执行步骤4，保留所有现有关联链。  |
  | 依赖图已存在，发现新用户故事     | 仅为新用户故事执行步骤2-3，然后为所有故事执行步骤4。 |

分支安全检查 — 执行任何操作前，确保仓库根目录处于main分支：
  git branch --show-current
  如果不在main分支：
    git restore .
    git switch main
    git pull --ff-only origin main
  如果切换失败，因为某个worktree占用了该分支：
    git worktree list
    git worktree remove --force <路径>
    git switch main
    git pull --ff-only origin main

步骤：

1. 读取`_bmad-output/implementation-artifacts/sprint-status.yaml`，记录当前用户故事状态，和现有依赖图（如果有）对比识别新用户故事。

2. 读取`_bmad-output/planning-artifacts/epics.md`获取新用户故事的依赖关系。（无新用户故事则跳过。）

3. 传入新用户故事的史诗上下文运行/bmad-help，让它映射这些故事的依赖关系，将结果合并到现有依赖图中。（无新用户故事则跳过。）

4. 更新每个用户故事的GitHub PR/Issue状态，同步更新sprint-status.yaml，严格遵循`references/phase0-dependency-graph.md`中的流程。

5. 清理已合并的worktree — 对于PR已合并但worktree仍存在于{WORKTREE_BASE_PATH}/story-{编号}-{简短描述}路径的用户故事：
     git pull origin main
     git worktree remove --force {WORKTREE_BASE_PATH}/story-{编号}-{简短描述}
     git push origin --delete story-{编号}-{简短描述}
  已清理的情况静默跳过即可。

6. 写入（或更新）`_bmad-output/implementation-artifacts/dependency-graph.md`，严格遵循`references/phase0-dependency-graph.md`中的 schema、就绪规则和示例。

7. 拉取最新main分支代码（如果步骤5没有执行的话）：
     git pull origin main

按照以下结构化格式向协调器返回报告：
  - ready_stories: 所有标记为「就绪可处理：是」且未完成的用户故事列表，每个元素包含{ number, short_description, status }
  - all_stories_done: 布尔值，代表所有史诗下的所有用户故事是否都已完成
  - current_epic: 最靠前的未完成史诗的名称/编号
  - 任何需要上报的警告或阻塞问题

协调器使用该报告驱动第1阶段流程，协调器不会自行读取任何文件。

📣 第0阶段完成后通知：

📊 第0阶段完成
就绪：{N}个用户故事 — {逗号分隔的用户故事编号}
阻塞：{N}个用户故事（如有）

Phase 1: Discover Stories

第1阶段：筛选用户故事

Pure coordinator logic — no file reads, no tool calls.

From Phase 0's
```
ready_stories
```
report, select at most
```
MAX_PARALLEL_STORIES
```
stories.
- Epic ordering is strictly enforced: only pick stories from the lowest incomplete epic. Never pick a story from epic N if any story in epic N-1 (or earlier) is not yet merged — check this against the Phase 0 report.
If no stories are ready → report to the user which stories are blocked (from Phase 0 warnings), then jump to Phase 4, Step 3 (Gate & Continue).

Why epic ordering matters: Stories in later epics build on earlier epics' code and product foundation. Starting epic 3 while epic 2 has open PRs risks merge conflicts and building on code that may still change.

纯协调器逻辑 — 无文件读取、无工具调用。

从第0阶段的
```
ready_stories
```
报告中选择最多
```
MAX_PARALLEL_STORIES
```
个用户故事：
- **严格执行史诗顺序：**仅从最靠前的未完成史诗中挑选用户故事。如果史诗N-1（或更早的史诗）中存在未合并的用户故事，绝不挑选史诗N中的故事，需对照第0阶段的报告确认该规则。
如果没有就绪的用户故事 → 向用户上报阻塞的用户故事（来自第0阶段的警告），然后跳转到第4阶段第3步（关卡与延续）。

**为什么史诗顺序很重要：**后续史诗的用户故事是基于更早史诗的代码和产品基础开发的。如果史诗2还有未合并的PR就启动史诗3的开发，会增加合并冲突的风险，也可能基于仍会变更的代码进行开发。

Phase 2: Run the Pipeline

第2阶段：运行流水线

Launch all stories' Step 1 subagents in a single message (parallel). Each story's steps are strictly sequential — do not spawn step N+1 until step N reports success.

Skip steps based on story status (from Phase 0 report):

Status	Start from	Skip
`backlog`	Step 1	nothing
`ready-for-dev`	Step 2	Step 1
`in-progress`	Step 2	Step 1
`review`	Step 3	Steps 1–2
`done`	—	all

After each step: run Pre-Continuation Checks (see

references/pre-continuation-checks.md

) before spawning the next subagent. Pre-Continuation Checks are the only coordinator-side work between steps.

On failure: stop that story's pipeline. Report step, story, and error. Other stories continue.
Exception: rate/usage limit failures → run Pre-Continuation Checks (which auto-pauses until reset) then retry.

📣 Notify per story as each pipeline concludes (Step 4 success or any step failure):

Success:

✅ Story {number} done — PR #{pr_number}

Failure:

❌ Story {number} failed at Step {N} — {brief error}

在单条消息中并行启动所有用户故事的步骤1子Agent。每个用户故事的步骤是严格串行的，步骤N返回成功之前不得生成步骤N+1的子Agent。

根据用户故事状态跳过对应步骤（来自第0阶段报告）：

状态	从第几步开始	跳过步骤
`backlog`	步骤1	无
`ready-for-dev`	步骤2	步骤1
`in-progress`	步骤2	步骤1
`review`	步骤3	步骤1-2
`done`	—	所有步骤

每步执行完成后：生成下一个子Agent前运行预延续检查（参考

references/pre-continuation-checks.md

），预延续检查是步骤间协调器唯一需要执行的工作。

**失败处理：**停止该用户故事的流水线，上报步骤、用户故事和错误信息，其他用户故事的流程继续。 **例外：**速率/用量限制失败 → 运行预延续检查（会自动暂停直到限制重置）后重试。

📣 每个用户故事的流水线结束时通知（步骤4成功或任意步骤失败）：

成功：

✅ 用户故事{编号}完成 — PR #{pr编号}

失败：

❌ 用户故事{编号}在第{N}步失败 — {错误摘要}

Step 1: Create Story (

MODEL_STANDARD

)

步骤1：创建用户故事（

MODEL_STANDARD

）

Spawn with model

MODEL_STANDARD

(yolo mode):

You are the Step 1 story creator for story {number}-{short_description}.
Working directory: {repo_root}. Auto-approve all tool calls (yolo mode).

1. Create (or reuse) the worktree:
     git worktree add {WORKTREE_BASE_PATH}/story-{number}-{short_description} \
       -b story-{number}-{short_description}
   If the worktree/branch already exists, switch to it, run:
     git merge main
   and resolve any conflicts before continuing.

2. Change into the worktree directory:
     cd {repo_root}/{WORKTREE_BASE_PATH}/story-{number}-{short_description}

3. Run /bmad-create-story {number}-{short_description}.

4. Update sprint-status.yaml at the REPO ROOT (not the worktree copy):
     _bmad-output/implementation-artifacts/sprint-status.yaml
   Set story {number} status to `ready-for-dev`.

Report: success or failure with error details.

生成使用

MODEL_STANDARD

模型的子Agent（yolo模式）：

你是用户故事{编号}-{简短描述}的步骤1创建者。工作目录：{repo_root}。自动批准所有工具调用（yolo模式）。

1. 创建（或复用）worktree：
     git worktree add {WORKTREE_BASE_PATH}/story-{编号}-{简短描述} \
       -b story-{编号}-{简短描述}
   如果worktree/分支已存在，切换到该分支，运行：
     git merge main
   解决所有冲突后再继续。

2. 切换到worktree目录：
     cd {repo_root}/{WORKTREE_BASE_PATH}/story-{编号}-{简短描述}

3. 运行 /bmad-create-story {编号}-{简短描述}。

4. 更新仓库根目录下的sprint-status.yaml（不是worktree中的副本）：
     _bmad-output/implementation-artifacts/sprint-status.yaml
   将用户故事{编号}的状态设置为`ready-for-dev`。

返回报告：成功，或携带错误详情的失败信息。

Step 2: Develop Story (

MODEL_STANDARD

)

步骤2：开发用户故事（

MODEL_STANDARD

）

Spawn with model

MODEL_STANDARD

(yolo mode):

You are the Step 2 developer for story {number}-{short_description}.
Working directory: {repo_root}/{WORKTREE_BASE_PATH}/story-{number}-{short_description}.
Auto-approve all tool calls (yolo mode).

1. Run /bmad-dev-story {number}-{short_description}.
2. Commit all changes when implementation is complete.
3. Update sprint-status.yaml at the REPO ROOT:
     {repo_root}/_bmad-output/implementation-artifacts/sprint-status.yaml
   Set story {number} status to `review`.

Report: success or failure with error details.

生成使用

MODEL_STANDARD

模型的子Agent（yolo模式）：

你是用户故事{编号}-{简短描述}的步骤2开发者。工作目录：{repo_root}/{WORKTREE_BASE_PATH}/story-{编号}-{简短描述}。自动批准所有工具调用（yolo模式）。

1. 运行 /bmad-dev-story {编号}-{简短描述}。
2. 实现完成后提交所有变更。
3. 更新仓库根目录下的sprint-status.yaml：
     {repo_root}/_bmad-output/implementation-artifacts/sprint-status.yaml
   将用户故事{编号}的状态设置为`review`。

返回报告：成功，或携带错误详情的失败信息。

Step 3: Code Review (

MODEL_QUALITY

)

步骤3：代码评审（

MODEL_QUALITY

）

Spawn with model

MODEL_QUALITY

(yolo mode):

You are the Step 3 code reviewer for story {number}-{short_description}.
Working directory: {repo_root}/{WORKTREE_BASE_PATH}/story-{number}-{short_description}.
Auto-approve all tool calls (yolo mode).

1. Run /bmad-code-review {number}-{short_description}.
2. Auto-accept all findings and apply fixes using your best engineering judgement.
3. Commit any changes from the review.

Report: success or failure with error details.

生成使用

MODEL_QUALITY

模型的子Agent（yolo模式）：

你是用户故事{编号}-{简短描述}的步骤3代码评审者。工作目录：{repo_root}/{WORKTREE_BASE_PATH}/story-{编号}-{简短描述}。自动批准所有工具调用（yolo模式）。

1. 运行 /bmad-code-review {编号}-{简短描述}。
2. 基于最优工程判断自动接受所有评审结论并修复问题。
3. 提交评审产生的所有变更。

返回报告：成功，或携带错误详情的失败信息。

Step 4: PR & CI (

MODEL_STANDARD

)

步骤4：PR与CI（

MODEL_STANDARD

）

Spawn with model

MODEL_STANDARD

(yolo mode):

You are the Step 4 PR and CI agent for story {number}-{short_description}.
Working directory: {repo_root}/{WORKTREE_BASE_PATH}/story-{number}-{short_description}.
Auto-approve all tool calls (yolo mode).

1. Commit all outstanding changes.

2. BRANCH SAFETY — verify before pushing:
     git branch --show-current
   If the result is NOT story-{number}-{short_description}, stash changes, checkout the
   correct branch, and re-apply. Never push to main or create a new branch.

3. Run /commit-commands:commit-push-pr.
   PR title: story-{number}-{short_description} - fixes #{gh_issue_number}
   (look up gh_issue_number from the epic file or sprint-status.yaml; omit "fixes #" if none)
   Add "Fixes #{gh_issue_number}" to the PR description if an issue number exists.

4. CI:
   - If RUN_CI_LOCALLY is true → skip GitHub Actions and run the Local CI Fallback below.
   - Otherwise monitor CI in a loop:
       gh run view
     - Billing/spending limit error → exit loop, run Local CI Fallback
     - CI failed for other reason, or Claude bot left PR comments → fix, push, loop
     - CI green → proceed to step 5

LOCAL CI FALLBACK (when RUN_CI_LOCALLY=true or billing-limited):
  a. Read all .github/workflows/ files triggered on pull_request events.
  b. Extract and run shell commands from each run: step in order (respecting
     working-directory). If any fail, diagnose, fix, and re-run until all pass.
  c. Commit fixes and push to the PR branch.
  d. Post a PR comment:
     ## Test Results (manual — GitHub Actions skipped: billing/spending limit reached)
     | Check | Status | Notes |
     |-------|--------|-------|
     | `<command>` | ✅ Pass / ❌ Fail | e.g. "42 tests passed" |
     ### Fixes applied
     - [failure] → [fix]
     All rows must show ✅ Pass before this step is considered complete.

5. CODE REVIEW — spawn a dedicated MODEL_DEV subagent (yolo mode) after CI passes:

You are the code review agent for story {number}-{short_description}. Working directory: {repo_root}/{WORKTREE_BASE_PATH}/story-{number}-{short_description}. Auto-approve all tool calls (yolo mode).

Run /code-review:code-review (reads the PR diff via gh pr diff).
For every finding, apply a fix using your best engineering judgement. Do not skip or defer any finding — fix them all.
Commit all fixes and push to the PR branch.
If any fixes were pushed, re-run /code-review:code-review once more to confirm no new issues were introduced. Repeat fix → commit → push → re-review until the review comes back clean.

Report: clean (no findings or all fixed) or failure with details.

Wait for the subagent to report before continuing. If it reports failure,
stop this story and surface the error.

6. Update sprint-status.yaml at the REPO ROOT:
  {repo_root}/_bmad-output/implementation-artifacts/sprint-status.yaml
Set story {number} status to `done`.

Report: success or failure, and the PR number/URL if opened.

生成使用

MODEL_STANDARD

模型的子Agent（yolo模式）：

你是用户故事{编号}-{简短描述}的步骤4 PR与CI Agent。工作目录：{repo_root}/{WORKTREE_BASE_PATH}/story-{编号}-{简短描述}。自动批准所有工具调用（yolo模式）。

1. 提交所有未提交的变更。

2. 分支安全检查 — 推送前确认：
     git branch --show-current
   如果返回结果不是story-{编号}-{简短描述}，暂存变更，切换到正确的分支后重新应用变更。禁止推送到main分支或创建新分支。

3. 运行 /commit-commands:commit-push-pr。
   PR标题：story-{编号}-{简短描述} - fixes #{gh_issue编号}
   （从史诗文件或sprint-status.yaml中查找gh_issue编号；如果没有则省略"fixes #"部分）
   如果存在Issue编号，在PR描述中添加"Fixes #{gh_issue编号}"。

4. CI处理：
   - 如果RUN_CI_LOCALLY为true → 跳过GitHub Actions，执行下方的本地CI兜底方案。
   - 否则循环监控CI状态：
       gh run view
     - 账单/消费限额错误 → 退出循环，执行本地CI兜底方案
     - 其他原因导致CI失败，或Claude机器人在PR留下评论 → 修复、推送、重新循环
     - CI通过 → 进入步骤5

本地CI兜底方案（当RUN_CI_LOCALLY=true或触发账单限额时执行）：
  a. 读取所有pull_request事件触发的.github/workflows/配置文件。
  b. 按顺序提取每个run:步骤中的shell命令执行（遵守工作目录配置）。如果任何命令失败，诊断修复后重新运行直到全部通过。
  c. 提交修复并推送到PR分支。
  d. 在PR下发表评论：
     ## 测试结果（手动执行 — 已跳过GitHub Actions：达到账单/消费限额）
     | 检查项 | 状态 | 备注 |
     |-------|--------|-------|
     | `<command>` | ✅ 通过 / ❌ 失败 | 例如 "42个测试通过" |
     ### 已应用的修复
     - [失败原因] → [修复方案]
     所有行都显示✅通过后，本步骤才算完成。

5. 代码评审 — CI通过后生成一个专属MODEL_DEV子Agent（yolo模式）：

你是用户故事{编号}-{简短描述}的代码评审Agent。工作目录：{repo_root}/{WORKTREE_BASE_PATH}/story-{编号}-{简短描述}。自动批准所有工具调用（yolo模式）。

运行 /code-review:code-review（通过gh pr diff读取PR diff）。
基于最优工程判断修复所有发现的问题，不得跳过或推迟任何问题，全部修复。
提交所有修复并推送到PR分支。
如果推送了任何修复，再次运行/code-review:code-review确认没有引入新问题。重复修复→提交→推送→重新评审流程，直到评审无问题。

返回报告：无问题（无发现或全部修复），或携带详情的失败信息。

等待子Agent返回报告后再继续。如果报告失败，停止该用户故事的流程并上报错误。

6. 更新仓库根目录下的sprint-status.yaml：
  {repo_root}/_bmad-output/implementation-artifacts/sprint-status.yaml
将用户故事{编号}的状态设置为`done`。

返回报告：成功或失败，以及PR编号/URL（如果已创建PR）。

Phase 3: Auto-Merge Batch PRs (when

AUTO_PR_MERGE=true

)

第3阶段：自动合并批次PR（当

AUTO_PR_MERGE=true

时执行）

After all batch stories complete Phase 2, merge every successful story's PR into

main

— one subagent per story, sequentially (lowest story number first).

Why sequential: Merging lowest-first ensures each subsequent merge rebases against a main that already contains its predecessors — keeping conflict resolution incremental and predictable.

Steps:

Collect all stories from the current batch that reached Step 4 successfully (have a PR). Sort ascending by story number.
For each story sequentially (wait for each to complete before starting the next):
- Pull latest main at the repo root: spawn a quick subagent or include in the merge subagent.
- Spawn a
```
MODEL_STANDARD
```
  subagent (yolo mode) with the instructions from
```
references/phase4-auto-merge.md
```
  .
- Run Pre-Continuation Checks after the subagent completes. If it fails (unresolvable conflict, CI blocking), report the error and continue to the next story.

Print a merge summary (coordinator formats from subagent reports):

Auto-Merge Results:
Story   | PR    | Outcome
--------|-------|--------
6.1     | #142  | Merged ✅
6.2     | #143  | Merged ✅ (conflict resolved: src/foo.ts)
6.3     | #144  | Failed ❌ (CI blocking — manual merge required)

📣 Notify after all merges are processed (coordinator formats from subagent reports):

🔀 Auto-merge complete
{story}: ✅ PR #{pr} | {story}: ✅ PR #{pr} (conflict resolved) | {story}: ❌ manual merge needed

Spawn a cleanup subagent (

MODEL_STANDARD

, yolo mode):

Post-merge cleanup. Auto-approve all tool calls (yolo mode).

1. Verify sprint-status.yaml at the repo root has status `done` for all merged stories.
   Fix any that are missing.

2. Repo root branch safety check:
     git branch --show-current
   If not main:
     git restore .
     git switch main
     git reset --hard origin/main
   If switch fails because a worktree claims the branch:
     git worktree list
     git worktree remove --force <path>
     git switch main
     git reset --hard origin/main

3. Pull main:
     git pull --ff-only origin main

Report: done or any errors encountered.

当前批次所有用户故事完成第2阶段后，将所有成功用户故事的PR合并到

main

分支 — 每个用户故事对应一个子Agent，串行执行（按用户故事编号从小到大执行）。

**为什么串行：**按编号从低到高合并可以确保后续合并的代码基于已包含前序变更的main分支，让冲突解决是增量且可预测的。

步骤：

收集当前批次中成功完成第4步的所有用户故事（已创建PR），按用户故事编号升序排序。
串行处理每个用户故事（等待上一个完成后再开始下一个）：
- 在仓库根目录拉取最新main代码：生成一个快速子Agent，或在合并子Agent中包含该操作。
- 生成一个使用
```
MODEL_STANDARD
```
  模型的子Agent（yolo模式），传入
```
references/phase4-auto-merge.md
```
  中的指令。
- 子Agent完成后运行预延续检查。如果失败（无法解决的冲突、CI阻塞），上报错误并继续处理下一个用户故事。

打印合并摘要（协调器基于子Agent报告格式化）：

自动合并结果：
用户故事   | PR    | 结果
--------|-------|--------
6.1     | #142  | 已合并 ✅
6.2     | #143  | 已合并 ✅（已解决冲突：src/foo.ts）
6.3     | #144  | 失败 ❌（CI阻塞 — 需要手动合并）

📣 所有合并处理完成后通知（协调器基于子Agent报告格式化）：

🔀 自动合并完成
{用户故事}: ✅ PR #{pr编号} | {用户故事}: ✅ PR #{pr编号}（已解决冲突） | {用户故事}: ❌ 需要手动合并

生成一个清理子Agent（

MODEL_STANDARD

，yolo模式）：

合并后清理。自动批准所有工具调用（yolo模式）。

1. 确认仓库根目录下的sprint-status.yaml中所有已合并用户故事的状态为`done`，修复缺失的状态。

2. 仓库根目录分支安全检查：
     git branch --show-current
   如果不在main分支：
     git restore .
     git switch main
     git reset --hard origin/main
   如果切换失败，因为某个worktree占用了该分支：
     git worktree list
     git worktree remove --force <路径>
     git switch main
     git reset --hard origin/main

3. 拉取main分支代码：
     git pull --ff-only origin main

返回报告：完成，或遇到的任何错误。

Phase 4: Batch Completion & Continuation

第4阶段：批次完成与流程延续

Step 1: Print Batch Summary

步骤1：打印批次摘要

Coordinator prints immediately — no file reads, formats from Phase 2 step results:

Story   | Step 1 | Step 2 | Step 3 | Step 4 | Result
--------|--------|--------|--------|--------|-------
9.1     |   OK   |   OK   |   OK   |   OK   | PR #142
9.2     |   OK   |   OK   |  FAIL  |   --   | Review failed: ...
9.3     |   OK   |   OK   |   OK   |   OK   | PR #143

If arriving from Phase 1 with no ready stories:

No stories ready to work on.
Blocked stories: {from Phase 0 report}

📣 Notify with the batch summary (same content, condensed to one line per story):

📦 Batch complete — {N} stories
{number} ✅ PR #{pr} | {number} ❌ Step {N} | ...

Or if no stories were ready:

⏸ No stories ready — waiting for PRs to merge

协调器立即打印 — 无需读取文件，基于第2阶段的步骤结果格式化：

用户故事   | 步骤1 | 步骤2 | 步骤3 | 步骤4 | 结果
--------|--------|--------|--------|--------|-------
9.1     |   完成   |   完成   |   完成   |   完成   | PR #142
9.2     |   完成   |   完成   |  失败  |   --   | 评审失败：...
9.3     |   完成   |   完成   |   完成   |   完成   | PR #143

如果从第1阶段跳转过来且无就绪用户故事：

无就绪的用户故事。
阻塞的用户故事：{来自第0阶段报告}

📣 发送批次摘要通知（内容相同，简化为每个用户故事一行）：

📦 批次完成 — {N}个用户故事
{编号} ✅ PR #{pr编号} | {编号} ❌ 第{N}步失败 | ...

如果无就绪用户故事则发送：

⏸ 无就绪用户故事 — 等待PR合并

Step 2: Check for Epic Completion

步骤2：检查史诗完成情况

Spawn an assessment subagent (

MODEL_STANDARD

, yolo mode):

Epic completion assessment. Auto-approve all tool calls (yolo mode).

Read:
  - _bmad-output/planning-artifacts/epics.md
  - _bmad-output/implementation-artifacts/sprint-status.yaml

Report back:
  - current_epic_complete: true/false (all stories done or have open PRs)
  - all_epics_complete: true/false (every story across every epic is done)
  - current_epic_name: name/number of the lowest incomplete epic
  - next_epic_name: name/number of the next epic (if any)
  - stories_remaining: count of non-done stories in the current epic

Using the assessment report:

If
current_epic_complete = true
:

Print:

🎉 Epic {current_epic_name} is complete! Starting retrospective countdown ({RETRO_TIMER_SECONDS ÷ 60} minutes)...

📣 Notify:

🎉 Epic {current_epic_name} complete! Running retrospective in {RETRO_TIMER_SECONDS ÷ 60} min...

Start a timer using the Timer Pattern with:

Duration:
```
RETRO_TIMER_SECONDS
```

Fire prompt:

"BAD_RETRO_TIMER_FIRED — The retrospective countdown has elapsed. Auto-run the retrospective: spawn a MODEL_DEV subagent (yolo mode) to run /bmad-retrospective, accept all changes. Run Pre-Continuation Checks after it completes, then proceed to Phase 4 Step 3."

[C] label:
```
Run retrospective now
```
[S] label:
```
Skip retrospective
```
[C] / FIRED action: Spawn MODEL_DEV subagent (yolo mode) to run
```
/bmad-retrospective
```
. Accept all changes. Run Pre-Continuation Checks after.
[S] action: Skip retrospective.

Proceed to Step 3 after the retrospective decision resolves.

生成一个评估子Agent（

MODEL_STANDARD

，yolo模式）：

史诗完成情况评估。自动批准所有工具调用（yolo模式）。

读取以下文件：
  - _bmad-output/planning-artifacts/epics.md
  - _bmad-output/implementation-artifacts/sprint-status.yaml

返回以下报告：
  - current_epic_complete: 布尔值，当前史诗是否完成（所有故事已完成或已有开放PR）
  - all_epics_complete: 布尔值，所有史诗的所有用户故事是否都已完成
  - current_epic_name: 最靠前的未完成史诗的名称/编号
  - next_epic_name: 下一个史诗的名称/编号（如有）
  - stories_remaining: 当前史诗中未完成的用户故事数量

基于评估报告执行对应逻辑：

如果
current_epic_complete = true
：

打印：

🎉 史诗{current_epic_name}已完成！启动回顾倒计时（{RETRO_TIMER_SECONDS ÷ 60}分钟）...

📣 通知：

🎉 史诗{current_epic_name}已完成！{RETRO_TIMER_SECONDS ÷ 60}分钟后运行回顾...

使用**定时器模式**启动定时器，配置如下：

时长：
```
RETRO_TIMER_SECONDS
```

触发提示：

"BAD_RETRO_TIMER_FIRED — 回顾倒计时已结束。自动运行回顾：生成MODEL_DEV子Agent（yolo模式）运行/bmad-retrospective，接受所有变更。完成后运行预延续检查，然后进入第4阶段第3步。"

[C] 标签：
```
立即运行回顾
```
[S] 标签：
```
跳过回顾
```
[C] / 触发动作： 生成MODEL_DEV子Agent（yolo模式）运行
```
/bmad-retrospective
```
，接受所有变更，完成后运行预延续检查。
[S] 动作： 跳过回顾。

回顾决策处理完成后进入第3步。

Step 3: Gate & Continue

步骤3：关卡与延续

Using the assessment report from Step 2, follow the applicable branch:

Branch A — All epics complete (
all_epics_complete = true
):

🏁 All epics are complete — sprint is done! BAD is stopping.

📣 Notify:

🏁 Sprint complete — all epics done! BAD is stopping.

Branch B — More work remains:

Print a status line:

Epic just completed:

✅ Epic {current_epic_name} complete. Next up: Epic {next_epic_name} ({stories_remaining} stories remaining).

Notify Pattern

通知模式

Use this pattern every time a

📣 Notify:

callout appears anywhere in this skill — including inside the Timer Pattern.

If
NOTIFY_SOURCE="telegram"
: call

mcp__plugin_telegram_telegram__reply

with:

```
chat_id
```
:
```
NOTIFY_CHAT_ID
```
```
text
```
: the message

If
NOTIFY_SOURCE="terminal"
(or if the Telegram tool call fails): print the message in the conversation as a normal response.

Always send both a terminal print and a channel message — the terminal print keeps the in-session transcript readable, and the channel message reaches the user on their device.

本技能中任何位置出现

📣 通知:

提示时都使用该模式，包括定时器模式内部的通知。

如果
NOTIFY_SOURCE="telegram"
：调用

mcp__plugin_telegram_telegram__reply

，参数为：

```
chat_id
```
:
```
NOTIFY_CHAT_ID
```
```
text
```
: 通知消息

如果
NOTIFY_SOURCE="terminal"
（或Telegram工具调用失败）：在会话中作为普通响应打印消息。

始终同时发送终端打印和频道消息：终端打印可以保持会话记录的可读性，频道消息可以让用户在设备上收到通知。

Timer Pattern

定时器模式

Both the retrospective and post-batch wait timers use this pattern. The caller supplies the duration, fire prompt, option labels, and actions.

Behaviour depends on

TIMER_SUPPORT

回顾定时器和批次后等待定时器都使用该模式。调用方提供时长、触发提示、选项标签和对应动作。

行为取决于

TIMER_SUPPORT

配置：

TIMER_SUPPORT=true

(native platform timers)

如果

TIMER_SUPPORT=true

（使用平台原生定时器）

Step 1 — compute target cron expression (convert seconds to minutes:

SECONDS ÷ 60

bash

undefined

步骤1 — 计算目标cron表达式（将秒转换为分钟：

秒数 ÷ 60

）：

bash

undefined

macOS

date -v +{N}M '+%M %H %d %m *'

Linux

date -d '+{N} minutes' '+%M %H %d %m *'

Save as `CRON_EXPR`. Save `TIMER_START=$(date +%s)`.

**Step 2 — create the one-shot timer** via `CronCreate`:
- `cron`: expression from Step 1
- `recurring`: `false`
- `prompt`: the caller-supplied fire prompt

Save the returned job ID as `JOB_ID`.

**Step 3 — print the options menu** (always all three options):
> Timer running (job: {JOB_ID}). I'll act in {N} minutes.
>
> - **[C] Continue** — {C label}
> - **[S] Stop** — {S label}
> - **[M] {N} Modify timer to {N} minutes** — shorten or extend the countdown

📣 **Notify** using the [Notify Pattern](#notify-pattern) with the same options so the user can respond from their device:

⏱ Timer set — {N} minutes (job: {JOB_ID})

[C] {C label} [S] {S label} [M] <minutes> — modify countdown


Wait for whichever arrives first — user reply or fired prompt. On any human reply, print elapsed time first:
```bash
ELAPSED=$(( $(date +%s) - TIMER_START ))
echo "⏱ Time elapsed: $((ELAPSED / 60))m $((ELAPSED % 60))s"

[C] →
```
CronDelete(JOB_ID)
```
, run the [C] action
[S] →
```
CronDelete(JOB_ID)
```
, run the [S] action

[M] N →

CronDelete(JOB_ID)

, recompute cron for N minutes from now,

CronCreate

again with same fire prompt, update

JOB_ID

and

TIMER_START

, print updated countdown, then 📣 Notify using the Notify Pattern:

⏱ Timer updated — {N} minutes (job: {JOB_ID})

[C] {C label}
[S] {S label}
[M] <minutes> — modify countdown

FIRED (no prior reply) → run the [C] action automatically

date -d '+{N} minutes' '+%M %H %d %m *'

保存为`CRON_EXPR`，保存`TIMER_START=$(date +%s)`。

**步骤2 — 通过`CronCreate`创建一次性定时器**：
- `cron`: 步骤1生成的表达式
- `recurring`: `false`
- `prompt`: 调用方提供的触发提示

将返回的任务ID保存为`JOB_ID`。

**步骤3 — 打印选项菜单**（始终显示三个选项）：
> 定时器运行中（任务ID：{JOB_ID}），我将在{N}分钟后执行操作。
>
> - **[C] 继续** — {C标签}
> - **[S] 停止** — {S标签}
> - **[M] {N} 修改定时器为{N}分钟** — 缩短或延长倒计时

📣 **使用[通知模式](#notify-pattern)发送相同选项的通知**，方便用户在设备上直接响应：

⏱ 定时器已设置 — {N}分钟（任务ID：{JOB_ID}）

[C] {C标签} [S] {S标签} [M] <分钟数> — 修改倒计时时长


等待先到达的事件：用户回复或定时器触发。收到任何人工回复时，先打印已流逝的时间：
```bash
ELAPSED=$(( $(date +%s) - TIMER_START ))
echo "⏱ 已流逝时间：$((ELAPSED / 60))分 $((ELAPSED % 60))秒"

[C] → 执行
```
CronDelete(JOB_ID)
```
，运行[C]对应的动作
[S] → 执行
```
CronDelete(JOB_ID)
```
，运行[S]对应的动作
[M] N → 执行
```
CronDelete(JOB_ID)
```
，重新计算从现在开始N分钟后的cron表达式，使用相同的触发提示重新执行
```
CronCreate
```
，更新
```
JOB_ID
```
和
```
TIMER_START
```
，打印更新后的倒计时，然后📣 使用通知模式发送通知：
```
⏱ 定时器已更新 — {N}分钟（任务ID：{JOB_ID}）

[C] {C标签}
[S] {S标签}
[M] <分钟数> — 修改倒计时时长
```
触发（无预先回复） → 自动运行[C]对应的动作

TIMER_SUPPORT=false

(prompt-based continuation)

如果

TIMER_SUPPORT=false

（使用基于提示的延续机制）

Save

TIMER_START=$(date +%s)

. No native timer is created — print the options menu immediately and wait for user reply:

Waiting {N} minutes before continuing. Reply when ready.
[C] Continue — {C label}

[S] Stop — {S label}
[M] N — remind me after N minutes (reply with
[M] <minutes>
)

📣 Notify using the Notify Pattern with the same options.

On any human reply, print elapsed time first:

bash

ELAPSED=$(( $(date +%s) - TIMER_START ))
echo "⏱ Time elapsed: $((ELAPSED / 60))m $((ELAPSED % 60))s"

[C] → run the [C] action
[S] → run the [S] action
[M] N → update
```
TIMER_START
```
, print updated wait message, 📣 Notify, and wait again

保存

TIMER_START=$(date +%s)

，不创建原生定时器，立即打印选项菜单并等待用户回复：

继续前等待{N}分钟，准备好后回复即可。
[C] 继续 — {C标签}

[S] 停止 — {S标签}
[M] N — N分钟后提醒我（回复
[M] <分钟数>
）

📣 使用通知模式发送相同选项的通知。

收到任何人工回复时，先打印已流逝的时间：

bash

ELAPSED=$(( $(date +%s) - TIMER_START ))
echo "⏱ 已流逝时间：$((ELAPSED / 60))分 $((ELAPSED % 60))秒"

[C] → 运行[C]对应的动作
[S] → 运行[S]对应的动作
[M] N → 更新
```
TIMER_START
```
，打印更新后的等待消息，📣 发送通知，继续等待

Rules

规则

Delegate mode only — never read files, run git/gh commands, or write to disk yourself. The only platform command the coordinator may run directly is context compaction via Pre-Continuation Checks (when
```
CONTEXT_COMPACTION_THRESHOLD
```
is exceeded). All other slash commands and operations are delegated to subagents.
One subagent per step per story — spawn only after the previous step reports success.
Sequential steps within a story — Steps 1→2→3→4 run strictly in order.
Parallel stories — launch all stories' Step 1 in one message (one tool call per story). Phase 3 runs sequentially by design.
Dependency graph is authoritative — never pick a story whose dependencies are not fully merged. Use Phase 0's report, not your own file reads.
Phase 0 runs before every batch — always after the Phase 4 wait. Always as a fresh subagent.
Confirm success before spawning the next subagent.
sprint-status.yaml is updated by step subagents — each step subagent writes to the repo root copy. The coordinator never does this directly.
On failure — report the error, halt that story. No auto-retry. Exception: rate/usage limit failures → run Pre-Continuation Checks (auto-pauses until reset) then retry.
Issue all Step 1 subagent calls in one response when Phase 2 begins. After each story's Step 1 completes, issue that story's Step 2 — never wait for all stories' Step 1 to finish before issuing any Step 2.

仅委托模式 — 不得自行读取文件、运行git/gh命令，也不得直接写入磁盘。协调器唯一可以直接运行的平台命令是超过
```
CONTEXT_COMPACTION_THRESHOLD
```
时通过预延续检查执行的上下文压缩。所有其他斜杠命令和操作都委托给子Agent执行。
每个用户故事的每个步骤对应一个子Agent — 仅在上一步返回成功后生成。
用户故事内步骤串行 — 步骤1→2→3→4严格按顺序执行。
用户故事并行处理 — 单条消息中启动所有用户故事的步骤1（每个用户故事对应一个工具调用）。第3阶段按设计为串行执行。
依赖图是权威依据 — 不得挑选依赖未完全合并的用户故事，使用第0阶段的报告，不得自行读取文件判断。
每个批次前都运行第0阶段 — 始终在第4阶段等待后执行，始终使用新的子Agent。
生成下一个子Agent前确认上一步成功。
sprint-status.yaml由步骤子Agent更新 — 每个步骤的子Agent写入仓库根目录的副本，协调器不得直接修改。
失败处理 — 上报错误，停止该用户故事的流程，无自动重试。**例外：**速率/用量限制失败 → 运行预延续检查（自动暂停直到限制重置）后重试。
第2阶段开始时在单次响应中发起所有步骤1的子Agent调用。每个用户故事的步骤1完成后，立即发起该用户故事的步骤2，不得等待所有用户故事的步骤1完成后再发起步骤2。

bad

Original

Translation

BAD — BMad Autonomous Development

BAD — BMad自主开发工具

On Activation

激活时操作

Startup: Capture Channel Context

启动：获取频道上下文

Configuration

配置

Pipeline

流水线

Phase 0: Build or Update the Dependency Graph

第0阶段：构建或更新依赖图

Phase 1: Discover Stories

第1阶段：筛选用户故事

Phase 2: Run the Pipeline

第2阶段：运行流水线

Step 1: Create Story (MODEL_STANDARD)

步骤1：创建用户故事（MODEL_STANDARD）

Step 2: Develop Story (MODEL_STANDARD)

步骤2：开发用户故事（MODEL_STANDARD）

Step 3: Code Review (MODEL_QUALITY)

步骤3：代码评审（MODEL_QUALITY）

Step 4: PR & CI (MODEL_STANDARD)

步骤4：PR与CI（MODEL_STANDARD）

Phase 3: Auto-Merge Batch PRs (when AUTO_PR_MERGE=true)

第3阶段：自动合并批次PR（当AUTO_PR_MERGE=true时执行）

Phase 4: Batch Completion & Continuation

第4阶段：批次完成与流程延续

Step 1: Print Batch Summary

步骤1：打印批次摘要

Step 2: Check for Epic Completion

步骤2：检查史诗完成情况

Step 3: Gate & Continue

步骤3：关卡与延续

Notify Pattern

通知模式

Timer Pattern

定时器模式

If TIMER_SUPPORT=true (native platform timers)

如果TIMER_SUPPORT=true（使用平台原生定时器）

macOS

macOS

Linux

Linux

If TIMER_SUPPORT=false (prompt-based continuation)

如果TIMER_SUPPORT=false（使用基于提示的延续机制）

Rules

规则

Step 1: Create Story (
`MODEL_STANDARD`
)

步骤1：创建用户故事（
`MODEL_STANDARD`
）

Step 2: Develop Story (
`MODEL_STANDARD`
)

步骤2：开发用户故事（
`MODEL_STANDARD`
）

Step 3: Code Review (
`MODEL_QUALITY`
)

步骤3：代码评审（
`MODEL_QUALITY`
）

Step 4: PR & CI (
`MODEL_STANDARD`
)

步骤4：PR与CI（
`MODEL_STANDARD`
）

Phase 3: Auto-Merge Batch PRs (when
`AUTO_PR_MERGE=true`
)

第3阶段：自动合并批次PR（当
`AUTO_PR_MERGE=true`
时执行）

If
`TIMER_SUPPORT=true`
(native platform timers)

如果
`TIMER_SUPPORT=true`
（使用平台原生定时器）

If
`TIMER_SUPPORT=false`
(prompt-based continuation)

如果
`TIMER_SUPPORT=false`
（使用基于提示的延续机制）