bad

BAD — BMad Autonomous Development

On Activation

Check if {project-root}/_bmad/config.yaml contains a bad section. If not — or if the user passed setup or 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 via the Agent tool. You never read files, run git/gh commands, or write to disk yourself.

Coordinator-only responsibilities:

• Pick stories from subagent-reported data
• Call the Agent tool to spawn subagents (in parallel where allowed — multiple Agent tool calls in one message)
• 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 inside Agent tool subagents with fresh context windows.

Startup: Capture Channel Context

Before doing anything else, determine how to send notifications:

1. 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".

2. Send the BAD started notification using the Notify Pattern:

   🤖 BAD started — building dependency graph...
   

Then proceed to Phase 0.

---

Configuration

Load base values from the bad section of _bmad/config.yaml at startup. 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 all subagents except Step 5 (code review): Phase 0, Phase 1 Epic-Start, Steps 1–4 and 6–7, Phase 3 (merge + cleanup), Phase 4 (assessment + retrospective)
MODEL_QUALITY	model_quality	opus	Model for Step 5 (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
STALE_TIMEOUT_MINUTES	stale_timeout_minutes	60	Minutes of subagent inactivity before watchdog alerts (0 = disabled)
TIMER_SUPPORT	timer_support	true	When true, use native platform timers; when false, use prompt-based continuation
MONITOR_SUPPORT	monitor_support	true	When true, use the Monitor tool for CI and PR-merge polling; when false, fall back to manual polling loops (required for Bedrock/Vertex/Foundry)
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, ...

---

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

---

Phase 0: Build or Update the Dependency Graph

Before spawning the subagent, create the full initial task list using TaskCreate so the user can see the complete pipeline at a glance. Mark Phase 0 in_progress; all others start as [ ]. Apply the Phase 3 rule at creation time:

[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

Call the Agent tool with model: MODEL_STANDARD, description: "Phase 0: dependency graph", and this prompt. The coordinator waits for the report.

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

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)

After Phase 0 completes, rebuild the task list in correct execution order — tasks display in creation order, so delete and re-add to ensure Phase 2 story tasks appear before Phase 3 and Phase 4:

1. Mark Phase 0: Dependency graph → completed
2. Mark Phase 1: Story selection → completed (already done)
3. Delete all nine generic startup tasks: the seven Phase 2: Step N tasks, Phase 3: Auto-merge, and Phase 4: Batch summary + continuation
4. Re-add in execution order using 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

Update each story step task to in_progress when its subagent is spawned, and completed (or failed) when it reports back. Update Phase 3 and Phase 4 tasks similarly as they execute.

---

Phase 1: Discover Stories

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

1. 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.
2. 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).
3. Epic transition detection: Compare the selected stories' epic to CURRENT_EPIC (a coordinator variable, initially unset).
   • If CURRENT_EPIC is unset or the selected stories belong to a different epic → update CURRENT_EPIC and run Epic-Start Test Design (below) as a blocking subagent before Phase 2 begins.
   • Otherwise → proceed directly to Phase 2.

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.

Epic-Start Test Design (MODEL_STANDARD)

Spawn before Phase 2 when starting a new epic (blocking — wait for completion before story pipelines begin):

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 det

---

*Content truncated.*