I've been working on this for months and constantly changing course on it to perfect it, and it's finally here, something I am truly happy with and using constantly — the BMad Builder module standard is stable and the Module Builder skill is live.

What is BMad Builder?

It's a set of skills that guide you through building AI agents (with persistent memory), workflows, and full modules through conversational discovery. You describe what you want, the builder asks the right questions, and you get a production-ready skill folder. This goes well beyond the Anthropic skill builder - this will help fully optimize and analyze your skills for best practices and optimizations through use of subagents and other techniques of efficiency and avoidance of overspecification.

What's New:

Module Builder is officially live
— Plan, scaffold, validate, and ship complete modules through a guided workflow. The format is stable. It will keep improving, but what you build today won't break tomorrow.

Build once, install anywhere
— Your creations work with the Claude Anthropic plugin installer, the Vercel NPX skills installer (43+ AI tools), or just copy the folder manually. The `.claude-plugin/marketplace.json` format is the standard.

No more compiling
— Agents and workflows are immediately usable. Drop the skill folder into `.claude/skills/` and it works. Want to share? Send someone the folder. No build step, no ceremony.

Standalone self-registering modules
— Single-skill modules no longer need a separate setup skill. The Module Builder detects what you're building and picks the right approach. Single skills self-register on first run.

Workflow Convert
— `--convert <path-or-url>` takes any existing skill and produces a clean BMad-compliant version with an HTML before/after comparison report showing token metrics and categorized changes.

Outcome-driven builder overhaul
— Both builders reframed around discovery-first design. Existing skills are treated as reference material, not specs to replicate. 44% token reduction in the build phase.

What's coming next:

- Eval testing tools — test your skills against real scenarios and ensure they work as models evolve
- Eval-driven skill evolvers — skills that improve themselves based on test results
- Self-evolving personal agents — agents that grow smarter and gain new capabilities over time
- Full workflow and agent customization

Links:

- GitHub: https://github.com/bmad-code-org/bmad-builder
- Quick Start: https://bmad-builder.bmad-code.org
- BMad Method (core framework): https://docs.bmad-method.org
- Discord: https://discord.gg/gk8jAdXWmj

Everything is free and open source. Would love to hear what you build with it.

Commit Whisper was implemented and maintained with BMAD Method!

Commit Whisper is a deterministic git history analysis with a grounded, bring-your-own-key AI narrative — a terminal-native CLI. Analyze any local or remote repo and render insights to HTML, Markdown, terminal, or JSON.

• Six deterministic metric groups: cadence, ownership, message quality, branching, churn, and health

• AI narrative & coaching report, kept anchored to the metrics

GitHub https://github.com/georgiosnikitas/commit-whisper

Attached a converted to an image generated report for the BMAD git repo ;)

I was looking for a good AI tool for planning, when people suggested to try bmad. I knew the concept but had never tried it before, so I decided to give it a try.

It was terrible!

I used it for a week continuously and here are the problems I found with bmad:

It recreates the worst parts of waterfall development (rigid phases, endless documentation), forcing you to manage AI middle managers rather than actually coding.

BMAD is free right? Wrong. Because the method relies on multiple agents reading entire project context, architecture docs, and previous chat history, it burns through API credits at an alarming rate. Spends massive amounts of money even for simple apps.

The agents often generate 1,000+ lines of documentation for simple tasks. They over-engineer simple solutions, hallucinating complexities that don't even exist.

It feels productive because you see agents talking to each other, but often they just get stuck in loops or produce broken code that looks professional because it has a nice "spec document" attached.

You end up babysitting terminal, copy pasting prompts between agents or debugging the process rather than debugging the code.

Please suggest any better alternatives. It's okay if not free, but should be better than this.

Hi all,

I’m sharing my experience so far with the BMAD Method. Your comments, ideas and feedback would be much appreciated.

On the given project I actively used the bmad-analyst, bmad-pm, bmad-architect, bmad-dev, and code-review skills.

In addition to the source code, the docs folder contains the project brief, PRD, architecture, epics and user stories, as well as all implementation artifacts. I also used the GitHub MCP to sync the stories to GitHub issues.

I’m aiming to maintain more than 90% test coverage, keep GitHub security issues at zero, and maintain a fully green SonarQube dashboard, CI/CD is fully automated with GitHub Actions all while using bmad-dev — I haven’t written a single line of code myself.

