Vibe Kanban
aiskillstore/marketplace
Manage AI coding agents on a visual Kanban board. An agent skill from aiskillstore/marketplace.
BMad Autonomous Development — orchestrates parallel story implementation pipelines.
$ npx skills add stephenleo/bmad-autonomous-development --skill bad -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install stephenleo/bmad-autonomous-development bad --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ 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-srcUse ~/.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/
Install the "bad" agent skill from https://github.com/stephenleo/bmad-autonomous-development/tree/main/skills/bad into .claude/skills/bad/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "bad", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/stephenleo/bmad-autonomous-development/tree/main/skills/badType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add stephenleo/bmad-autonomous-development --skill bad -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install stephenleo/bmad-autonomous-development bad --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/stephenleo/bmad-autonomous-development.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/bad .agents/skills/bad && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "bad" agent skill from https://github.com/stephenleo/bmad-autonomous-development/tree/main/skills/bad into .agents/skills/bad/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "bad", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add stephenleo/bmad-autonomous-development --skill bad -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install stephenleo/bmad-autonomous-development bad --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/stephenleo/bmad-autonomous-development.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/bad .cursor/skills/bad && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "bad" agent skill from https://github.com/stephenleo/bmad-autonomous-development/tree/main/skills/bad into .cursor/skills/bad/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "bad", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/stephenleo/bmad-autonomous-development.git --path skills/bad--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add stephenleo/bmad-autonomous-development --skill bad -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install stephenleo/bmad-autonomous-development bad --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/stephenleo/bmad-autonomous-development.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/bad .gemini/skills/bad && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "bad" agent skill from https://github.com/stephenleo/bmad-autonomous-development/tree/main/skills/bad into .gemini/skills/bad/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "bad", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install stephenleo/bmad-autonomous-development badInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add stephenleo/bmad-autonomous-development --skill bad -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/stephenleo/bmad-autonomous-development.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/bad .github/skills/bad && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "bad" agent skill from https://github.com/stephenleo/bmad-autonomous-development/tree/main/skills/bad into .github/skills/bad/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "bad", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add stephenleo/bmad-autonomous-development --skill bad -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install stephenleo/bmad-autonomous-development bad --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/stephenleo/bmad-autonomous-development.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/bad .opencode/skills/bad && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "bad" agent skill from https://github.com/stephenleo/bmad-autonomous-development/tree/main/skills/bad into .opencode/skills/bad/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "bad", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
badBMad 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. 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.
5 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit be7a26c. It shows what the files ask for, not the result of running them.
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.
Ships 1 file in scripts/ (Shell, from the files we listed), which the agent can run.
Shell commands in SKILL.md call:
gitghFrom the folder's file list and the shell code blocks in SKILL.md.
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.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
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.
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.
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.
The full file from stephenleo/bmad-autonomous-development at commit be7a26c, republished under its MIT licence (© stephenleo). 2,479 words, ~7,721 tokens.
.claude/skills/bad/SKILL.md (or your agent's skills folder). This skill also uses 21 other files; get the full folder from GitHub.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:
Everything else — file reads, git operations, gh commands, disk writes — happens inside Agent tool subagents with fresh context windows.
Before doing anything else, determine how to send notifications:
Check for a connected channel — look at the current conversation context:
<channel source="telegram" chat_id="..." ...> tag, save NOTIFY_CHAT_ID and NOTIFY_SOURCE="telegram".NOTIFY_SOURCE="terminal".Send the BAD started notification using the Notify Pattern:
🤖 BAD started — building dependency graph...Then proceed to Phase 0.
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, ...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 1Before 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 + continuationCall 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:
Phase 0: Dependency graph → completedPhase 1: Story selection → completed (already done)Phase 2: Step N tasks, Phase 3: Auto-merge, and Phase 4: Batch summary + continuation[ ] 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 + continuationUpdate 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.
Pure coordinator logic — no file reads, no tool calls.
ready_stories report, select at most MAX_PARALLEL_STORIES stories.CURRENT_EPIC (a coordinator variable, initially unset).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.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.
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.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 |
atdd-done | Step 3 | Steps 1–2 |
in-progress | Step 3 | Steps 1–2 |
review | Step 4 | Steps 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:
✅ Story {number}: Step {N} — {step name}❌ 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.
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.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.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.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.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.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.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.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:
MODEL_STANDARD subagent (yolo mode) with the instructions from references/subagents/phase3-merge.md.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 neededMODEL_STANDARD, yolo mode):Post-merge cleanup. Auto-approve all tool calls (yolo mode).
Read `references/subagents/phase3-cleanup.md` and follow its instructions exactly.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 #143If 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
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:
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:
RETRO_TIMER_SECONDS"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."Run retrospective nowSkip retrospectiveStop BAD/bmad-retrospective. Accept all changes. Run Pre-Continuation Checks after.CronDelete(JOB_ID), stop BAD, print final summary, and 📣 Notify: 🛑 BAD stopped by user.Proceed to Step 3 after the retrospective decision resolves.
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:
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.✅ Batch complete. Ready for the next batch.Start the wait using the Monitor Pattern (when MONITOR_SUPPORT=true and AUTO_PR_MERGE=false) or the Timer Pattern otherwise:
AUTO_PR_MERGE=trueguard: WhenAUTO_PR_MERGE=true, Phase 3 already merged all batch PRs before Phase 4 runs.BATCH_PRSwill be empty, causing the Monitor to fireALL_MERGEDimmediately with no actual pause. Skip the Monitor path entirely and go directly to the Timer only path below — theWAIT_TIMER_SECONDScooldown 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:
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.WAIT_TIMER_SECONDS"BAD_WAIT_TIMER_FIRED — Max wait elapsed. Stop PR_MONITOR, run Pre-Continuation Checks, then re-run Phase 0."Continue nowStop BADPR_MONITOR, run Pre-Continuation Checks, then re-run Phase 0.PR_MONITOR, CronDelete, stop BAD, print final summary, and 📣 Notify: 🛑 BAD stopped by user.MERGED: #N event: log progress — ✅ PR #N merged — waiting for remaining batch PRs; keep PR_MONITOR running.ALL_MERGED event: CronDelete the fallback timer, stop PR_MONITOR, run Pre-Continuation Checks, re-run Phase 0.⏳ Watching for PR merges (max wait: {WAIT_TIMER_SECONDS ÷ 60} min)...If MONITOR_SUPPORT=false or AUTO_PR_MERGE=true — Timer only:
WAIT_TIMER_SECONDS"BAD_WAIT_TIMER_FIRED — The post-batch wait has elapsed. Run Pre-Continuation Checks, then re-run Phase 0, then proceed to Phase 1."Continue nowStop BAD🛑 BAD stopped by user.After Phase 0 completes:
Read references/coordinator/pattern-notify.md whenever a 📣 Notify: callout appears. It covers Telegram and terminal output.
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.
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.
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.
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.
/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.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.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
SKILL.md and 21 other files (scripts, references, assets) in skills/bad of stephenleo/bmad-autonomous-development.
Open the folder on GitHubat commit be7a26c
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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Bad this skillstephenleo/bmad-autonomous-development | 107 | — | ~7.7k | Automated safety check: Pass | MIT | |
| Vibe Kanbanaiskillstore/marketplace | 430 | — | ~4.4k | Automated safety check: Notes | None | |
| Clawteamwin4r/ClawTeam-OpenClaw | 1.5k | — | ~3.1k | Automated safety check: Pass | MIT | |
| PRP Workstream OrchestratorWirasm/prp | 2.3k | — | ~3.5k | Automated safety check: Pass | MIT | |
| Gh Issuestrpc-group/trpc-agent-go | 1.8k | 8 repos | ~8.7k | Automated safety check: Pass | Apache-2.0 | |
| Firewood Reviewava-labs/firewood | 153 | — | ~2.1k | Automated safety check: Notes | Custom licence |
aiskillstore/marketplace
Manage AI coding agents on a visual Kanban board. An agent skill from aiskillstore/marketplace.
win4r/ClawTeam-OpenClaw
Multi-agent swarm orchestration. An agent skill from win4r/ClawTeam-OpenClaw.
Wirasm/prp
Coordinates several PRP workstreams in isolated Git worktrees from one session, verifying proof, holding merge gates and sequencing the merges.
trpc-group/trpc-agent-go
Fetch GitHub issues, spawn sub-agents to implement fixes and open PRs, then monitor and address PR review comments.
ava-labs/firewood
A skill your agent uses when reviewing ava-labs/firewood code changes — pull request or local workspace.
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.
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.
Bad fits situations like: the user says run BAD; start autonomous development; automate the sprint; run the pipeline.
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.
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.
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.
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.
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.
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.
Bad is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
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.
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.
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.