BMad Autonomous Development — orchestrates parallel story implementation pipelines.

MITAuto-check passedAgent Workflows

Install Bad

skills CLI
$ npx skills add stephenleo/bmad-autonomous-development --skill bad -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install stephenleo/bmad-autonomous-development bad --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/stephenleo/bmad-autonomous-development.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/bad .claude/skills/bad && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
bad
GitHub stars
107
Token cost
~7.7k tokens
SKILL.md length
2,479 words
Files
22 (incl. scripts, references, assets)
Skills in repo
1
Repo updated
First seen
Licence
MIT

At a glance

BMad Autonomous Development — orchestrates parallel story implementation pipelines.

  • Works in 5 steps: Build or Update the Dependency Graph → Discover Stories → Run the Pipeline → …
  • The user says run BAD
  • SKILL.md covers On Activation, Startup: Capture Channel Context, Configuration and Pipeline, plus 11 more sections
  • Runs Shell scripts from its folder; calls git and gh

What it does

Bad is an agent skill from stephenleo/bmad-autonomous-development. BMad Autonomous Development — orchestrates parallel story implementation pipelines. Builds a dependency graph, updates PR status from GitHub, picks stories from the backlog, and runs each through create → dev → review → PR in parallel — each story isolated in its own git worktree — using dedicated subagents with fresh context windows. Loops through the entire sprint plan in batches, with optional epic retrospective. Use when the user says "run BAD", "start autonomous development", "automate the sprint", "run the…

Its SKILL.md is about 7.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 25 other files, including scripts, reference files and assets (for example `assets/bad-statusline.sh`, `assets/module-setup.md` and `assets/module.yaml`).

It sits in Agent Workflows, covering Sprint planning and agile, Pull requests and Context engineering. It works with Git and GitHub. The repository describes itself as: 🤖 Autonomous development orchestrator for the BMad Method. Runs fully autonomous, parallel, multi-agent pipelines through the full story lifecycle (create → dev → review → PR)… The licence is MIT.

When your agent uses it

  • The user says run BAD
  • Start autonomous development
  • Automate the sprint
  • Run the pipeline

Example prompts

  • “run BAD”
  • “start autonomous development”
  • “automate the sprint”
  • “/bad”

Requirements

  • A Bash shell

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Build or Update the Dependency Graph
  2. Discover Stories
  3. Run the Pipeline
  4. Auto-Merge Batch PRs (when AUTO_PR_MERGE=true)
  5. Batch Completion & Continuation

What it can do on your machine

Read from SKILL.md and the folder at commit be7a26c. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (Shell, from the files we listed), which the agent can run.

    Shell commands in SKILL.md call:

    • git
    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Bad loads about 7.7k tokens when it runs, and up to ~17k if it reads all its reference files. Until then it costs about 164 tokens; SKILL.md has 2,479 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~164
When it runs · the whole SKILL.md, loaded when a task matches
~7.7k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~17k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from stephenleo/bmad-autonomous-development at commit be7a26c, republished under its MIT licence (© stephenleo). 2,479 words, ~7,721 tokens.

