Forem: Lars

Bmalph: BMAD planning + Ralph autonomous loop, glued together in one command

Lars — Mon, 23 Feb 2026 10:06:10 +0000

I built Bmalph because I kept running into the same problem: AI coding assistants are great at writing code, but terrible at remembering why you made a decision three features ago. You re-explain context, the architecture drifts, things contradict each other. For small projects that's fine. For anything real, it's a slow disaster.

bmalph is a CLI that combines two great existing open source projects: BMAD-METHOD for structured AI planning, and Ralph for autonomous implementation. One command installs and wires them together in your project.

Until last week it only worked with Claude Code. That's changed.

How it works

The core idea is simple: separate thinking from doing.

Phases 1-3 (BMAD — Planning)

Before any code gets written, you work interactively with specialized AI agents: an Analyst, a Product Manager, and an Architect. They guide you through producing a product brief, a PRD, UX specs, architecture decisions, and user stories. The AI asks questions. You make decisions. Nothing moves forward without your input.

The output is a set of real planning documents that live in your repo under _bmad-output/. Not chat history. Not a summary in your clipboard. Actual files that persist.

Phase 4 (Ralph — Implementation)

Once planning is done, Ralph takes those docs and implements them autonomously. It picks the next story from @fix_plan.md, writes tests first, implements the code, commits, and moves on to the next story. You don't babysit it. The loop runs until the board is empty or the circuit breaker trips.

The key thing Ralph has that vanilla Claude Code doesn't: a persistent spec. When it implements story 8, it still knows what was decided in story 1 because the planning docs are right there.

Multi-platform support

The initial release assumed Claude Code. That was limiting. This release adds support for six platforms across two tiers.

Platform	Tier	What you get
Claude Code	Full	Phases 1-4, BMAD + Ralph loop
OpenAI Codex	Full	Phases 1-4, BMAD + Ralph loop
Cursor	Instructions-only	Phases 1-3, BMAD planning only
Windsurf	Instructions-only	Phases 1-3, BMAD planning only
GitHub Copilot	Instructions-only	Phases 1-3, BMAD planning only
Aider	Instructions-only	Phases 1-3, BMAD planning only

The tier split comes down to one thing: whether the platform exposes a scriptable CLI. Ralph is a bash loop that spawns fresh AI sessions, so it needs claude or codex in your PATH. Cursor, Windsurf, Copilot, and Aider don't work that way, so they get the planning workflow only.

That said, Phases 1-3 alone are where most of the thinking happens. If you're on an instructions-only platform you still get the full BMAD workflow: analysts, PRDs, architecture, epics, stories.

Platform detection is automatic. Run bmalph init and it figures out which platform you're using from project markers. Or pass --platform <id> explicitly.

npm install -g bmalph

# auto-detect
bmalph init

# or be explicit
bmalph init --platform codex
bmalph init --platform cursor

How bmalph compares to just using your AI assistant directly

This comes up a lot so let me be direct about it.

Just prompting Claude Code / Cursor / Copilot directly

Fine for small tasks. A bug fix, a component, a quick script. bmalph is overkill for that. If you're reaching for bmalph on a weekend project you're over-engineering your workflow.

Where it breaks down is anything with multiple moving parts spanning more than a few sessions. The AI has no memory of earlier decisions, you end up re-explaining context constantly, and the architecture slowly drifts into something nobody planned.

BMAD-METHOD standalone

BMAD is great but setting it up manually in each project is friction. bmalph bundles and installs it with one command, keeps it versioned, and wires it to Ralph. If you're already using BMAD standalone, bmalph init is essentially a migration path — it preserves your _bmad-output/ artifacts.

Devin, SWE-agent, and other fully autonomous systems

Different category. Those are trying to do everything autonomously from a single prompt. bmalph keeps you in the loop during planning — you're making decisions with the AI agents, not handing off a spec and waiting. Ralph only takes over once you've explicitly approved the plan and triggered the implementation.

BMAD is now stable

Earlier versions had version drift issues where the bundled BMAD could get out of sync. That's fixed. The bundled version is now pinned, tested, and the upgrade path is clean.

bmalph upgrade

This updates the bundled BMAD and Ralph assets without touching _bmad-output/ — your planning artifacts are never overwritten.

What's next

A few things on the roadmap:

Story-level diff summary. After each story, Ralph automatically generates a readable summary of what changed, which files were touched, and whether tests passed. Right now that's buried in raw logs.

Automatic context regeneration. When Ralph gets stuck, the circuit breaker detects it and stops. Instead: automatically run GPC (Generate Project Context) and refresh the context before the next iteration.

