BMAD Sprint Board
A DSH Harness plugin that reads a
BMAD project and shows it in the
Session sidebar: what is being worked on, what disagrees with the tracking file,
and what to do next.
Read-only. It never writes to your sprint files. Every action it offers is a
string you copy — a command when the board knows what to do, a prompt when it
only knows what to ask.
Requirements │ BMAD Sprint board │ Chat
─────────────────────────────────────────
Status Epic Requirements Specs
stories ████████░░ 12 / 15 80%
requirements ███████░░░ 11 / 17 65%
⚠ 23 of 40 unmapped
NEXT bmad-build Storefront Header Navigation Tools Integration
it is the next unstarted story [Ask agent · prompt]
● DONE (12) ● GAPS (4) ● COULD NOT CHECK (1) ● BACKLOG (3)
What you get
Four views, one tab
| View | Shows |
|---|
| Status | One foldable lane per story status, in board order, with the gaps board below |
| Epic | One section per epic: its status, retrospective state, and progress |
| Requirements | Every declared requirement by class, each with the state its evidence supports |
| Specs | The spec files no story in the sprint file claims |
Requirements and specs are readings of the same artefacts, so they are views of
the same tab rather than tabs of their own.
The requirements lane is the one worth knowing about, because it has four
states rather than two:
| Mark | State | Meaning |
|---|
✓ | done | verifiable, and verified |
◑ | partial | some covering epic is finished |
✗ | not started | verifiable, and nothing has begun |
○ | no evidence | nothing can say either way |
○ is the point. A requirement with no coverage map and no story citing it is
not "not done" — the board cannot tell, and says so rather than guessing.
The gaps board
The board is a check on the tracking file, not a mirror of it.
| Detector | Fires when |
|---|
| B1 done but owing | a story is done while deferred entries still name its spec |
| B3 review patches never applied | a story is done with unticked [Review][Patch] items |
| U1 UX run not carried into the plan | a UX design run the epics document never names |
| U2 UX requirement no epic delivers | a UX requirement whose components no story mentions |
| REQ | requirements the inventory declares that no coverage map claims |
Alongside them: two sparse progress bars side by side — stories against
requirements, because the distance between them is the finding — and one next
action, chosen from BMAD's own ladder rather than invented. A board that offers
three next actions has not answered.
Unverifiable is a state, never a silence. A check that cannot be evaluated
reports itself, and the bar's denominator never shrinks — so the board cannot
improve its score by going blind.
Keyboard
primary+S on desktop, primary+alt+S on the web, opening in whichever sidebar
pane you are already in. web:linux declares no default on purpose: the Harness
admits only three chords product-wide there, so every shipped tab command omits
it rather than squat on one.
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" })
Category
UI & Experience. It adds a sidebar tab and reads. It contributes no tool, no
model and no service, and it writes nothing.
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.
Extending
The plugin is two layers, and only the second knows about DSH:
| What | Where |
|---|
| What the board reads and computes | src/core.js, src/detect.js, src/plan.js, src/ux.js, src/requirements.js — pure, no DSH, no DOM |
| How it renders | src/shell-*.js — CSS, components, slot registration |
Adding a view is one entry in the VIEWS 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 line in detect().
src/detect.test.js shows the shape: the fixtures there prove a detector fires,
while the live-workspace tests only prove it agrees with the repository. Those
are different jobs, and keeping them apart is what stops a sprint in progress
from breaking the suite.
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 — what every section renders
from, how paths and folds resolve, the parsing, the bundle layout. None of it is
needed to install or use the plugin.
Licence
MIT — see LICENSE.
