Describe your idea
Add a "tracker-first" execution mode that reads a project's sprint-status.yaml (and an optional lane-map.yaml dependency graph) and dispatches dev, review, QA, and retrospective work across multiple stories in parallel, instead of driving stories one at a time. Alongside it, add an optional advisory UX loop that periodically delegates to a UX-designer agent for design judgment (and, when a design system is detected, runs a deterministic scan for things like color-token drift or new unmapped pages) and appends timestamped findings to a status file for human review — without ever blocking a story from reaching "done".
Why is this needed?
Once epics and stories are planned, the current model works through them sequentially — story 2 waits for story 1 even when they have no real dependency. Most stories in a sprint aren't actually sequential; only a few have genuine dependencies on each other. A lane-map-driven approach lets independent stories start immediately and only gates the ones with an explicit depends_on, which shortens wall-clock time for a sprint round considerably. Separately, UX consistency tends to drift silently during fast parallel execution since nobody is watching design fidelity as stories complete — an advisory, non-blocking loop closes that gap without adding a hard gate to the pipeline.
How should it work?
- A tracker-first orchestrator skill/agent reads sprint-status.yaml plus a lane-map.yaml listing each story's id and depends_on. Each round, it computes which stories are eligible to start now (no unmet dependencies) and dispatches dev → review → QA → retro lanes for each in parallel.
- Dependencies gate individual stories, not the round as a whole — the moment a blocking story clears review, everything waiting only on it can start immediately, independent of other in-flight stories.
- Each round ends with a machine-readable closure line (e.g. done: X/X, retros: X/X, churn: none) that a lightweight evaluator (or a human) can check to decide whether the round is complete.
- A separate, optional orchestration loop runs on its own interval (e.g. every 20–40 minutes) and delegates to a UX/design-review agent for judgment calls (missing design dossiers, journey drift, prototype candidates). If a design-system file is present, it first runs a deterministic scan (hex-color drift, missing design-token references, newly added pages not yet mapped) and passes those results into the agent's review. Findings are appended, timestamped, to a status file for review in a dashboard — purely advisory, never blocking.
- A PM/monitoring loop periodically summarizes tracker state (risks, blockers, on-track assessment) independent of the mechanical closure check.
I prototyped this as a standalone BMad Method addon here: https://github.com/molenaar/mm-plo-addon — it implements exactly this (mm-plo-orchestrator for lane-based parallel dispatch, mm-ux-orchestrator for the advisory UX loop) as two skills on top of BMad. Happy to have bmad-auto borrow the approach, or adapt the addon's lane-map / closure-line / advisory-loop patterns directly.
PR
Not currently working on a PR — sharing the idea and the working prototype in case the bmad-auto maintainers want to adopt or adapt it. Would review CONTRIBUTING.md and consider contributing if there's interest.
Additional context
Describe your idea
Add a "tracker-first" execution mode that reads a project's sprint-status.yaml (and an optional lane-map.yaml dependency graph) and dispatches dev, review, QA, and retrospective work across multiple stories in parallel, instead of driving stories one at a time. Alongside it, add an optional advisory UX loop that periodically delegates to a UX-designer agent for design judgment (and, when a design system is detected, runs a deterministic scan for things like color-token drift or new unmapped pages) and appends timestamped findings to a status file for human review — without ever blocking a story from reaching "done".
Why is this needed?
Once epics and stories are planned, the current model works through them sequentially — story 2 waits for story 1 even when they have no real dependency. Most stories in a sprint aren't actually sequential; only a few have genuine dependencies on each other. A lane-map-driven approach lets independent stories start immediately and only gates the ones with an explicit depends_on, which shortens wall-clock time for a sprint round considerably. Separately, UX consistency tends to drift silently during fast parallel execution since nobody is watching design fidelity as stories complete — an advisory, non-blocking loop closes that gap without adding a hard gate to the pipeline.
How should it work?
I prototyped this as a standalone BMad Method addon here: https://github.com/molenaar/mm-plo-addon — it implements exactly this (mm-plo-orchestrator for lane-based parallel dispatch, mm-ux-orchestrator for the advisory UX loop) as two skills on top of BMad. Happy to have bmad-auto borrow the approach, or adapt the addon's lane-map / closure-line / advisory-loop patterns directly.
PR
Not currently working on a PR — sharing the idea and the working prototype in case the bmad-auto maintainers want to adopt or adapt it. Would review CONTRIBUTING.md and consider contributing if there's interest.
Additional context