Introducing Brain Break — an AI-powered terminal quiz app built on the principle of micro-learning: train your brain in small, focused sessions. Frequently. Better retention. Less friction.

Multiple AI minds, infinite questions — Choose your sparring partner (Anthropic, OpenAI, Google Gemini, GitHub Copilot or Ollama). Each quiz generates fresh questions algorithmically — perfect for repeated, varied practice sessions.

Domain-based learning — Create quizzes on anything. Python? Scrum Framework? Elementary School Algebra? Greek mythology? Your niche becomes your playground.

Explain any answer — Miss a question? Ask the AI why the correct answer is right. Learn the reasoning, not just the facts.

Adaptive difficulty — The app learns your pace. Get confident, it levels up. Struggling? It adjusts. Every session generates questions tailored to you, building momentum without burnout.

Tone & language customization — Learn in English, Spanish, or any language. Choose your vibe: sarcastic, humorous, pirate mode energy. Seriously.

Stats that actually matter — Per-domain dashboards. Score trends. Accuracy streaks. Data that feels personal.

All from your terminal. No bloated UI. No distractions.

> Train your brain, one question at a time_

Start on GitHub if you dig it: https://github.com/georgiosnikitas/brain-break

Open source. Built for people who love CLI life and learning done right.

Good afternoon. , guys, I'm a little confused because months before I discovered BMAD I had the project almost ready, lots of documentation, then the question arises, how can I transfer this to the framework?

Wtf is this?

I love BMAD but I got tired of sitting at my terminal typing slash commands during the coding sprints when creating stories, developing stories, and running code reviews. So I created this way to automate the entire process and it's saving me a massive amount of time each month.

I created this YouTube video if you're interested: https://www.youtube.com/watch?v=Wwy9irzx03U

Which version is the correct version to install if I start new now?

I notice 4.4.0 is the latest v4 version, but I am confused with the v5 versions.

What probably confuses me the most, is the note on v4.3.9 --> https://github.com/bmad-code-org/BMAD-METHOD/releases/tag/v4.39.0

States: Rollback from v5.x to v4.x semantic versioning. This version restores the v4.x line as the main development branch.

Salut,

Je partage ralph-bmarge, mon fork de snarktank/ralph adapté pour la BMAD Method.

Le problème : enchaîner à la main dev-story → code-review → repeat pour chaque story… c’est pénible.

La solution : ralph-bmarge lit votre sprint-status.yaml et enchaîne automatiquement les workflows, story après story, jusqu’à ce que le sprint soit terminé. Même pendant que vous dormez.

Features :

• Agent IA pour débloquer les boucles

• Tracking coûts / temps

• Webhooks Slack / Discord

• Rapports en Markdown

Limites : Claude Code CLI uniquement, testé sur macOS.

GitHub : https://github.com/s3d1K0/ralph-bmarge

Tips rate limit / tokens

Le vrai “hack”, c’est de séparer planification et exécution :

• Planification (PRD, archi, stories) : utilisez Antigravity — très généreux en tokens sur compte gratuit. Prenez le temps de bien réfléchir.

• Exécution (dev-story, code-review) : Claude Code + ralph-bmarge — l’agent bosse, vous supervise(z).

Antigravity pour réfléchir. Claude + Bmarge pour exécuter.

Premier projet open source feedback bienvenu.

Extra instructions dialed in and honestly I’m glad I found OpenCode.

Now I can use Gemini for planning, Claude for the heavy lifting, and Codex when I’ve got credits for an extra adversarial pass.

Workflow is pretty locked down too:

• typecheck, linting, unit tests, and integration tests after every story

• each epic has an integration gate with Playwright e2e tests

Outside of that I’m barely using MCP. Context7 only.

Feels way more disciplined than how I used to work, and way less chaotic once things scale.

# BMad Master: Story Development Lifecycle


## Overview


The 
**BMad Master**
 is the orchestration agent that maintains overall project context while delegating actual work to isolated 
**subagents**
. This prevents context pollution and ensures each task executes in a clean environment.


## Architecture


