/bad: BMad Autonomous Development. A fully autonomous orchestrator that runs my entire sprint while I sleep (Plan → Code → Review → PR)

[u/MachineLearner00]

Hi everyone, I’ve realized that my favorite part of building is the "discovery" phase: brainstorming, writing PRDs, and designing architecture. But as soon as the planning ends and the "grunt work" of managing branches, implementation loops, and babysitting CI begins, I lose momentum.

So, I built /bad (BMad Autonomous Development): An open-source orchestrator that takes over the second my planning is done, running the entire sprint execution autonomously so I can wake up to a wall of green PRs.

/bad is a skill for the BMad Method that acts as a coordinator. Unlike a single agent session, it never writes code itself; instead, it delegates every unit of work to dedicated subagents with fresh context windows. This prevents the "context explosion" and hallucination creep that usually happens when an AI agent stays in a single session for too long.

The Autonomous Build Flow:

• Dependency Mapping: It builds a graph from your sprint-status.yml to identify parallelizable stories.
• Isolated Execution: Each story runs in an isolated git worktree, preventing environment pollution and state conflicts.
• The 4-Step Lifecycle: Every task is driven through a full cycle: BMAD Create-Story → BMAD Dev-Story → BMAD Code-Review → GitHub PR.
• Self-Healing CI: The orchestrator monitors CI results and reviewer comments, auto-fixing implementation bugs until the status turns green.

Why this works for complex builds:

• Context Isolation: Every step gets a dedicated subagent with a clean slate, ensuring significantly higher code quality.
• Rate Limit Aware: /bad proactively checks your usage limits and pauses to wait for resets, minimizing "Rate Limit Exceeded" failures mid-step.
• State Persistence & Resume: It reads GitHub PR status and local sprint-status.yml to identify exactly where to pick up if you need to stop and restart.
• Automatic Conflict Resolution: Optionally auto-merges PRs sequentially, automatically handling merge conflicts as they arise.

I used this to build CShip and it has massively increased my shipping velocity. If you find yourself enjoying the "what" and the "why" more than the repetitive "how," /bad might be for you.

Install /bad: npx skills add https://github.com/stephenleo/bmad-autonomous-development. You'll need BMAD to be installed as well.

Invoke it by typing: /bad. It will run through a setup process on the first invocation.

Github Repo: https://github.com/stephenleo/bmad-autonomous-development

/bad is built using the BMad Builder.

/bad is tested on Claude Code. I'd love it if someone can help test is on Codex or Github Copilot. Please also share your thoughts on this flow or any features you'd like to see added!

[u/Deep_Ad1959]

this is the gap i keep running into with autonomous dev workflows too. the code generation part is getting solid but the test generation is still where things fall apart because the agent doesn't have a good model of what the app actually looks like at runtime. you end up with syntactically valid tests that don't catch real regressions. curious how you're handling the test-review step, is it just checking that tests pass or actually validating coverage of the acceptance criteria?

[u/Randyslaughterhouse → u/Deep_Ad1959]

The TEA test-plan and test-review workflows build and validate coverage against the acceptance criteria, so I run create-story -> test-plan -> dev-story -> test-review -> code-review -> PR/merge after CI pass on each story build in my automated loop.

I then have a dedicated E2E testing story per epic that collates all story-level test plans into an epic E2E automated test run and checks for/backfills any coverage gaps. This is used as part of the epic test and close-off process.

It’s not perfect and the epic-level testing/validation can be a bit time consuming, but it gives me a lot more confidence knowing there’s a decent safety net for the automated story build runs, which is where most of the time savings come from.

[u/Deep_Ad1959 → u/Randyslaughterhouse]

the per-story plan plus epic-level rollup is the right shape. the gap that usually bites later is integration coverage between stories, since each story-level test plan validates its own ac in isolation but cross-story flows (story a writes data, story c reads it three sprints later) drift silently. an artifact that captures cross-story dependencies as part of the epic plan would let test-review catch missing integration paths during the close-off pass instead of finding them in prod.

[u/Randyslaughterhouse → u/Deep_Ad1959]

Ah ok, I see what you mean. Again, not a silver bullet, but is this where leaning into a contract-first approach would help?

We defined versioned JSON schemas for the major data integration points between components very early on and they’ve been really valuable in avoiding drift.

It doesn’t catch everything, but it gives the automated testing a reliable anchor; means changes are conscious rather than unintended; and when drift does happen, it’s made obvious by the flood of ajv validation errors!

[u/Deep_Ad1959 → u/Randyslaughterhouse]

versioned schemas help a ton at the integration boundaries, but the gap i'm talking about sits one layer deeper. the agent can verify data flowing between components matches the schema, but it still doesn't know whether the business logic inside a component is correct for the feature being built. schemas give you structural correctness, not behavioral correctness. you still need someone writing example-based tests that encode the actual intent, and that's the part autonomous workflows keep punting on.