The .feature file is the spec, the backlog, and the contract.
Extreme-BDD treats BDD scenarios as the single source of truth. Radicle issues become the collaboration surface, the local board reads your working tree directly, and your seed replicates the whole loop. No external tracker, no parallel backlog, no central server.
What you get
Spec = backlog
Every backlog item is a @pending scenario in a .feature file with a priority tag and an As a <Profile> actor.
Board reads working tree
The local board UI parses your bdd/features/*.feature directly. No commit required to see the backlog.
Issues mirror the spec
A sync script opens or edits Radicle issues for each pending scenario and writes the scenario → issue map locally.
Sovereign hosting
Replicate via your own Radicle seed. The board, the docs, and this site can all live on a single droplet you control.
The whole loop in one block
Why “extreme”?
The name is inherited from Extreme Programming’s bias toward short feedback loops and working software. The Agile Manifesto puts working software over comprehensive documentation, and XP made testing, test-first development, ten-minute builds, and continuous integration part of the method. Extreme-BDD applies that instinct to the backlog: the spec, the card, and the acceptance test are one file instead of three.
There’s no separate ticket system to drift away from the spec.
There’s no spec doc to drift away from the tickets. Every change is
one commit to one .feature file. Radicle ships that
commit to everyone on the team. No forge in the middle.
Why BDD?
Behaviour-Driven Development gives that file its shape. Dan North introduced BDD as a shift from talking about tests to talking about behaviour, then described a story’s behaviour as acceptance criteria captured in scenarios: Given context, When something happens, Then outcomes must hold. Cucumber’s BDD docs make the same practical point: good examples become documentation that can be checked automatically against the system’s behaviour.
That is why Extreme-BDD uses .feature files as the
backlog primitive. A scenario is readable enough for planning,
specific enough for a board card, and executable enough to prove when
the work is really Done.
Sources:
Agile Manifesto,
Agile Alliance on XP,
Dan North on BDD,
Cucumber on BDD.
▶ Watch the workflow video
Two minutes. One scenario travels from Alice's editor to Done on canonical main — spec, board, branch, sync, merge, accept. Every column transition shown live.
Prefer to read along? Full demo page.
▶ Watch a patch find its own audience
Ninety seconds. Alice ships a security fix that breaks Bob’s code. Bob fixes it on his own branch — tests passing — and gossips it via Radicle. Tom finds Bob’s work and adopts it. Alice eventually does too. They never meet. No central forge in the loop.
The editorial punch is scene 7: Tom’s board surfaces Bob’s branch as a ghost card — passing tests, Bob’s DID as creator — before Alice has agreed to anything.
radicle-priorities) and dogfoods the protocol — the
entire backlog of the project is in bdd/features/, the
board UI is in web/, and the Radicle issues mirror is in
scripts/sync_bdd_issues.py.
To get added to the allowlist, email
info@bitlemmas.com.