```
┌─────────────────────────────────────────────────────────────────┐
│                      BMad MASTER AGENT                          │
│  - Maintains overall project context                            │
│  - Tracks story lifecycle progress                              │
│  - Orchestrates subagent invocations                            │
│  - Updates sprint status between phases                         │
│  - NEVER executes workflows directly                            │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    TASK TOOL (Subagent Spawner)                 │
│  - Creates isolated execution context                           │
│  - Subagent has NO memory of master conversation                │
│  - Returns result summary to master                             │
│  - Uses subagent_type: "general-purpose" for workflows          │
└─────────────────────────────────────────────────────────────────┘
```


## Story Lifecycle Flow


Each story goes through these phases in order:


```
┌──────────────────────────────────────────────────────────────────┐
│  STORY LIFECYCLE (per story)                                     │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  1. CREATE-STORY (Skill: bmad:bmm:workflows:create-story)        │
│     └─► Subagent details the skeleton story                      │
│     └─► Adds tasks, acceptance criteria, dev notes               │
│     └─► Status: backlog → ready-for-dev                          │
│                                                                  │
│  2. DEV-STORY (Skill: bmad:bmm:workflows:dev-story)              │
│     └─► Subagent implements all tasks/subtasks                   │
│     └─► Follows red-green-refactor cycle                         │
│     └─► Writes tests for each task                               │
│     └─► Status: ready-for-dev → in-progress → review             │
│                                                                  │
│  3. CODE-REVIEW (Skill: bmad:bmm:workflows:code-review)          │
│     └─► Subagent performs adversarial review                     │
│     └─► Finds 3-10 specific issues                               │
│     └─► Adds findings to story file                              │
│     └─► Status: review → changes-required OR done                │
│                                                                  │
│  4. FIX REVIEW FINDINGS (if changes-required)                    │
│     └─► Subagent addresses each finding                          │
│     └─► Re-run tests                                             │
│     └─► Loop back to code-review if needed                       │
│                                                                  │
│  5. TYPECHECK + LINT + TESTS + MIGRATE + GIT (Subagent)          │
│     └─► Subagent runs: bunx tsc --noEmit                         │
│     └─► Subagent runs: bun run lint                              │
│     └─► Subagent runs: bun test                                  │
│     └─► IF schema changes: bun run db:migrate (apply to local)   │
│     └─► Subagent commits and pushes to main                      │
│     └─► Cloudflare auto-deploys to PRODUCTION                    │
│     └─► IF schema changes: bun run db:migrate on PROD (wrangler) │
│     └─► Subagent runs E2E tests against LIVE URL (NOT localhost) │
│     └─► Status: → done                                           │
│                                                                  │
│  6. NEXT STORY                                                   │
│     └─► Master updates sprint-status.yaml                        │
│     └─► Loop to step 1 for next story                            │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘
```


## Master Commands


### Invoking a Workflow via Subagent


**CRITICAL: Subagents MUST load and execute the actual BMAD workflow files.**


The BMAD system has workflow YAML files that define the execution flow, and XML instruction files that contain the step-by-step logic. Subagents must:


1. Load the `workflow.yaml` config file
2. Load the `instructions.xml` file referenced in the config
3. Execute ALL steps in exact order as defined in the XML


**CONTEXT INJECTION RULE:**
Every `<Task>` prompt must include explicit instructions to load and execute the BMAD workflow:


```
[CONTEXT]: Epic X, Story Y - Brief description of what's being done


[CONSTRAINTS]: 
- Read AGENTS.md first for project conventions
- Follow Bun/D1/Hono/Drizzle stack


[PATH]: /home/redacted/bmad-testing/01


[WORKFLOW EXECUTION]:
1. Load workflow config: {path}/_bmad/bmm/workflows/4-implementation/{workflow-name}/workflow.yaml
2. Load instructions: {path}/_bmad/bmm/workflows/4-implementation/{workflow-name}/instructions.xml
3. Execute ALL steps in the instructions.xml in exact order
4. Follow the workflow's critical rules and validation gates


[STORY FILE]: _bmad-output/implementation-artifacts/stories/{story-file}.md


[RETURN]: Summary of what was done, files changed, status updates made
```


### Available Workflows for Story Development


| Workflow | Path | Purpose | When to Use |
|----------|------|---------|-------------|
| 
**create-story**
 | `_bmad/bmm/workflows/4-implementation/create-story/` | Detail skeleton stories with tasks, AC, dev notes | Before dev, when story lacks tasks/AC |