Download SKILL.mdSave it as .claude/skills/bad/SKILL.md (or your agent's skills folder). This skill also uses 21 other files; get the full folder from GitHub.
name
bad
description
BMad Autonomous Development — orchestrates parallel story implementation pipelines. Builds a dependency graph, updates PR status from GitHub, picks stories from the backlog, and runs each through create → dev → review → PR in parallel — each story isolated in its own git worktree — using dedicated subagents with fresh context windows. Loops through the entire sprint plan in batches, with optional epic retrospective. Use when the user says "run BAD", "start autonomous development", "automate the sprint", "run the pipeline", "kick off the sprint", or "start the dev pipeline". Run /bad setup or /bad configure to install and configure the module.

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.

VariableConfig KeyDefaultDescription
MAX_PARALLEL_STORIESmax_parallel_stories3Max stories to run in a single batch
WORKTREE_BASE_PATHworktree_base_path.worktreesRoot directory for git worktrees
MODEL_STANDARDmodel_standardsonnetModel 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_QUALITYmodel_qualityopusModel for Step 5 (code review)
RETRO_TIMER_SECONDSretro_timer_seconds600Auto-retrospective countdown after epic completion (10 min)
WAIT_TIMER_SECONDSwait_timer_seconds3600Post-batch wait before re-checking PR status (1 hr)
CONTEXT_COMPACTION_THRESHOLDcontext_compaction_threshold80Context window % at which to compact/summarise context
STALE_TIMEOUT_MINUTESstale_timeout_minutes60Minutes of subagent inactivity before watchdog alerts (0 = disabled)
TIMER_SUPPORTtimer_supporttrueWhen true, use native platform timers; when false, use prompt-based continuation
MONITOR_SUPPORTmonitor_supporttrueWhen 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_THRESHOLDapi_five_hour_threshold80(Claude Code) 5-hour rate limit % that triggers a pause
API_SEVEN_DAY_THRESHOLDapi_seven_day_threshold95(Claude Code) 7-day rate limit % that triggers a pause
API_USAGE_THRESHOLDapi_usage_threshold80(Other harnesses) Generic API usage % that triggers a pause
RUN_CI_LOCALLYrun_ci_locallyfalseWhen true, skip GitHub Actions and always run the local CI fallback
AUTO_PR_MERGEauto_pr_mergefalseWhen 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 details.

Phase 2: Run the Pipeline

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):

StatusStart fromSkip
backlogStep 1nothing
ready-for-devStep 2Step 1
atdd-doneStep 3Steps 1–2
in-progressStep 3Steps 1–2
reviewStep 4Steps 1–3
done—all

After each step — mandatory gate (never skip, even with parallel stories): 📣 Notify the step result (formats below), then run Pre-Continuation Checks (references/coordinator/gate-pre-continuation.md). Only after all checks pass → spawn the next subagent.

📣 Notify per step as each step completes:

  • Success: ✅ Story {number}: Step {N} — {step name}
  • Failure: ❌ Story {number}: Step {N} — {step name} failed — {brief error}

Step names: Step 1 — Create, Step 2 — ATDD, Step 3 — Develop, Step 4 — Test review, Step 5 — Code review, Step 6 — PR + CI, Step 7 — PR review.

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.

Hung subagents: when MONITOR_SUPPORT=true and the activity log hook is installed (Step 4 of setup), use the Watchdog Pattern when spawning Steps 2, 3, 4, and 5 to detect stale agents.