Multi-agent Ralph. Instead of one Claude/Codex session per story, Ralph spawns a separate session per layer: one for tests, one for implementation, one for review. More complex, but closer to how a real team works..

Try it

npm install -g bmalph
bmalph init

Repo: github.com/LarsCowe/bmalph

Questions, feedback, or war stories from using it in production — all welcome.

I got tired of copy-pasting messages from RabbitMQ to validate them, so I built an MCP server

Lars — Sun, 15 Feb 2026 11:18:56 +0000

If you've worked on projects where teams communicate through message brokers, you know the drill. A message lands in a queue with a broken payload. Maybe a field is the wrong type, maybe a required property is missing, maybe someone changed the schema without telling anyone.

The debugging loop looks like this:

Open the RabbitMQ management UI
Navigate to the queue
Click "Get messages"
Copy the payload
Find the JSON Schema for that message type
Paste it into some online validator
Read the error
Fix the publisher
Repeat

I did this dozens of times per week. So I built an MCP server that does it in one sentence.

What is MCP?

Quick context if you haven't seen it yet: MCP (Model Context Protocol) is a standard that lets AI assistants call external tools. If you use Claude Code, Cursor, VS Code Copilot, or Windsurf, you can add MCP servers that give your assistant new capabilities.

Think of it like plugins, but standardized across clients.

The idea

What if I could just ask my AI assistant:

"Inspect the orders queue and check if all messages are valid"

And it would connect to my broker, peek at the messages (without consuming them), validate each one against the right JSON Schema, and tell me exactly what's broken?

That's what Queue Pilot does.

How it works

You define your message contracts as JSON Schema files. These are the schemas your teams already agreed on (or should agree on). Each schema has an $id that matches the type field on your messages.

// schemas/order.created.json
{
  "$id": "order.created",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Order Created",
  "type": "object",
  "required": ["orderId", "amount"],
  "properties": {
    "orderId": { "type": "string" },
    "amount": { "type": "number", "minimum": 0 }
  }
}

Then you add Queue Pilot to your MCP client. One command generates the config:

npx queue-pilot init --schemas ./schemas --client claude-code

That's it. Your assistant now has access to your broker.

What you can actually do with it

Here's where it gets practical. These are real prompts I use daily:

Debugging a broken consumer:

"Show me the messages in the dead-letter queue and validate them"

Queue Pilot peeks at the messages, matches each one to its schema by the type field, and returns validation errors. No more copy-pasting.

Before deploying a publisher change:

"Publish this to the events exchange: { "type": "order.created", "orderId": 123, "amount": "fifty" }"

The publish_message tool validates against the schema first. This message would be rejected because orderId should be a string and amount should be a number, not a string. Invalid messages never hit the broker.

Checking queue health across the board:

"List all queues and show me which ones have backed-up messages"

Setting up test infrastructure:

"Create a queue called test-orders, bind it to the events exchange with routing key order.*, and publish 3 test messages"

The inspect_queue tool

This is the one I use most. It combines peeking and validation in a single call.

When you ask your assistant to inspect a queue, Queue Pilot:

Fetches messages from the queue without consuming them
Looks at each message's type property
Finds the matching schema by $id
Validates the payload against that schema
Returns a report: which messages are valid, which aren't, and exactly why

For a queue with 5 messages where 2 have issues, you'd get something like:

Messages 1, 2, 4: Valid (order.created)
Message 3: Invalid (order.created)
  - /amount: must be number, got string
Message 5: No matching schema for type "order.updated"

No browser tabs. No copy-pasting. No context switching.

Kafka support

Queue Pilot also supports Apache Kafka through a unified adapter interface. The same tools work for both brokers, plus Kafka-specific ones like list_consumer_groups, describe_consumer_group, list_partitions, and get_offsets.

npx queue-pilot init --schemas ./schemas --broker kafka --client claude-code

The Kafka adapter uses the Confluent JavaScript client and supports SASL authentication.

Setup in 2 minutes

1. Create your schemas directory

Put your JSON Schema files in a folder. One file per message type.

2. Generate config for your MCP client

# Claude Code
npx queue-pilot init --schemas /path/to/schemas --client claude-code

# Cursor
npx queue-pilot init --schemas /path/to/schemas --client cursor

# VS Code
npx queue-pilot init --schemas /path/to/schemas --client vscode

3. Start using it

Open your editor and ask your assistant about your queues. It has access to 14+ tools for inspecting, validating, publishing, and managing your message infrastructure.