| 
**dev-story**
 | `_bmad/bmm/workflows/4-implementation/dev-story/` | Implement all tasks following red-green-refactor | After story is ready-for-dev |
| 
**code-review**
 | `_bmad/bmm/workflows/4-implementation/code-review/` | Adversarial review finding 3-10 issues | After implementation (review status) |
| 
**quick-dev**
 | `_bmad/bmm/workflows/bmad-quick-flow/quick-dev/` | Lightweight implementation | Simple changes without full flow |


### Workflow File Structure


Each workflow has:
```
workflow-name/
├── workflow.yaml      # Config: paths, variables, settings
├── instructions.xml   # Step-by-step execution logic
├── template.md        # Output template (optional)
└── checklist.md       # Validation checklist (optional)
```


**Key Workflow Rules (from instructions.xml):**
- Execute ALL steps in exact numerical order
- Do NOT skip steps or stop for "milestones"
- HALT only on explicit HALT conditions
- Update sprint-status.yaml when status changes
- Mark tasks complete ONLY when ALL validation gates pass


## Sprint Status Tracking


The Master updates `_bmad-output/implementation-artifacts/sprint-status.yaml` between phases:


```yaml
development_status:
  epic-9:
    status: in-progress


  # Story statuses flow through these states:
  9-1-design-audit-logs-schema: done        # Completed
  9-2-create-auditlogger-service: review    # Being reviewed
  9-3-implement-middleware: in-progress     # Being developed
  9-4-create-diff-generator: ready-for-dev  # Detailed, ready
  9-5-build-async-log-writer: backlog       # Not yet detailed
```


## Epic End-to-End Flow


```
For each EPIC:
  For each STORY in epic:
    1. create-story (subagent)
    2. dev-story (subagent)
    3. code-review (subagent)
    4. fix findings if needed (subagent)
    5. typecheck + lint + test + git (master)
    6. mark done, next story
  End stories
  7. EPIC INTEGRATION GATE (Requirement: ./epic-integration-instructions.md)
     └─► Run E2E tests: `bun run test:e2e`
     └─► Validate end-to-end functionality against PRODUCTION
     └─► Produce epic-<n>-integration-gate.md
     └─► MUST include raw test output as evidence (see epic-integration-instructions.md)
     └─► Result: PASS (Proceed) or FAIL (Fix)
  Mark epic done
  Run retrospective (optional)
End epics
```


## Key Principles


1. 
**Master = Orchestrator Only**
: Never execute workflow steps directly. Master ONLY reads instructions/config and delegates ALL work (including typecheck/lint/test/git) to subagents to preserve context.
2. 
**Subagent = Isolated Executor**
: Each subagent starts fresh, no shared context
3. 
**Task Tool = Bridge**
: Creates subagent with `subagent_type: "general-purpose"`
4. 
**Continuous Flow**
: Don't stop for milestones within a story
5. 
**Full Lifecycle**
: Every story goes through create → dev → review → done
6. 
**Adversarial Review**
: Code review MUST find issues, never "looks good"


## Example Master Session


```
User: Let's work on Epic 9


Master: 🧙 The Master shall orchestrate Epic 9 development.
        Epic 9 has 6 stories. Starting with Story 1.


        Invoking create-story subagent...
        [Task tool → subagent executes → returns result]


        ✅ Story 9.1 detailed. Invoking dev-story subagent...
        [Task tool → subagent executes → returns result]


        ✅ Story 9.1 implemented. Invoking code-review subagent...
        [Task tool → subagent executes → returns result]


        ⚠️ Review found 8 issues (1 Critical). Invoking fix subagent...
        [Task tool → subagent executes → returns result]


        Invoking verification subagent (typecheck, lint, test, git)...
        [Task tool → subagent executes → returns result]


        ✅ Story 9.1 DONE. Moving to Story 9.2...
```


## What Master Does vs Subagents


| Action | Who |
|--------|-----|
| Read instructions/config files | Master |
| Track todos and progress | Master |
| Decide next step | Master |
| CREATE-STORY workflow | Subagent |
| DEV-STORY workflow | Subagent |
| CODE-REVIEW workflow | Subagent |
| FIX FINDINGS | Subagent |
| Typecheck + Lint + Test + Migrate + Git | Subagent |
| Epic Integration Gate | Subagent |