Step 1: Create Story (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. Run "validate story {number}-{short_description}". For every finding,
   apply a fix directly to the story file using your best engineering judgement.
   Repeat until no findings remain.

5. 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.
Step 2: ATDD (MODEL_STANDARD)

Spawn with model MODEL_STANDARD (yolo mode):

You are the Step 2 ATDD 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. Run /bmad-testarch-atdd {number}-{short_description}.
2. Commit any generated test files.
3. Update sprint-status.yaml at the REPO ROOT:
     {repo_root}/_bmad-output/implementation-artifacts/sprint-status.yaml
   Set story {number} status to `atdd-done`.

Report: success or failure with error details.
Step 3: Develop Story (MODEL_STANDARD)

Spawn with model MODEL_STANDARD (yolo mode):

You are the Step 3 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.
Step 4: Test Review (MODEL_STANDARD)

Spawn with model MODEL_STANDARD (yolo mode):

You are the Step 4 test 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-testarch-test-review {number}-{short_description}.
2. Apply all findings using your best engineering judgement.
3. Commit any changes from the review.

Report: success or failure with error details.
Step 5: Code Review (MODEL_QUALITY)

Spawn with model MODEL_QUALITY (yolo mode):

You are the Step 5 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.
Step 6: PR & CI (MODEL_STANDARD)

Spawn with model MODEL_STANDARD (yolo mode):

You are the Step 6 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. Look up the GitHub issue number for this story:
   Read the story's section in `_bmad-output/planning-artifacts/epics.md` and extract
   the `**GH Issue:**` field. Save as `gh_issue_number`. If the field is absent
   (local-only mode — no GitHub auth), proceed without it.

4. Run /commit-commands:commit-push-pr.
   PR title: story-{number}-{short_description} - fixes #{gh_issue_number}
   Include "Fixes #{gh_issue_number}" in the PR description body (omit only if
   no issue number was found in step 3).

5. CI:
   - If RUN_CI_LOCALLY is true → skip GitHub Actions and run the Local CI Fallback below.
   - Otherwise, if MONITOR_SUPPORT is true → use the Monitor tool to watch CI status:
       Write a poller script:
         while true; do gh run view --json status,conclusion 2>&1; sleep 30; done
       Start it with Monitor. React to each output line as it arrives:
       - conclusion=success → stop Monitor, report success
       - conclusion=failure or cancelled → stop Monitor, diagnose, fix, push, restart Monitor
       - Billing/spending limit error in output → stop Monitor, run Local CI Fallback
       - gh TLS/auth error in output → stop Monitor, switch to curl poller from `references/coordinator/pattern-gh-curl-fallback.md`
   - Otherwise → poll manually in a loop:
       gh run view
     (If `gh` fails, use `gh run view` curl equivalent from `references/coordinator/pattern-gh-curl-fallback.md`)
     - 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 → report success

LOCAL CI FALLBACK (when RUN_CI_LOCALLY=true or billing-limited):
  Read `references/subagents/step6-ci-fallback.md` and follow its instructions exactly.

Report: success or failure, and the PR number/URL if opened.
Step 7: PR Code Review (MODEL_STANDARD)

Spawn with model MODEL_STANDARD (yolo mode):

You are the Step 7 PR 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 /code-review:code-review (reads the PR diff via gh pr diff).
2. For every finding, apply a fix using your best engineering judgement.
   Do not skip or defer any finding — fix them all.
3. Commit all fixes and push to the PR branch.
4. 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.
5. Update sprint-status.yaml at the REPO ROOT:
     {repo_root}/_bmad-output/implementation-artifacts/sprint-status.yaml
   Set story {number} status to `done`.

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

Phase 3: Auto-Merge Batch PRs (when 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:

  1. Collect all stories from the current batch that reached Step 6 successfully (have a PR). Sort ascending by story number.
  2. 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/subagents/phase3-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.
  3. 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
  1. Spawn a cleanup subagent (MODEL_STANDARD, yolo mode):
    Post-merge cleanup. Auto-approve all tool calls (yolo mode).
    Read `references/subagents/phase3-cleanup.md` and follow its instructions exactly.

Phase 4: Batch Completion & Continuation

Step 1: Print Batch Summary

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

Story   | Step 1 | Step 2 | Step 3 | Step 4 | Step 5 | Step 6 | Step 7 | Result
--------|--------|--------|--------|--------|--------|--------|--------|-------
9.1     |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   | PR #142
9.2     |   OK   |   OK   |   OK   |  FAIL  |   --   |   --   |   --   | Test review failed: ...
9.3     |   OK   |   OK   |   OK   |   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

Show full SKILL.md (1,078 more words)Show less
Step 2: Check for Epic Completion

From Phase 2 results, collect the batch stories and their PR numbers (e.g. 8.1 → #101, 8.2 → #102). Pass these as BATCH_STORIES_WITH_PRS in the assessment prompt below.

Spawn an assessment subagent (MODEL_STANDARD, yolo mode):

Epic completion assessment. Auto-approve all tool calls (yolo mode).
BATCH_STORIES_WITH_PRS: {coordinator substitutes: "story → #PR" pairs from this batch, one per line}

Read `references/subagents/phase4-assessment.md` and follow its instructions exactly.

Using the assessment report:

If current_epic_merged = true:

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

  2. 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_STANDARD 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
    • [X] label: Stop BAD
    • [C] / FIRED action: Spawn MODEL_STANDARD subagent (yolo mode) to run /bmad-retrospective. Accept all changes. Run Pre-Continuation Checks after.
    • [S] action: Skip retrospective.
    • [X] action: CronDelete(JOB_ID), stop BAD, print final summary, and 📣 Notify: 🛑 BAD stopped by user.
  3. Proceed to Step 3 after the retrospective decision resolves.

Step 3: Gate & Continue

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:

  1. Print a status line:

    • current_epic_merged = true (epic fully landed): ✅ Epic {current_epic_name} complete. Next up: Epic {next_epic_name} ({stories_remaining} stories remaining).
    • current_epic_prs_open = true (all stories have PRs, waiting for merges): ⏸ Epic {current_epic_name} in review — waiting for PRs to merge before continuing.
    • Otherwise (more stories to develop in current epic): ✅ Batch complete. Ready for the next batch.
  2. Start the wait using the Monitor Pattern (when MONITOR_SUPPORT=true and AUTO_PR_MERGE=false) or the Timer Pattern otherwise:

    AUTO_PR_MERGE=true guard: When AUTO_PR_MERGE=true, Phase 3 already merged all batch PRs before Phase 4 runs. BATCH_PRS will be empty, causing the Monitor to fire ALL_MERGED immediately with no actual pause. Skip the Monitor path entirely and go directly to the Timer only path below — the WAIT_TIMER_SECONDS cooldown must still fire before the next batch. The wait exists to give the developer a chance to review the merged changes and course-correct before the next batch begins — never skip or shorten it.

    If MONITOR_SUPPORT=true and AUTO_PR_MERGE=false — Monitor + CronCreate fallback:

    • Fill in BATCH_PRS from the Phase 0 pending-PR report (space-separated numbers, e.g. "101 102 103"). Use the PR-merge watcher script from monitor-pattern.md with that value substituted. Save the Monitor handle as PR_MONITOR.
    • Also start a CronCreate fallback timer using the Timer Pattern with:
      • Duration: WAIT_TIMER_SECONDS
      • Fire prompt: "BAD_WAIT_TIMER_FIRED — Max wait elapsed. Stop PR_MONITOR, run Pre-Continuation Checks, then re-run Phase 0."
      • [C] label: Continue now
      • [S] label: Stop BAD
      • [C] / FIRED action: Stop PR_MONITOR, run Pre-Continuation Checks, then re-run Phase 0.
      • [S] action: Stop PR_MONITOR, CronDelete, stop BAD, print final summary, and 📣 Notify: 🛑 BAD stopped by user.
    • On MERGED: #N event: log progress — ✅ PR #N merged — waiting for remaining batch PRs; keep PR_MONITOR running.
    • On ALL_MERGED event: CronDelete the fallback timer, stop PR_MONITOR, run Pre-Continuation Checks, re-run Phase 0.
    • 📣 Notify: ⏳ Watching for PR merges (max wait: {WAIT_TIMER_SECONDS ÷ 60} min)...

    If MONITOR_SUPPORT=false or AUTO_PR_MERGE=true — Timer only:

    • Use the Timer Pattern with:
      • Duration: WAIT_TIMER_SECONDS
      • Fire prompt: "BAD_WAIT_TIMER_FIRED — The post-batch wait has elapsed. Run Pre-Continuation Checks, then re-run Phase 0, then proceed to Phase 1."
      • [C] label: Continue now
      • [S] label: Stop BAD
      • [C] / FIRED action: Run Pre-Continuation Checks, then re-run Phase 0.
      • [S] action: Stop BAD, print a final summary, and 📣 Notify: 🛑 BAD stopped by user.
  3. After Phase 0 completes:

    • At least one story unblocked → proceed to Phase 1.
    • All stories still blocked → print which PRs are pending (from Phase 0 report), restart Branch B for another wait.

Notify Pattern

Read references/coordinator/pattern-notify.md whenever a 📣 Notify: callout appears. It covers Telegram and terminal output.


Timer Pattern

Read references/coordinator/pattern-timer.md when instructed to start a timer. It covers both TIMER_SUPPORT=true (CronCreate) and TIMER_SUPPORT=false (prompt-based) paths.


Monitor Pattern

Read references/coordinator/pattern-monitor.md when MONITOR_SUPPORT=true. It covers CI status polling (Step 6) and PR-merge watching (Phase 4 Branch B), plus the MONITOR_SUPPORT=false fallback for each.


Watchdog Pattern

Read references/coordinator/pattern-watchdog.md when MONITOR_SUPPORT=true and the activity log hook is installed (Step 4 of setup). Use it before spawning long-running Phase 2 subagents (Steps 2, 3, 4, 5) to detect hung agents via activity log monitoring.


gh → curl Fallback Pattern

Read references/coordinator/pattern-gh-curl-fallback.md when any gh command fails (TLS error, sandbox restriction, spending limit, etc.). Pass the path to subagents that run gh commands so they can self-recover. Note: gh pr merge has no curl fallback — if unavailable, surface the failure to the user.


Rules

  1. Delegate mode only — never read project files, run git/gh commands, or write to disk yourself. Coordinator-only direct operations are limited to: Pre-Continuation Checks (Bash session-state read, /reload-plugins, /compact), timer management (CronCreate/CronDelete), channel notifications (Telegram tool), and the Monitor tool for CI/PR polling. All story-level operations are delegated to subagents.
  2. One subagent per step per story — spawn only after the previous step reports success.
  3. Sequential steps within a story — Steps 1→2→3→4→5→6→7 run strictly in order.
  4. Parallel stories — launch all stories' Step 1 in one message (one tool call per story). Phase 3 runs sequentially by design.
  5. Dependency graph is authoritative — never pick a story whose dependencies are not fully merged. Use Phase 0's report, not your own file reads.
  6. Phase 0 runs before every batch — always after the Phase 4 wait. Always as a fresh subagent.
  7. Phase 4 wait is mandatory and full-duration — always use WAIT_TIMER_SECONDS unchanged. Never shorten or skip the wait because PRs are already merged or the wait seems unnecessary. The wait gives the developer time to review merged changes and course-correct before the next batch.
  8. Confirm success before spawning the next subagent.
  9. sprint-status.yaml is updated by step subagents — each step subagent writes to the repo root copy. The coordinator never does this directly.
  10. 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.
  11. 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. This rolling-start rule applies to all sequential steps within a story.
  12. Pre-Continuation Checks are mandatory at every gate — run references/coordinator/gate-pre-continuation.md between every step spawn, after each Phase 3 merge, and before every Phase 0 re-entry. Never skip or defer these checks, even when handling multiple parallel story completions simultaneously.

© stephenleo, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 21 other files (scripts, references, assets) in skills/bad of stephenleo/bmad-autonomous-development.

  • SKILL.md
  • assets/bad-statusline.sh
  • assets/module-help.csv
  • assets/module-setup.md
  • assets/module.yaml
  • references/coordinator/gate-pre-continuation.md
  • references/coordinator/pattern-gh-curl-fallback.md
  • references/coordinator/pattern-monitor.md
  • references/coordinator/pattern-notify.md
  • references/coordinator/pattern-timer.md
  • references/coordinator/pattern-watchdog.md
  • references/coordinator/setup-statusline-hook.md
  • references/subagents/phase0-graph.md
  • references/subagents/phase0-prompt.md
  • references/subagents/phase3-cleanup.md
  • references/subagents/phase3-merge.md
  • references/subagents/phase4-assessment.md
  • … and 5 more

Open the folder on GitHubat commit be7a26c

Compare with similar skills

Bad next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Bad compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Bad this skillstephenleo/bmad-autonomous-development107—~7.7kAutomated safety check: PassMIT
Vibe Kanbanaiskillstore/marketplace430—~4.4kAutomated safety check: NotesNone
Clawteamwin4r/ClawTeam-OpenClaw1.5k—~3.1kAutomated safety check: PassMIT
PRP Workstream OrchestratorWirasm/prp2.3k—~3.5kAutomated safety check: PassMIT
Gh Issuestrpc-group/trpc-agent-go1.8k8 repos~8.7kAutomated safety check: PassApache-2.0
Firewood Reviewava-labs/firewood153—~2.1kAutomated safety check: NotesCustom licence

Similar skills

  • Vibe Kanban

    aiskillstore/marketplace

    Manage AI coding agents on a visual Kanban board. An agent skill from aiskillstore/marketplace.

    430 GitHub stars~4.4k tokensUpdated today
    Agent WorkflowsAuto-check: notes
  • Clawteam

    win4r/ClawTeam-OpenClaw

    Multi-agent swarm orchestration. An agent skill from win4r/ClawTeam-OpenClaw.

    1.5k GitHub stars~3.1k tokensUpdated 3 mo ago
    Agent WorkflowsAuto-check passed
  • Coordinates several PRP workstreams in isolated Git worktrees from one session, verifying proof, holding merge gates and sequencing the merges.

    2.3k GitHub stars~3.5k tokensUpdated 5 days ago
    Agent WorkflowsAuto-check passed
  • Gh Issues

    trpc-group/trpc-agent-go

    Fetch GitHub issues, spawn sub-agents to implement fixes and open PRs, then monitor and address PR review comments.

    1.8k GitHub starsUsed in 8 repos~8.7k tokens
    Agent WorkflowsAuto-check passed
  • Firewood Review

    ava-labs/firewood

    A skill your agent uses when reviewing ava-labs/firewood code changes — pull request or local workspace.

    153 GitHub stars~2.1k tokensUpdated yesterday
    DevelopmentAuto-check: notes
  • Work With PR Lifecycle

    code-yeongyu/oh-my-openagent

    Takes a task through to a merged pull request in an isolated git worktree, splitting it into small independent PRs and looping on CI and review gates until they pass.

    70k GitHub stars~4.6k tokensUpdated today
    DevelopmentAuto-check passed

Works with

Questions about Bad

What does Bad do?

BMad Autonomous Development — orchestrates parallel story implementation pipelines. Bad is an agent skill from stephenleo/bmad-autonomous-development. BMad Autonomous Development — orchestrates parallel story implementation pipelines.

When should I use Bad?

Bad fits situations like: the user says run BAD; start autonomous development; automate the sprint; run the pipeline.

How do I install Bad in Claude Code?

Run `npx skills add stephenleo/bmad-autonomous-development --skill bad -a claude-code`. Or copy the skill folder (skills/bad in stephenleo/bmad-autonomous-development) into .claude/skills/bad in your project. Claude Code loads it when a task matches its description.

How do I install Bad in Codex?

Run `npx skills add stephenleo/bmad-autonomous-development --skill bad -a codex`. Or copy the skill folder (skills/bad in stephenleo/bmad-autonomous-development) into .agents/skills/bad in your project. Codex loads it when a task matches its description.

Can I use Bad in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add stephenleo/bmad-autonomous-development --skill bad -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/bad, .gemini/skills/bad, .github/skills/bad and .opencode/skills/bad in your project.

What does Bad need to run?

Going by SKILL.md and its folder, Bad needs a shell for the scripts in its folder and the command-line tools its instructions call (git and gh). Our summary lists: A Bash shell.

Does Bad access the network?

SKILL.md contains no URLs. Its commands use git and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Bad safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Bad use?

Bad is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Bad use?

About 7.7k tokens (SKILL.md is roughly 31k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 9.1k tokens, read only when the agent opens those files.

What are the alternatives to Bad?

Skills that share tags, products or a category with Bad: Vibe Kanban (aiskillstore/marketplace, 430 stars), Clawteam (win4r/ClawTeam-OpenClaw, 1.5k stars), PRP Workstream Orchestrator (Wirasm/prp, 2.3k stars) and Gh Issues (trpc-group/trpc-agent-go, 1.8k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Bad?

stephenleo (a GitHub user) maintains it in stephenleo/bmad-autonomous-development, which has 107 GitHub stars. The repository was last updated on April 19, 2026.

Source: stephenleo/bmad-autonomous-development on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.