bad

Name: bad
Author: stephenleo

github.com/stephenleoAgent 工作流107267 次安装27 周前更新

代码仓库

关于 bad

BAD 是用于协调 BMad 自主开发流程的 Agent 技能，通过子 Agent 推进依赖分析、故事开发、评审及 PR 流程。它按故事状态和阶段顺序安排工作，并支持并行处理故事。

主要功能

01通过子 Agent 协调开发步骤
02构建并更新故事依赖图
03按阶段顺序推进故事流程
04在允许时并行处理多个故事
05跟踪 PR、CI 与合并状态

适用场景

01协调多个故事的开发与审查
02依据依赖关系选择可启动的故事
03为新 Epic 安排测试设计
04跟踪批次的 PR、CI 和后续处理

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/stephenleo/bmad-autonomous-development --skill bad

安装后在 Claude Code 中输入/bad确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

assets/

bad-statusline.sh

module-help.csv

module-setup.md

module.yaml

references/coordinator/

gate-pre-continuation.md

pattern-gh-curl-fallback.md

pattern-monitor.md

pattern-notify.md

pattern-timer.md

pattern-watchdog.md

setup-statusline-hook.md

references/subagents/

phase0-graph.md

phase0-prompt.md

phase3-cleanup.md

phase3-merge.md

phase4-assessment.md

step6-ci-fallback.md

scripts/

merge-config.py

merge-help-csv.py

setup-activity-hook.py

详细介绍

BAD — BMad 自主开发

激活时

检查 {project-root}/_bmad/config.yaml 是否包含 bad 部分。如果没有，或者用户将 setup 或 configure 作为参数传入，则加载 ./assets/module-setup.md，并在继续之前完成注册。

即使模块已注册，setup/configure 参数也始终会触发加载 ./assets/module-setup.md（用于重新配置）。

完成设置后（或配置已存在时），加载 bad 配置，然后继续执行下方的启动流程。

你是协调器。你要通过 Agent 工具将每一步委派给子 Agent。你绝不会亲自读取文件、运行 git/gh 命令或写入磁盘。

协调器专属职责：

根据子 Agent 报告的数据选择故事
调用 Agent 工具以生成子 Agent（在允许时并行调用——在同一条消息中多次调用 Agent 工具）
管理计时器（CronCreate / CronDelete）
执行继续前检查（需要会话 stdin JSON——仅限协调器执行）
处理用户输入、输出摘要并发送频道通知

其他所有事项——读取文件、执行 git 操作、运行 gh 命令、写入磁盘——都由拥有全新上下文窗口的 Agent 工具子 Agent 完成。

启动：捕获频道上下文

在进行任何其他操作之前，确定如何发送通知：

检查是否连接了频道——查看当前对话上下文：
- 如果看到 <channel source="telegram" chat_id="..." ...> 标签，则保存 NOTIFY_CHAT_ID 和 NOTIFY_SOURCE="telegram"。
- 如果连接了其他类型的频道，则保存其对应的标识符。
- 如果未连接频道，则设置 NOTIFY_SOURCE="terminal"。

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

🤖 BAD started — building dependency graph...

然后继续执行阶段 0。

Configuration

启动时从 _bmad/config.yaml 的 bad 部分加载基础值。然后解析传递给 /bad 的参数中的任意 KEY=VALUE 覆盖项——参数优先于配置。对于未在配置或参数中设置的变量，使用下表中的默认值。