The full tool list

Universal (all brokers): list_schemas, get_schema, validate_message, list_queues, peek_messages, inspect_queue, get_overview, check_health, get_queue, list_consumers, publish_message, purge_queue, create_queue, delete_queue

RabbitMQ-specific: list_exchanges, create_exchange, delete_exchange, list_bindings, create_binding, delete_binding, list_connections

Kafka-specific: list_consumer_groups, describe_consumer_group, list_partitions, get_offsets

When is this useful?

Queue Pilot is designed for development and testing, not production monitoring. It shines when:

Multiple teams publish/consume messages and schemas drift over time
You're debugging why a consumer is failing on certain messages
You want to validate message contracts before merging a PR
You need to quickly set up queues, bindings, and test data for local development
You want to catch schema violations before they reach a test environment

What's next

The project is at v0.5.0. Kafka support is newer and I'm looking for feedback from people who work with multi-team message contracts. If you have ideas or run into issues, open an issue on GitHub.

Links:

GitHub: github.com/LarsCowe/queue-pilot
npm: npmjs.com/package/queue-pilot

If you work with message queues and MCP-compatible editors, I'd love to hear how you handle schema validation in your workflow. Drop a comment or open an issue.

I Glued 2 of the Best AI Dev Frameworks Together

Lars — Thu, 12 Feb 2026 11:14:21 +0000

If you've used Claude Code for anything beyond quick scripts, you know the pattern: you start prompting, things go well for 20 minutes, then your project turns into spaghetti because there was never a plan.

I ran into this constantly. So I started using two open-source tools separately:

BMAD-METHOD: a structured planning system with AI agents that walk you through product briefs, PRDs, architecture docs, and user stories.
Ralph: an autonomous bash loop that picks up stories one by one and implements them with TDD, committing as it goes.

Both are solid on their own. But switching between them was friction. Copy-pasting artifacts, manually setting up Ralph's task list, keeping things in sync when plans changed. It wasn't hard, just annoying enough that I kept thinking "this should be one thing."

So I spent about a month building bmalph: a CLI that installs both systems, connects them with slash commands, and handles the handoff from planning to implementation.

How it works

npm install -g bmalph
cd my-project
bmalph init

This drops BMAD agents, Ralph's loop, and 50+ slash commands into your project.

From there, you work through 3 planning phases in Claude Code using slash commands like /analyst, /pm, and /architect. Each phase has specific deliverables: product brief, PRD, architecture, stories.

When your plan is solid, you run /bmalph-implement. This reads your BMAD stories, generates Ralph's task list (@fix_plan.md), copies specs over, and you start the autonomous loop:

bash .ralph/ralph_loop.sh

Ralph picks stories from the plan, implements with TDD, commits, moves to the next one. Circuit breaker stops it if something goes wrong. Ctrl+C if you want to stop manually.

The part I actually like

Incremental development works well. You can plan Epic 1, let Ralph build it, then go back to BMAD to plan Epic 2. When you run /bmalph-implement again, it preserves completed stories and adds the new ones. A specs changelog tracks what changed so Ralph knows what's new.

Why I'm posting this

I've been using bmalph on my own projects and it works for my workflow. But I'm one person with one way of working, so I'm genuinely curious:

Does this workflow make sense to you, or is it overengineered for how you use Claude Code?
What's missing?
What would you change?

If you try it, give it a star and open an issue or drop a comment. Stars help with visibility, but honest feedback is what actually makes it better.

GitHub: https://github.com/LarsCowe/bmalph

I combined two AI dev tools into one workflow - here's bmalph

Lars — Tue, 27 Jan 2026 16:25:26 +0000

I've been using Claude Code with two separate methodologies:

BMAD-METHOD handles my planning. Analyst agent for requirements, PM for PRDs, architect for technical decisions. Generates thorough documentation with clear acceptance criteria.

Ralph handles implementation. Autonomous TDD loop that picks up stories, writes tests first, implements, commits.

The problem: they don't talk to each other. I was manually copying requirements, reformatting task lists, losing context along the way.

So I built bmalph.

One CLI that installs both systems and connects the workflow:

bmalph init

Now my process is:

Plan with BMAD slash commands (/analyst, /pm, /architect)
Run /bmalph-implement
Ralph takes over with autonomous TDD

Everything stays in my repo. Planning artifacts convert directly to implementation tasks. No manual bridging, no lost context.

Best of both worlds: BMAD's planning depth combined with Ralph's autonomous execution.

GitHub: https://github.com/LarsCowe/bmalph