BMAD Sprint Board
A DSH Harness plugin that reads a
BMAD v7 project and shows it
in the Session sidebar: every initiative, what is being worked on, and what the
ticket store disagrees with the tickets on disk.
Read-only. It never writes to your ticket store. Every action it offers is a
string you copy.
Requirements │ BMAD Sprint board │ Chat
-------------------------------------------
Status Epic Tickets Initiatives
tools done 4 epics 16 tickets <- initiative, active when set
GAPS (2)
L1 plans not linked in the ticket store high
16 plan files match a ticket by name, but no entry
declares them with a ticket key [Ask agent · prompt]
C1 epic settled with open tickets high
epic-tools-landing says done, 2 tickets open
BLOCKED (1) IN PROGRESS (2) DONE (13) UNKNOWN (29)
What you get
Four views, one tab
| View | Shows |
|---|---|
| Status | One foldable lane per ticket state, with a gaps board beneath it |
| Epic | One section per epic: its status, its tickets, and its progress |
| Tickets | Every ticket in the initiative, grouped by state, across all epics |
| Initiatives | Every initiative with its status and counts, marking the active one |
Selecting an initiative in Initiatives loads it into the other three views.
The selection is local: nothing is written back, so looking at another initiative
cannot change which one BMAD considers active.
BMAD v7 only
This is version 2. Version 1 read BMAD v6 -- sprint-status.yaml, epics.md,
spec-*.md -- and none of those exist in a v7 project. The two are different
data models, not different formatting, so the plugin is released in two versions:
| BMAD | Install |
|---|---|
| v7 | dsh-plugin-bmad-sprint-board (this one, 2.x) |
| v6 | dsh-plugin-bmad-sprint-board@1.0.0 |
Opened on a v6 project, 2.x says so and points at 1.0.0 rather than rendering an
empty board.
The gaps board
The board is a check on the ticket store, not a mirror of it.
| Detector | Fires when |
|---|---|
| L1 unreadable ticket files | a file in a ticket folder is neither a leaf ticket nor a plan, so the store ignores it |
| L2 unlisted leaves | a leaf ticket exists on disk with no entry in the ticket index |
| L3 plans no ticket claims | a plan file corresponds to no index entry |
| L4 unrecognised status | a ticket carries a status word this board does not know |
| C1 epic settled with open tickets | an epic says done while tickets inside it are not |
| C2 initiative settled with open tickets | an initiative says done while tickets inside it are not |
| E1 initiative declares no epics | the folder exists and its store lists no epics |
L1 is the one that matters on a migrated project. The ticket store decides
what a file is from its frontmatter type: story, spike or bug is a leaf
that carries the ticket, anything else declaring a ticket key is a plan over
one, and anything else is ignored. A file named story-x-plan.md whose type is
feature and which names no ticket is therefore neither — invisible to the
tooling, which reports its ticket as backlog however finished the work is. Every
number it prints is wrong while every file on disk looks correct.
The board's lanes are the store's lanes. States come from tickets.py's own
table rather than being invented: an empty status is backlog, because a planned
story looks exactly like that before bmad-build writes its plan — a plan is an
artefact of building, not a precondition of existing. Only a status word the store
does not define becomes unknown, and it is shown but never counted as settled.
How it reads a v7 project
It resolves the same two keys the official tooling does, by merging the same
three files lowest priority first:
_bmad/config.toml [core] output_folder
_bmad/custom/config.toml team overrides
_bmad/custom/config.user.toml [core] active_initiative
which is what _bmad/scripts/resolve_config.py does. The board agrees with that
script rather than assuming a layout.
Install
From npm, into the web profile:
dsh plugin --profile web add dsh-plugin-bmad-sprint-board
Or from the repository, and from a local clone:
dsh plugin --profile web add github:vitaliy-bobrov/dsh-plugin-bmad-sprint-board
dsh plugin --profile web add /path/to/bmad-sprint-board-bundle
Substitute your own profile name for web. Nothing needs building, the package
has no dependencies, and it runs no install scripts. Reload the page afterwards:
the Client half registers on the next load, and the Host half contributes nothing
to register.
The same three, through the agent's tool rather than the CLI:
plugin_manager({ action: "install_bundle",
target: "dsh-plugin-bmad-sprint-board" })
Peer dependency
The manifest declares one peer, and the range is not the obvious one:
"peerDependencies": { "@deepseek-ai/dsh": "^0.2.0-0" }
A plain ^0.2.0 is rejected. The compatibility check compares the range
against the running version with prereleases included, and against a runtime such
as 0.2.0-rc.2 a bare ^0.2.0 does not match — so the install is refused before
pnpm runs. ^0.2.0-0 resolves to >=0.2.0-0 <0.3.0-0: prereleases of 0.2.0,
every later 0.2.x, and nothing beyond.
Category
UI & Experience. It adds a sidebar tab and reads. It contributes no tool, no
model and no service, and it writes nothing.
Extending
The plugin is two layers, and only the second knows about DSH:
| What | Where |
|---|---|
| Parsers | src/toml.js, src/frontmatter.js — the two readers BMAD's files need |
| The project model | src/config.js, src/store.js, src/model.js, src/scan.js — pure, no DSH, no DOM |
| The checks | src/detect.js |
| How it renders | src/shell-*.js — CSS, components, slot registration |
Adding a view is one entry in the view list in src/shell-post.js plus a body
function; the switcher, the fold state and the snapshot are already shared.
Adding a detector is a function returning gaps shaped
{ id, title, severity, subject, evidence, action } and one push in
detectInitiative(). src/model.test.js shows the shape: each detector is
tested against a fixture that should fire it and a clean fixture beside it,
because a detector nobody has checked can stay quiet is one nobody has checked.
node build.mjs # reassemble client.js from src/
node build.mjs --check # fail if client.js and src/ have drifted apart
node --test src/*.test.js
client.js is committed on purpose: an install from a registry or a git URL does
no build, so the assembled bundle has to be present. Edit src/, rebuild, and
--check will tell you if you forget.
More
- Implementation notes
— the parsing, the linking rules and the bundle layout. None of it is needed to
install or use the plugin.
Licence
MIT — see LICENSE.
