I've been running the dashboard against a v6.8.0 project and the Play/Copy buttons don't launch any of the workflows.
The commands are hardcoded to the old slash-command names (/bmad-bmm-dev-story etc.), but v6 installs everything as Claude Code skills now. There's no .claude/commands/ anymore, just .claude/skills/<id>/SKILL.md, and the bmm workflows drop the module segment, so it's bmad-dev-story, not bmad-bmm-dev-story. A couple of the mappings are also just stale: create-prd points at bmad-create-prd (deprecated; it's bmad-prd now), and qa-automate should be bmad-qa-generate-e2e-tests.
The good news is the install has what's needed to avoid hardcoding entirely: _bmad/_config/skill-manifest.csv lists every installed skill (id, description, module, path), and _bmad/_config/manifest.yaml has an ides: list of which tools the project was set up for.
That ides list is the other thing I wanted to raise: actions currently assume claude in a terminal, but installs often target more than one tool, and some of them (Cursor, Kiro, etc.) aren't terminal-driven at all.
Before I put up a PR I wanted to check the direction:
- Is it OK to read those manifests at runtime, or would you rather keep a static command map while things are still alpha?
- For the non-CLI tools, is "copy the invocation and let the user paste it" reasonable, or did you have something else in mind?
I've got a working branch that does the manifest-based discovery plus a small per-tool indirection (run in the terminal for Claude Code / Codex, copy for the rest), with tests passing. Happy to open it once you point me the right way.
I've been running the dashboard against a v6.8.0 project and the Play/Copy buttons don't launch any of the workflows.
The commands are hardcoded to the old slash-command names (
/bmad-bmm-dev-storyetc.), but v6 installs everything as Claude Code skills now. There's no.claude/commands/anymore, just.claude/skills/<id>/SKILL.md, and the bmm workflows drop the module segment, so it'sbmad-dev-story, notbmad-bmm-dev-story. A couple of the mappings are also just stale:create-prdpoints atbmad-create-prd(deprecated; it'sbmad-prdnow), andqa-automateshould bebmad-qa-generate-e2e-tests.The good news is the install has what's needed to avoid hardcoding entirely:
_bmad/_config/skill-manifest.csvlists every installed skill (id, description, module, path), and_bmad/_config/manifest.yamlhas anides:list of which tools the project was set up for.That
ideslist is the other thing I wanted to raise: actions currently assumeclaudein a terminal, but installs often target more than one tool, and some of them (Cursor, Kiro, etc.) aren't terminal-driven at all.Before I put up a PR I wanted to check the direction:
I've got a working branch that does the manifest-based discovery plus a small per-tool indirection (run in the terminal for Claude Code / Codex, copy for the rest), with tests passing. Happy to open it once you point me the right way.