rp1 vs BMAD: AI Development Workflow comparison

You have a feature to build. Your AI coding assistant can generate the code, but who decides what to build, in what order, and how to know it is done?

Two open-source tools tackle this problem from different angles: BMAD-METHOD (46k+ stars, established community) and rp1 (newer, workflow-first approach). Both aim to replace ad-hoc prompting with structured planning. They make different trade-offs worth understanding before you commit.

This post walks through a real planning scenario with both tools so you can evaluate the fit for your team.

The Scenario: Team Notification Service

Imagine you are building an internal notification service for your engineering team. Requirements seem simple at first: send alerts when deployments finish, when CI pipelines fail, or when on-call incidents trigger. But complexity surfaces quickly.

Multiple delivery channels (email, Slack, SMS). Different teams want different routing rules. Some alerts are critical (page the on-call); others are informational (weekly digest). You need audit logging for compliance. And the mobile team wants push notifications eventually.

This is exactly the kind of project where unstructured “just start coding” leads to rework. Let us see how each tool approaches the planning.

How rp1 Handles It

rp1 organises planning into three commands that form a linear workflow: [/blueprint](https://rp1.run/reference/dev/blueprint/) for requirements, [/phase-plan](https://rp1.run/reference/dev/phase-plan/) for decomposition, and [/blueprint-audit](https://rp1.run/reference/dev/blueprint-audit/) for progress tracking.

Step 1: /blueprint (Brain Dump to PRD in ~10 Questions)

You start with [/blueprint](https://rp1.run/reference/dev/blueprint/). The command runs a guided interview in two stages.

Charter interview (up to 5 questions). The first question is always an open-ended brain dump: describe the project in your own words. rp1’s charter-interviewer agent analyses your answer and determines which of five sections (Problem, Users, Value Proposition, Scope, Success Criteria) your response already covers. It then asks targeted follow-up questions only for the gaps, in priority order: Problem first, then Users, Value Prop, Scope, and Success Criteria.

If your brain dump is thorough, you might answer only 3 questions total. The agent is stateless; it reads a scratch pad embedded in the charter document to determine what has been covered. It never re-asks a question you have already answered.

PRD interview (up to 5 questions). Once the charter exists, rp1 runs a second interview for the surface-specific PRD, covering Overview, Scope, Requirements, Dependencies, and Timeline. It infers context from your README and existing docs to pre-fill answers, using a “validate” response type that lets you confirm inferred details rather than retyping them.

For our notification service, the charter captures the “why” (teams are missing critical alerts, current email-only approach has no routing) while the PRD captures the “what” (multi-channel delivery, routing rules, audit logging, API design).

Output: charter.md (project-level) and prds/notifications.md (surface-specific). Both are version-controlled markdown.

Step 2: /phase-plan (Vertical Slices, Not Horizontal Layers)

This is where rp1 is most opinionated. You run [/phase-plan](https://rp1.run/reference/dev/phase-plan/) prds/notifications.md and the phase-planner agent decomposes your PRD into 2-5 delivery phases.

The agent enforces a Slice Validity Rubric with four mandatory criteria. Every phase must be:

| # | Criterion                     | What It Means                                        |
| - | ----------------------------- | ---------------------------------------------------- |
| 1 | **Framed**                    | States the sub-problem it solves                     |
| 2 | **Independently deliverable** | Ships user-visible value alone                       |
| 3 | **Independently testable**    | Verifiable without later phases                      |
| 4 | **Stackable**                 | Composes on prior phases with obvious value gradient |

The agent explicitly rejects horizontal decomposition. Here is the difference for our notification service:

Horizontal (what rp1 rejects):

| Phase | Scope                                    | Problem                 |
| ----- | ---------------------------------------- | ----------------------- |
| P1    | Data model for all notification types    | No shippable value      |
| P2    | API layer for all endpoints              | Still nothing works     |
| P3    | Channel integrations (Slack, email, SMS) | Finally something ships |

Vertical (what rp1 produces):

| Phase | Scope                                                   | Ships Value                                |
| ----- | ------------------------------------------------------- | ------------------------------------------ |
| P1    | Slack notifications end-to-end (model + API + delivery) | Teams get Slack alerts for deployments     |
| P2    | + Email channel with routing rules                      | Teams choose Slack or email per alert type |
| P3    | + SMS for critical alerts with on-call integration      | P0 incidents page the right person         |
| P4    | + Audit logging and compliance dashboard                | Security team has the trail they need      |

Each phase ships something teams can use. If you stop after P2, you still have a working notification service. The agent runs a self-review pass, marking each slice against the four criteria, and merges or reorders until all pass.

Output: prds/notifications-phase-plan.md with initiative framing, phase details, exit criteria, and child handoff rows. Each row includes a ready-to-run [/build](https://rp1.run/reference/dev/build/) command for that phase.

Step 3: /blueprint-audit (Evidence-Based Progress Tracking)

After your team has built a few phases, you run [/blueprint-audit](https://rp1.run/reference/dev/blueprint-audit/) notifications. The auditor gathers evidence across three tiers:

1. Archived features: checks archives/features/ for completed features linked to this PRD
2. Active features: checks features/ for in-progress work; presence of a verification report means complete
3. Codebase: greps for phase-related keywords when the first two tiers are insufficient

It classifies each phase as Complete, Partial, or Not Started. Then it asks: is this PRD still relevant? You get five options:

• Archive the PRD (done; triggers closure summary)
• Add scope (new requirements emerged)
• Remove scope (descope phases that are no longer needed)
• Continue (keep going as planned)
• Defer (pause for now)

This closes the loop. Planning feeds execution, execution feeds evidence, evidence feeds planning decisions.

How BMAD Handles It

BMAD takes a different philosophy. Where rp1 uses stateless agents behind an orchestrator, BMAD creates a team of named AI personas that collaborate through conversation.

Agent-Team Approach

BMAD defines six named agents, each with a distinct role:

| Agent   | Role                        |
| ------- | --------------------------- |
| Mary    | Analyst / Business Analyst  |
| John    | Product Manager             |
| Winston | System Architect            |
| Amelia  | Senior Engineer / Developer |
| Sally   | UX Designer                 |
| Paige   | Technical Writer            |

For our notification service, the full workflow would flow: Mary (research and analysis) to John (PRD creation) to Winston (architecture document) to Amelia (epic and story breakdown, then implementation).

Quick Flow vs Full Flow

BMAD offers two tracks. Quick Flow is for small features; it produces a single technical spec and lets you start coding in under 5 minutes. An independent review described it as having “the lowest barrier to start: two steps, one document.”

Full Flow is for complex work. It produces a PRD, architecture document, and story breakdown. The same review measured full flow at roughly 6 days end-to-end (2 days planning, 4 days implementation) for a moderately complex feature.

Adversarial Review

BMAD’s strongest capability is its adversarial code review, which scored 5/5 for iterative refinement in the independent review. The reviewer noted it “surfaces issues before passing and catches things a standard review would miss.” This is a genuine strength; mandatory problem-finding as a quality gate is valuable when you need high-confidence output.

The Complexity Trade-off

BMAD’s breadth comes with a learning curve. The same independent review scored Full Flow’s developer experience at 2 out of 5, noting: “BMAD Full scores high on visibility because /bmad-help reads your project state and tells you what to do next. But it mostly exists to rescue you from BMAD's own complexity."

The reviewer described the challenge as “a heavy artifact set and a steep learning curve.” Quick Flow mitigates this by scoping down to two steps and one document, scoring a more favourable 3/5 on developer experience.

Key Differences at a Glance

| Dimension                | rp1                                                            | BMAD                                                                   |
| ------------------------ | -------------------------------------------------------------- | ---------------------------------------------------------------------- |
| **Philosophy**           | Workflow-centric: stateless agents behind orchestrators        | Agent-team: named personas that collaborate                            |
| **Planning friction**    | \~10 questions (5 charter + 5 PRD) with smart inference        | Full Flow: multi-agent sequence producing PRD + architecture + stories |
| **Work decomposition**   | Enforced vertical slices via Slice Validity Rubric             | Epic/story breakdown via PM and Architect agents                       |
| **Quality gate**         | Three-tier evidence-based audit (archives, features, codebase) | Adversarial review (mandatory problem-finding, scored 5/5)             |
| **Lifecycle management** | Five dispositions: archive, add/remove scope, continue, defer  | Course correction command available anytime                            |
| **Quick start**          | Single `/blueprint` command starts the interview               | Quick Flow: two steps, one document, code in 5 minutes                 |
| **Community**            | Newer project, growing                                         | 46k+ stars, YouTube masterclass, active Discord                        |

When to Use Which

rp1 fits well when:

• You want minimal friction from idea to delivery plan
• Your team values vertical slice decomposition and wants it enforced, not suggested
• You need evidence-based progress tracking against your plan
• You work with Claude Code (stable support), OpenCode, or Codex CLI

BMAD fits well when:

• You want multi-agent brainstorming and adversarial review
• Your project needs UX design or technical writing as first-class planning activities
• You use Quick Flow for small features alongside Full Flow for larger ones

These tools are not mutually exclusive in philosophy. Both reject ad-hoc prompting in favour of structured planning. Both produce version-controlled artifacts. The difference is in how they get there: rp1 optimises for a guided, low-friction path from intent to delivery-ready phases; BMAD optimises for role-based collaboration with deep review capabilities.

Try Both

The best way to evaluate is to run both on a real project. Both are open source and free:

Start with a small feature you are planning next week. Run /blueprint in rp1 to see how the guided interview captures your intent. Run BMAD's Quick Flow to see how the agent-team approach feels. Compare the artifacts each produces and decide which workflow matches how your team thinks.

The structured AI development space is young. Both projects are actively shipping (rp1 is on v0.7.6 with 83 releases; BMAD is on v6.6.0 with 32 releases). Your feedback shapes what these tools become.

rp1 is an open-source workflow layer for AI coding assistants. GitHub | Docs | Discord

BMAD-METHOD is an open-source AI-native development framework. GitHub | Docs

Independent review referenced: ranthebuilder.cloud