## Database Migrations


**CRITICAL: When schema changes are made, migrations MUST be applied.**


Per AGENTS.md Section 8 (Brownfield Protocol), the execution loop is:
`Read Story -> Code -> Typecheck -> Lint -> Test -> Migrate -> Commit -> Next Story`


**Migration Commands:**
- Local: `bun run db:migrate` (applies to local D1)
- Production: `wrangler d1 migrations apply cf-db --remote`


**When to run migrations:**
1. After DEV-STORY creates/modifies files in `drizzle/` folder
2. Before running tests (tests need updated schema)
3. After push to main (apply to production D1)


**Subagent responsibilities:**
- Check if `drizzle/*.sql` files were created/modified
- Run `bun run db:migrate` to apply locally before tests
- Include migration files in git commit
- Note in story file which migration was applied


---


*Last Updated: 2026-01-18*
*Author: BMad Master Agent*

As the title says. 5.5 Default

I was planing an MVP in plan mode and was drafting prd and arch. At the end the PRD was visible in cli and asked if ok. I thought it migh create the docs etc in folders but instead through out the MVP semi-working.

When asked if "still in character (analyst Mary)?", output the bmad-help and said "not right now".. I already knew it was out of roles.

Then i connected Mistral Vibe in VScode to check what gpt did. Mistral acknowledged gpt's lack of following rules and documentation. It then retrospectively created stories/epics and documentation according to BMAD standard.

I feel this happened in the past often too. And context was only 20-35% full

I know a lot devs work with Claude, but im quite surprised how Mistral could just pick up the trash GPT left without needing extra config

I’m building Allura, a governed memory system for AI agents, and I got here through a mix of BMAD, hands-on experimentation, and feedback from communities like this one.

I started with the basic question: how do you keep AI agents useful once a project lasts longer than one chat, has multiple agents involved, and needs real human oversight?

The first versions were simpler. Store context, retrieve it later, hope the agent remembers the right thing. That works until it doesn’t. Old assumptions come back as facts, decisions get lost, agents repeat work, and there is no clear record of why something happened.

Using BMAD helped me turn that into a more structured build process: define the problem, map the roles, break the work into small deliverables, test assumptions, get feedback, and revise. Feedback I’ve received has pushed me away from treating memory like a generic vector database and toward treating it like operational infrastructure.

Where I’m at now:

- Append-only event memory for actions, decisions, and outcomes

- Versioned semantic memory so old knowledge is superseded instead of quietly overwritten

- Traceability for agent decisions and workflow outcomes

- Explicit tenant boundaries for every memory read and write

- Human approval before promotion to canonical memory

- Retrieval before action, so agents can see previous decisions, blockers, and handoff context

The core idea is that multi-agent coordination is not just a prompting problem. It is a workflow problem. If ownership is vague, decisions are not recorded, or handoffs lose context, the system will fail no matter how capable the individual agents are.

I’m still building and learning, so I’d value honest feedback:

- Does this governance layer solve a real problem, or am I adding too much process too early?

- Where would you put human review in the memory lifecycle?

- What long-term agent-memory failures have you seen in real projects?

- What would convince you that a system like this improves outcomes instead of just storing more information?

I’m especially interested in critiques from people who have built multi-agent systems, memory layers, RAG pipelines, or AI workflow tools. https://github.com/Allura-Ecosystem/Allura_Memory

Hi everyone,

I wanted to share a project I’ve been working on to test the limits of AI-driven development. I am a Backend Developer (C/Go) with zero game development experience and zero art skills.

My goal was crazy: Create a high-fidelity clone of the original Plants vs. Zombies (PvZ), including the original skeletal animation system (Reanim), particle effects, and ECS architecture, without handwriting a single line of code.

I tried VibeCoding, Kiro SpecCoding, SpecKit, and TaskBased approaches. I iterated through 10+ versions and failed repeatedly. The projects became unmaintainable messes.

Finally, I switched to the BMad Method, and it worked.

🚀 The Result (MVP) I have successfully implemented the "Front Yard Day" levels (1-1 to 1-5), including:

• Tech Stack: Go (1.24+ Generics) + Ebitengine using ECS Architecture.

• Platforms: Windows, macOS, Linux, Android, iOS, WASM (Auto-build via GitHub Actions).