变量	配置键	默认值	说明
`MAX_PARALLEL_STORIES`	`max_parallel_stories`	`3`	单个批次中运行的最大故事数
`WORKTREE_BASE_PATH`	`worktree_base_path`	`.worktrees`	Git worktree 的根目录
`MODEL_STANDARD`	`model_standard`	`sonnet`	除步骤 5（代码审查）外，所有子 Agent 使用的模型：阶段 0、阶段 1 Epic-Start、步骤 1–4 和 6–7、阶段 3（合并 + 清理）、阶段 4（评估 + 回顾）
`MODEL_QUALITY`	`model_quality`	`opus`	步骤 5（代码审查）使用的模型
`RETRO_TIMER_SECONDS`	`retro_timer_seconds`	`600`	Epic 完成后的自动回顾倒计时（10 分钟）
`WAIT_TIMER_SECONDS`	`wait_timer_seconds`	`3600`	批次完成后等待一段时间，再重新检查 PR 状态（1 小时）
`CONTEXT_COMPACTION_THRESHOLD`	`context_compaction_threshold`	`80`	压缩／总结上下文时所对应的上下文窗口占用百分比
`STALE_TIMEOUT_MINUTES`	`stale_timeout_minutes`	`60`	子 Agent 不活动多少分钟后由 watchdog 发出提醒（0 = 禁用）
`TIMER_SUPPORT`	`timer_support`	`true`	为 `true` 时使用平台原生计时器；为 `false` 时使用基于提示词的续接方式
`MONITOR_SUPPORT`	`monitor_support`	`true`	为 `true` 时使用 Monitor 工具轮询 CI 和 PR 合并状态；为 `false` 时回退到手动轮询循环（Bedrock/Vertex/Foundry 必需）
`API_FIVE_HOUR_THRESHOLD`	`api_five_hour_threshold`	`80`	（Claude Code）触发暂停的 5 小时速率限制百分比
`API_SEVEN_DAY_THRESHOLD`	`api_seven_day_threshold`	`95`	（Claude Code）触发暂停的 7 天速率限制百分比
`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 config: 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 new epic → Epic-Start Test Design [subagent, blocking]
           └─ 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 → Step 5 → Step 6 → Step 7
  ├─► Story B ──► Step 1 → Step 2 → Step 3 → Step 4 → Step 5 → Step 6 → Step 7
  └─► Story C ──► Step 1 → Step 2 → Step 3 → Step 4 → Step 5 → Step 6 → Step 7
  │
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 前，使用 TaskCreate 创建完整的初始任务列表，让用户一目了然地看到整个工作流。将阶段 0 标记为 in_progress；其他任务均以 [ ] 开始。在创建时应用阶段 3 规则：

[in_progress] Phase 0: Dependency graph
[ ] Phase 1: Story selection
[ ] Phase 2: Step 1 — Create story
[ ] Phase 2: Step 2 — ATDD
[ ] Phase 2: Step 3 — Develop
[ ] Phase 2: Step 4 — Test review
[ ] Phase 2: Step 5 — Code review
[ ] Phase 2: Step 6 — PR + CI
[ ] Phase 2: Step 7 — PR review
[ ] Phase 3: Auto-merge                                      ← if AUTO_PR_MERGE=true
[completed] Phase 3: Auto-merge — skipped (AUTO_PR_MERGE=false)  ← if AUTO_PR_MERGE=false
[ ] Phase 4: Batch summary + continuation

使用 model: MODEL_STANDARD、description: "Phase 0: dependency graph" 调用 Agent 工具，并提供以下提示词。协调器等待报告。

Read `references/subagents/phase0-prompt.md` and follow its instructions exactly.

协调器根据报告推进阶段 1。协调器不在本地读取文件。

📣 通知（阶段 0 完成后）：

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

阶段 0 完成后，按正确的执行顺序重建任务列表——任务按创建顺序显示，因此请删除并重新添加任务，以确保阶段 2 的故事任务显示在阶段 3 和阶段 4 之前：

将 Phase 0: Dependency graph 标记为 completed
将 Phase 1: Story selection 标记为 completed（已完成）
删除所有九个通用启动任务：七个 Phase 2: Step N 任务、Phase 3: Auto-merge 和 Phase 4: Batch summary + continuation
使用 TaskCreate 按执行顺序重新添加：

[ ] Phase 1: Epic-Start Test Design            ← add once if new epic, before all story tasks
[ ] Phase 2 | Story {N}: Step 1 — Create story ← one set per selected story, all stories first
[ ] Phase 2 | Story {N}: Step 2 — ATDD
[ ] Phase 2 | Story {N}: Step 3 — Develop
[ ] Phase 2 | Story {N}: Step 4 — Test review
[ ] Phase 2 | Story {N}: Step 5 — Code review
[ ] Phase 2 | Story {N}: Step 6 — PR + CI
[ ] Phase 2 | Story {N}: Step 7 — PR review
                                               ← repeat for each story in the batch
[ ] Phase 3: Auto-merge                        ← if AUTO_PR_MERGE=true
[completed] Phase 3: Auto-merge — skipped (AUTO_PR_MERGE=false)  ← if AUTO_PR_MERGE=false
[ ] Phase 4: Batch summary + continuation

启动子 Agent 时，将每个故事步骤任务更新为 in_progress；子 Agent 返回报告后，将其更新为 completed（或 failed）。阶段 3 和阶段 4 的任务也应在执行过程中相应更新。

阶段 1：发现故事

纯协调器逻辑 — 不读取文件，不调用工具。

从阶段 0 的 ready_stories 报告中，最多选择 MAX_PARALLEL_STORIES 个故事。
- 严格执行史诗顺序： 只能选择最早未完成史诗中的故事。如果史诗 N-1（或更早）的任何故事尚未合并，绝不能选择史诗 N 中的故事 — 请依据阶段 0 报告进行核对。
如果没有故事准备就绪 → 告知用户哪些故事受阻（依据阶段 0 的警告），然后跳转到 阶段 4，第 3 步（关卡与继续）。
检测史诗切换： 将所选故事所属的史诗与 CURRENT_EPIC（协调器变量，初始未设置）进行比较。
- 如果 CURRENT_EPIC 未设置，或所选故事属于不同的史诗 → 更新 CURRENT_EPIC，并在阶段 2 开始前运行 史诗启动测试设计（如下所示），作为一个阻塞式子 Agent。
- 否则 → 直接进入阶段 2。

史诗顺序为何重要： 后续史诗中的故事建立在前序史诗的代码和产品基础之上。在史诗 2 仍有未关闭的 PR 时就开始史诗 3，可能导致合并冲突，或基于仍可能变更的代码进行构建。

史诗启动测试设计（`MODEL_STANDARD`）

开始新史诗时，在阶段 2 之前启动（阻塞 — 等待完成后再开始故事流水线）：

You are the epic test design agent for {current_epic_name}.
Working directory: {repo_root}. Auto-approve all tool calls (yolo mode).

1. Run /bmad-testarch-test-design for {current_epic_name}.
2. Commit any new test plan files.

Report: success or failure with error details.

阶段 2：运行流水线

在同一条消息中并行启动所有故事的第 1 步子 Agent。每个故事的步骤都严格按顺序执行 — 第 N 步报告成功前，不要启动第 N+1 步。

根据故事状态跳过步骤（依据阶段 0 报告）：

状态	从哪一步开始	跳过
`backlog`	第 1 步	无
`ready-for-dev`	第 2 步	第 1 步
`atdd-done`	第 3 步	第 1–2 步
`in-progress`	第 3 步	第 1–2 步
`review`	第 4 步	第 1–3 步
`done`	—	全部

每一步完成后 — 必须执行关卡（即使有并行故事，也绝不能跳过）： 📣 通知步骤结果（格式如下），然后运行继续前检查（references/coordinator/gate-pre-continuation.md）。只有所有检查均通过后 → 才能启动下一个子 Agent。

📣 每一步完成时通知：

成功：✅ Story {number}: Step {N} — {step name}
失败：❌ Story {number}: Step {N} — {step name} failed — {brief error}

步骤名称：第 1 步 — 创建，第 2 步 — ATDD，第 3 步 — 开发，第 4 步 — 测试审查，第 5 步 — 代码审查，第 6 步 — PR + CI，第 7 步 — PR 审查。

失败时： 停止该故事的流水线。报告步骤、故事和错误。其他故事继续。
例外： 遇到速率／用量限制错误时 → 运行继续前检查（该检查会自动暂停，直到重置），然后重试。

子 Agent 卡住时： 当 MONITOR_SUPPORT=true 且已安装活动日志钩子（设置的第 4 步）时，启动第 2、3、4、5 步时使用看门狗模式检测停滞的 Agent。