BMAD UI — A visual interface for the BMAD Method

[lorenzogm]

Hey everyone,

I have been using the BMAD Method for a while and kept running into the same friction: remembering which skill to invoke, in which order, with which agent, and keeping track of what has been completed across phases.

So I built BMAD UI — an open-source web interface that sits on top of your _bmad/ and _bmad-output/ directories and gives you full visibility into your project state.

What it provides:

• Workflow visualization — all four phases displayed with status, workflows, artifacts, and descriptions. Great for onboarding and for checking what comes next
• Session tracking — every CLI skill invocation is tracked with model, story, timestamps, and status
• Analytics dashboard — total tokens and costs, usage by model, cache hit rates, sessions by skill, requests by epic, activity heatmaps
• Execution support — shows the exact command to run for each workflow step (currently Copilot CLI, extensible to Cursor and Claude)
• It reads your local files — no database, no external dependencies. Everything stays in git.

I am also working toward a guided chat interface so non-technical team members (PMs, designers) can participate in BMAD workflows without CLI knowledge.

Links:

• Article with more details: https://lorenzogm.com/en/blog/bmad-ui-a-visual-interface-for-ai-driven-development
• Demo (read-only, real project data): https://bmad.lorenzogm.com
• Source code: https://github.com/lorenzogm/bmad-ui

Feedback and contributions are welcome. Would love to hear how others are managing the workflow complexity.

[bmadcode]

we have a few efforts in flight, if you would like to contribute also towards it would welcome the contribution - please reach out to me in the discord @lorenzogm if we have not chatted already in there!

[darraghh1]

Suggestion: make the Umami tracker opt-in (default off)

index.html ships with a hardcoded Umami tracking script:

<script defer src="/u/script.js" data-website-id="aa557b06-..."></script>

Two concerns worth thinking about:

1. Default-on telemetry surprises self-hosters. Anyone running the app from a fork, local dev, or their own Vercel deploy is sending pageviews to your Umami instance unless they read the HTML and remove the line. The npm/install path doesn't surface it.
2. The "proxied to bypass tracking protection" comment is the part that really stands out. Routing through /u/ defeats users' explicit choice to block third-party analytics — that's a different posture from just "we collect anonymous metrics."

A small tweak that keeps your data for the canonical deploy but respects everyone else:

<script> if (import.meta.env.VITE_ENABLE_ANALYTICS) { /* inject Umami */ } </script>

…or wrap the existing tag in a {import.meta.env.VITE_ENABLE_ANALYTICS && ...} in app.tsx, set VITE_ENABLE_ANALYTICS=true in your Vercel project, and document it in the deployment guide. Forks, local devs, and other self-hosters then opt in explicitly if they want it.

Happy to send a PR if useful.

[lonbadax]

Thariq Shihipar (Claude Code @ Anthropic) recently made the case that HTML is more comfortable than Markdown for certain documents.

In BMAD I'm thinking specifically about stories and epics — they're pretty heavy to read in MD and would be much more practical as HTML.

Could be a nice addition to your idea of making BMAD more visual. What do you think?

[sebastiandev]

well.. that would help with visualisation out of the box but would work against 3rd party UIs. I think as long as bmad stories and epics are well structured, then the viz layer should be built on top of them in HTML or whatever one needs.