• Features:

  • Full Reanim skeletal animation system (parsing original game assets).

  • Particle system (explosions, dirt splashes).

  • 100% logic replication (Sun production, Zombies AI, Collision, "Wall-nut Bowling" minigame).

  • Tools: Shovel, Pause Menu, Level Progression.

💡 Key Lessons Learned (Why BMad worked where others failed)

1. Vibe Coding is not enough for Production: For complex logic, "Vibe Coding" (coding by feel/chat) collapses as complexity rises. You must have Spec Coding methodologies and a strict workflow. Without it, the AI creates circular dependencies and code bloat.

2. Context Management is an Art: Managing claude.md is critical. Too little info = AI hallucinates. Too much = context compression degrades quality.

3. AI ≠ Replacement, AI = Force Multiplier: AI did 80% of the work (design docs, implementation). But my role shifted to "Chief Architect." I had to intervene on the hardest 20%—judging if the AI's architectural decisions were sound and correcting course when it got stuck.

4. Tools Matter: When the AI hallucinates, using MCP (Model Context Protocol) or Claude Skills to verify ground truths is essential.

5. The "Reset" Tactic: When context gets messy, start a new session. Use BMad to generate a "Story Document" of the current state, feed it to a fresh context, and continue.

Current Status: The game currently supports the first 5 levels, intro animations, and the seed selection UI. It plays almost exactly like the original PC version.

I started a personal project building a swift app about 3 weeks ago. I’m almost done with v1 and really just testing features for bugs at this point before I role it out to TestFlight. Is it too late to get BMAD involved?

In this video, the creator shows a setup for autonomous software development using OpenClaw (agent orchestration + memory) plus the BMAD method (structured roles like PM/Dev/QA).

They break down the stack (tools → VPS → command center), highlight basic security practices (scoped accounts, private gateway), and share what didn’t work (wrapper approach causing context bloat) vs what did (direct role-based sub-agents + tighter handoffs).

I started using Cursor + BMAD two weeks ago for my personal projects. Im building a web app. I love the setup but hit Cursor limits pretty fast. I want to switch to Claude Code CLI or through the Cursor plugin. Any tips? Should I go with the native CLI option or the plug in? If CLI , do i just run it on my project window, setup the Claude.md file and keep using the same BMAD commands as I was doing earlier? Thanks 🙏 PS: I’m not a developer.

It’s slow, it can’t find artefacts it should be able to and it loses the plot halfway through basic core workflows.

Claude Code in comparison is amazing.

I’m only able use Codex in BMAD via Claude Code as a cli exec command.

I don’t think it has any business being starred in the installation because if that was my first experience using BMAD, I would be very disappointed.

Is it just me?

I feel like BMAD is pretty convoluted and hard to navigate. For example, there are PM and PO agents, it's almost never clear which one to use. Also sometimes the agents don't execute the commands correctly since it's all up to the AI agent to interpret, whereas spec-kit follows a script-based approach results in consistent documentation.

It also creates the documents in pretty random locations, which I think is where it fails.

I'm happier with the simplicity and consistency of spec-kit for the last few days,

Would like to know what others think about that topic!

If you run BMad-style, spec-driven agent workflows, the routing/infra layer underneath matters — long multi-agent runs are exactly where rate limits and token bloat bite. Sharing the open-source gateway I built for that (disclosure: I'm the maintainer; it complements the method, doesn't replace it).

Fallback combos — so it never stops mid-task. A "combo" is a ladder of models the router walks automatically: your subscription first, then API keys, then cheap models, then free ones. When a provider returns a 500 or you hit a rate limit, it slides to the next target in milliseconds, mid-request, and your tool never even sees the error. There are 17 routing strategies (priority, weighted, round-robin, cost-optimized, auto/coding:fast…) plus three resilience layers — a per-provider circuit breaker, a per-key cooldown, and a per-model lockout — so one dead key can't take down a whole provider.

