Athenode vs BMAD Method: comparison

Short answer: BMAD Method is a free, open-source method with role-based agents and the deepest planning of the file-based tools: a PRD, UX and architecture, then epics and stories with prerequisites, all as files in your repository. Athenode keeps a similar idea — a tree of work with dependencies — on the server, shared by the whole team, and runs from a quick one-spec fix up to large trees that agents implement unattended for hours.

At a glance

	Athenode	BMAD Method
Where specs live	On the Athenode server, shared by the project	Files in your repo (`_bmad-output/`), optional publishing to GitHub Issues, Jira or Linear
Team work	One shared tree, owner / editor / viewer roles, live progress	Through git; team settings committed to the repo
Old specs	Stay in the tree with Q&A, plan and changed files	Completed plans kept as files, plus retrospectives
Structure	A tree with blockers between any specs	Initiative → epics → stories, with prerequisites
Planning style	Questions at every level of one spec tree	Role-based: product, UX, architecture, development
Small changes	One spec, a few questions, apply — no decomposition	`bmad-build` for small changes
Large work	Unattended runs through a whole subtree, in blocker order	`bmad-build-auto`, one ticket per run; BMad Loop for an epic
AI tools	9, including Claude Code, Cursor, Codex, Copilot and Kiro	Any tool that supports skills
Licence and price	Hosted service with a free plan	Open source (MIT), free

How BMAD Method works

BMAD Method ("Breakthrough Method for Agile AI-Driven Development") gives your AI tool a set of role-based skills. For larger work you go through a planning path — product requirements, UX, an architecture "spine", one spec per epic — and break epics into stories with prerequisites and requirement coverage. bmad-build plans, implements and self-reviews one story at a time, bmad-build-auto runs unattended per ticket, and retrospectives read the git history when an epic is finished. Small changes go straight to bmad-build.

It is thorough, free and works on existing codebases. Its version 6 reorganised the method around skills, so older tutorials often describe files and agents that no longer exist.

Two ways to work: a small change or a whole application

Athenode is built for both ends of the scale, and you choose per task:

A small change. Run /mindmap-specification with a sentence about what you want. The agent asks a few basic questions you might have forgotten — edge cases, what should stay unchanged — and writes one specification. You then apply it straight away with /apply-specification, without decomposing anything. Minutes from idea to reviewed code.
A whole application or a large feature. Specify the project, decompose it into features and stages, and keep going — /decompose-specification asks its own questions at every level — until the entire tree is ready, before a single line of code is written. Blockers between specs set the build order. Then /apply-specification works through the tree on its own: it plans, implements and reviews every prepared leaf in dependency order without stopping to ask you anything, for hours on a large tree, even days.

Where the specs live

In Athenode, specifications live on the server, not in one developer's working copy:

The whole team sees the same tree. Everyone on a project works from the same specs, with owner, editor and viewer roles, and the app updates as agents make progress.
Nothing gets lost. Completed specs stay in the tree together with the questions and answers that shaped them, the implementation plan, and the list of changed files with a summary of what was done — so you can always look back at why and how something was built.
Your code stays in your repository. Agents read and update specs through the Athenode MCP server; Athenode never needs your source code.

The trade-off: you need an Athenode account and a connection to the service, and specs are reviewed in Athenode rather than in the same pull request as the code.

When to choose BMAD Method

You want role-based planning — product, UX, architecture — with formal documents and sign-off points.
You want everything as files in your repository, open source and free.
You want to publish work to GitHub Issues, Jira or Linear.
Your team is comfortable following a structured agile method end to end.

When to choose Athenode

Your team needs the plan in one shared place with roles and live progress, not as files on branches.
You want planning to come from questions at each level of one spec tree rather than a sequence of role documents.
You want unattended implementation through a whole subtree in one run, for hours, rather than one ticket per run.
You want the same tool to stay light for a quick fix.

Can you use both?

For separate projects, yes. On one project, keep a single source of truth for requirements.

Frequently asked questions

Can Athenode handle both quick fixes and large projects?

Yes. A quick fix is one specification and a few questions, applied straight away. A large project is a tree of specifications decomposed up front and implemented unattended, leaf by leaf in dependency order, for hours on a large tree.

Both tools have a hierarchy of work. What is the difference?

BMAD keeps initiatives, epics and stories as files in your repository. Athenode keeps the tree on the server, shared by the team, with blockers between any specs and completed specs kept with their questions, plan and changed files.

Is BMAD free?

Yes, BMAD Method is free and open source under the MIT licence. Athenode is a hosted service with a free plan.