Integrating parallel flows into BMAD natively to improve task creation.

[EnzoTironi]

Tested Bmad-Claude-Code today, it worked really well, from someone who used the official BMAD, it was a great improvement, thanks for your work!

Using OPUS-4 as orchestrator and Sonnet-4/Haiku, based on task evaluation. It`s an ambitious goal, but i think we could make great advancements using the most modern patterns of AI improvements.

Task Creator (Multiple Instances) => Update for considering parallel tasks and different models for sub-agents

Task Evaluator => Evaluate the different artifacts created and merge for best results in tasks and reduce HIL

Task GH Issues => Then create this task in Github issues using the cli

Task Execution=> Retrieve from GH issues, and execute using the proper instructions set before

I wanted to ask you, have you tested further on the idea of having an opus-4, orchestrating little haiku or sonnet instances? I tried some prompts, but couldnt validate if it were really spawning little agents, or just hallucinating.
I would love to brainstorm about, and add my contributions to the repo.

[cabinlab]

Hey! Totally missed the notification about this. I kinda stopped working on BMAD because Claude Code doesn't seem to like Agile. It was a struggle to prevent it from stripping things out every time I tried to make a change.

I have a private repo where I attempted to rebuild BMAD from the ground up to be completely Claude Code native. A big part of that was parallelization. Unfortunately, I couldn't get good enough results to make it public. There was a ton of semantic drift where one agent would use a term in one meaning of the word, then another agent would use it in another way, which totally changed the meaning and introduced tons of bugs. This happened repeatedly and I eventually nuked most of the work.

You mentioned GH issues, and that is sorta what I'm leaning toward now. However, not just issues, but using GitHub's native Projects (v2) to force additional structure. Their v2 Projects API is GraphQL only, and Claude actually writes GraphQL queries natively. So in theory, you can make the agents aware of the API, then have them directly write queries and skip dealing with resolvers or any code when interacting with the Projects API. Since Projects is built on top of Issues/PRs, this essentially adds different views (Kanban, roadmaps, etc.) to the humans working on the project.

Maybe you figured this out since you started this thread, but the native CC Tasks tool is actually its built-in agent spawning tool. So when you ask it to use parallel agents it uses the Task tool to spawn agents. This is easiest to see if you also use Plan-Mode to talk about the parallel agents because planning helps to talk to Claude about the model and thinking level each agent should use. And it does have the capability to specify these for the agents it spawns. However, there's zero visibility into what the agents are doing, and they often go off the rails and end up wasting a lot of tokens.

In the native Tasks tool, the subagents will generate their own CC-native Todo lists using TodoWrite and TodoRead. This is part of the native behavior. Claude is also [usually] aware of its Task/Agent capabilities. Because of that, you can ask it to use its Task tool to build the task package for each agent, then have it output a file with the exact prompt it would give to the spawned agents via the Tasks tool. But with regular prompting, you can't make this happen in a consistent and predictable manner. So if you just try to manually spawn agents in parallel terminals or TMUX or Docker containers or whatever, it doesn't work quite the same as the native Task tool. And as you've probably noticed, CC agents don't listen and/or read carefully when instructions are in markdown files (or whatever). But they do take their own native Todo lists seriously.

Where we can get the power back is via the Claude Code SDK. Via the SDK, Claude can generate native TodoWrite and TodoRead task lists, then translate them back and forth between GitHub issues and sub-issues (GH deprecated Todos in Issues). This circles back to what you're talking about. You can have Opus writing CC-native Todo lists for whatever mix of agents is best for your flow or Pro vs Max 5x vs Max 20x.

The last time I worked on it was about a day before Hooks came out, which makes all of this potentially even more powerful. I dunno, I have a private repo where I started to build the translation layer between GH and the native Claude Code features, but haven't built it out yet.