RFC: BMaD Batch Method - Model Tiering for Team-Scale Rate Limit Sustainability

[Himalyan-AI]

Seeking Feedback Before PR Submission

Hi BMAD community! 👋

We've been scaling BMAD across our development team using Claude Max subscriptions with Claude Code, and encountered rate limit bottlenecks that cascaded through our team's velocity.

We developed a pattern we're calling the BMaD Batch Method and wanted to get community/maintainer feedback before submitting a PR.

---

The Problem We Faced

Working entirely on Opus became impractical at team scale:

• Individual developers hitting rate limits mid-sprint
• Context lost waiting for resets
• Bottlenecks rippling through the whole team

Our Solution: Strategic Model Tiering

Phase	Model	Rationale
Planning	Opus	Interprets ambiguous requirements, makes architectural decisions
Development	Sonnet	Mechanical translation of clear specs to code
Testing	Sonnet	Pattern-based, well-defined expectations
Review	Opus	Cross-story pattern detection, quality gates
Rework	Sonnet	Targeted fixes from specific review feedback

How Quality Is Preserved

Quality is front-loaded:

• Opus resolves ALL ambiguity during planning → crystal-clear story files
• Sonnet receives unambiguous specs → deterministic implementation
• Batch review with cross-story visibility actually IMPROVES quality

Results

~3-5x more stories completed per rate limit window with equivalent (or better) quality.

---

What We've Built

1. Architecture documentation (344 lines) explaining the pattern, rationale, and quality preservation mechanics

2. Supporting utility (sync-skills task) - discovered we needed this for custom module development

Current Limitations (Being Honest)

• Model switching is manual (/model command in Claude Code)
• Workflow UX for prompting model switches needs optimization
• This is alpha-stage - tested with our team but seeking broader validation

---

Questions for the Community

1. Does this align with BMAD's direction? We don't want to contribute something that conflicts with the project's vision.

2. Is the integration approach correct? We've tried to match existing patterns in src/core/tasks/ and docs/.

3. Would this be valuable? Are others hitting similar rate limit scaling issues?

4. Any red flags? Things we might have missed or got wrong?

---

Next Steps

Based on feedback, we're happy to:

• Share the full docs/code for review before formal PR
• Iterate on the approach
• Adjust scope (e.g., docs only, or include utility task)
• Abandon if it doesn't fit 😄

We closed a premature PR (#1333) to have this conversation first. Apologies for jumping the gun!

Looking forward to your thoughts.

— Team Himalyan-AI

[iter-next]

I've also encountered the same problem recently. I think this feature is very useful. Kudos to you all.