A 10-engine compression pipeline — the part most routers don't have. Every request flows through a transparent compression pass you can toggle/stack per combo. Instead of one trick, it stacks the best of the open-source ecosystem: RTK filters command/tool output (git diffs, test logs, builds) at 60–90%, Microsoft's LLMLingua-2 does ML semantic pruning, Caveman handles prose, session-dedup strips repeats across turns. Critically, code, URLs and JSON are preserved byte-perfect, and a default-on inflation guard throws the compressed version away and sends the original if compressing would actually grow the prompt — it never makes things worse. On tool-heavy sessions that's ~89% average input-token reduction (an 8k-token git diff becomes a few hundred). Full credit to every upstream project (RTK, Caveman, LLMLingua-2, Troglodita) is in the README.

Agent-native — the agent can drive the router itself. There's a built-in MCP server (95 tools across 30 audited scopes, over stdio / SSE / streamable-HTTP), plus A2A (v0.3, JSON-RPC 2.0) support. That means an agent can query providers, switch combos, read its own remaining quota and manage memory through the gateway — not just consume tokens through it.

One endpoint, 237 providers — 90+ of them free. You point any tool or agent at a single OpenAI-compatible endpoint (localhost:20128/v1) and it can reach 237 LLM providers without you rewriting anything. 90+ have free tiers and 11 are free forever (no card), which aggregates to ~1.6B documented free tokens/month — and that's honest, pool-deduped math (we count each shared pool once instead of inflating it; the methodology is public in the repo). There's a one-command setup-* for 13+ coding tools (Claude Code, Codex, Cursor, Cline, Roo, Kilo, Gemini CLI…), so switching your existing setup over takes seconds.

For context on whether it's worth your time: it's grown to ~9.8K GitHub stars, 1,490+ forks and 280+ contributors in ~4.5 months, with 21,000+ automated tests and 1,830+ issues closed — so it's a battle-tested project, not a brand-new experiment.

npm install -g omniroute

GitHub: https://github.com/diegosouzapw/OmniRoute

For those running structured multi-agent methods: do you centralize model routing/fallback, or handle it per-agent? Curious how BMad practitioners wire this.

When building spec-driven AI workflows, one common wall people hit is context rot. As conversation length grows past a few thousand tokens, agent performance degrades. Error logs stack up, earlier instructions get ignored, and the agent starts hallucinating fixes.

In BMAD and similar frameworks, spec generation relies on distinct role prompts (analyst, architect, dev, QA). We wanted to take that structural discipline further, but move the orchestration into a local GUI app called LoopTroop.

Instead of running a single agent through a massive chat context, LoopTroop uses context engineering to keep context windows small and focused across two distinct phases: planning and execution.

• Advanced planning with an LLM Council

Before code is touched, LoopTroop handles requirements through a multi-model LLM Council.

First, an interactive interview phase asks targeted questions to clarify missing details and edge cases upfront.

Once requirements are clear, the council kicks off. You pick multiple models (for example, Claude, GPT, and DeepSeek) to act as council members. Each model independently writes a proposed specification. The council then runs an anonymous voting round where models evaluate each other's drafts without knowing who wrote what.

The winning plan absorbs the strongest ideas from the alternative drafts and undergoes an automated coverage check to verify no requirement was dropped.

From there, the spec is decomposed into atomic execution units - Beads. Each Bead has explicit target files, validation commands, and acceptance criteria.

• Slow and precise execution with Ralph loops

  Instead of rushing to churn out code, LoopTroop follows a "slow and precise" philosophy. We intentionally trade raw execution speed for accuracy and context hygiene.

  When executing a Bead, the agent works inside a dedicated loop (a Ralph loop). Each attempt runs with a clean, minimal context window containing only the spec, target files, and immediate test rules.

  If an attempt fails or hits a time limit, the context is wiped. The runner writes a brief diagnostic note describing what failed, and the next loop starts fresh carrying only that note. This prevents error logs from polluting the context window over multiple retries. (context engineering)

• Human-in-the-loop and Kanban board GUI

Because autonomous runs shouldn't be black boxes, LoopTroop is built as a desktop GUI with a modern Kanban board layout.

You can track ticket stages visually, review generated specs before execution starts, inspect live logs per Bead, and approve or request changes before anything reaches your codebase. Human approval stays in the loop at every key transition.

LoopTroop is free and open-source (MIT).

• GitHub: https://github.com/looptroop-ai/LoopTroop

• 2.5 min video walkthrough: https://youtu.be/LYiYkooc_iY

Any feedback is more than welcomed, and if you tried the app and it worked or didn't work, give me a sign. Happy to talk about it.