bdd
v1.0.3Convert specs to Gherkin scenarios, scaffold step definitions, and verify acceptance test coverage.
<nav class="site-nav" aria-label="Primary">
<a href="#why">Why</a>
<a href="#how-it-works">How it works</a>
<a href="#getting-started">Getting Started</a>
</nav>
<div class="header-actions">
<a class="btn btn-ghost" href="https://github.com/RSginer/spec-kit-bdd" target="_blank" rel="noopener">
<svg viewBox="0 0 16 16" width="16" height="16" aria-hidden="true"><path fill="currentColor" d="M8 0C3.58 0 0 3.58 0 8c0 3.54 2.29 6.53 5.47 7.59.4.07.55-.17.55-.38 0-.19-.01-.82-.01-1.49-2.01.37-2.53-.49-2.69-.94-.09-.23-.48-.94-.82-1.13-.28-.15-.68-.52-.01-.53.63-.01 1.08.58 1.23.82.72 1.21 1.87.87 2.33.66.07-.52.28-.87.51-1.07-1.78-.2-3.64-.89-3.64-3.95 0-.87.31-1.59.82-2.15-.08-.2-.36-1.02.08-2.12 0 0 .67-.21 2.2.82.64-.18 1.32-.27 2-.27.68 0 1.36.09 2 .27 1.53-1.04 2.2-.82 2.2-.82.44 1.1.16 1.92.08 2.12.51.56.82 1.27.82 2.15 0 3.07-1.87 3.75-3.65 3.95.29.25.54.73.54 1.48 0 1.07-.01 1.93-.01 2.2 0 .21.15.46.55.38A8.01 8.01 0 0 0 16 8c0-4.42-3.58-8-8-8Z"/></svg>
GitHub
</a>
<button id="theme-toggle" class="theme-toggle" type="button" aria-label="Toggle color theme">
<svg class="icon-sun" viewBox="0 0 24 24" width="18" height="18" aria-hidden="true"><circle cx="12" cy="12" r="4" fill="none" stroke="currentColor" stroke-width="2"/><g stroke="currentColor" stroke-width="2" stroke-linecap="round"><path d="M12 2v2M12 20v2M4.22 4.22l1.42 1.42M18.36 18.36l1.42 1.42M2 12h2M20 12h2M4.22 19.78l1.42-1.42M18.36 5.64l1.42-1.42"/></g></svg>
<svg class="icon-moon" viewBox="0 0 24 24" width="18" height="18" aria-hidden="true"><path fill="currentColor" d="M21 12.79A9 9 0 1 1 11.21 3 7 7 0 0 0 21 12.79Z"/></svg>
</button>
</div>
</div>
spec-kit-bdd
A spec-kit community extension that adds Behavior-Driven Development and Acceptance Test-Driven Development to the spec-driven workflow — acceptance criteria become executable scenarios before implementation starts.
Build quality in, don't inspect it in afterward
Lean software development treats anything that doesn't directly deliver value to the user as waste — rework from misread requirements, code built against specs nobody validated, defects caught late instead of early. That's the core teaching behind Lean Software Development: An Agile Toolkit: build quality into the process instead of inspecting for it afterward.
spec-kit-bdd applies that here. Acceptance criteria become executable Gherkin scenarios before implementation starts, and step definitions fail (RED) until the code they describe actually satisfies them (GREEN). Ambiguity in a spec surfaces as a failing scenario before any code is written — instead of as a bug report or a misaligned feature after the fact.
How this differs from writing tests the usual way
Compared to hand-rolled Cucumber/Behave/SpecFlow, or spec-kit without BDD at all.
Traceability by default
Scenarios are generated automatically from your spec-kit specification and verified by /speckit.bdd.verify — no hand-maintained mapping between spec and tests.
Tests exist before code
/speckit.bdd.scaffold runs before implementation as part of the spec-kit lifecycle itself — not whenever the team gets around to it.
Zero new runtime
A YAML manifest and Markdown prompt files. No new framework to install and configure per language, unlike a standalone Cucumber/Behave/SpecFlow setup.
See docs →Coverage gaps surface automatically
Gaps show up in features/TRACEABILITY.md, generated for you — instead of relying on manual auditing or no mechanism at all.
Spec → scenarios → tests → code
The full spec-kit lifecycle, with three commands slotted in so tests exist before code.
<div class="flow">
<div class="flow-step flow-step--purple">
<span class="flow-num">1. SPEC</span>
<p>Describe the behaviour with <code>/speckit.specify</code>.</p>
</div>
<div class="flow-arrow" aria-hidden="true">→</div>
<div class="flow-step flow-step--green">
<span class="flow-num">2. BDD (Gherkin)</span>
<p>Specify examples with <code>/speckit.bdd.scenarios</code> — RED.</p>
</div>
<div class="flow-arrow" aria-hidden="true">→</div>
<div class="flow-step flow-step--blue">
<span class="flow-num">3. ATDD</span>
<p>Scaffold failing steps with <code>/speckit.bdd.scaffold</code> — still RED.</p>
</div>
<div class="flow-arrow" aria-hidden="true">→</div>
<div class="flow-step flow-step--muted">
<span class="flow-num">4. PLAN</span>
<p>Standard spec-kit: <code>/speckit.plan</code> then <code>/speckit.tasks</code>.</p>
</div>
<div class="flow-arrow" aria-hidden="true">→</div>
<div class="flow-step flow-step--orange">
<span class="flow-num">5. CODE</span>
<p>Implement with <code>/speckit.implement</code> until GREEN.</p>
</div>
<div class="flow-arrow" aria-hidden="true">→</div>
<div class="flow-step flow-step--purple">
<span class="flow-num">6. VERIFY</span>
<p>Close the loop with <code>/speckit.bdd.verify</code>.</p>
</div>
</div>
<p class="flow-legend"><span class="dot" aria-hidden="true"></span>Steps 2, 3, and 6 are what spec-kit-bdd adds to your normal spec-kit flow.</p>
<table class="produces-table">
<thead>
<tr><th>Command</th><th>What it produces</th></tr>
</thead>
<tbody>
<tr><td><code>/speckit.bdd.scenarios</code></td><td>Gherkin <code>.feature</code> files from your spec-kit specification</td></tr>
<tr><td><code>/speckit.bdd.scaffold</code></td><td>Step definition stubs (Python, JS, Ruby, Java, C#) ready to implement</td></tr>
<tr><td><code>/speckit.bdd.verify</code></td><td>A traceability matrix mapping spec requirements ↔ scenarios</td></tr>
</tbody>
</table>
From spec to green tests
<div class="install-block">
<p>Install the extension into an existing spec-kit project:</p>
<pre><code>specify extension add bdd --from https://github.com/RSginer/spec-kit-bdd/archive/refs/tags/v1.0.3.zip</code></pre>
<p>That adds six commands to spec-kit's own lifecycle. Here's the full workflow, spec to green tests:</p>
</div>
<div class="steps">
<div class="step">
<h3>Write what you want to build</h3>
<p>Start a spec-kit feature the usual way — nothing BDD-specific yet.</p>
<pre><code>/speckit.specify</code></pre>
</div>
<div class="step">
<h3>Convert acceptance criteria to Gherkin</h3>
<p>Generates <code>features/*.feature</code> files from the spec you just wrote. Tests are written — <strong>RED</strong>. Review them, they define what the system must do.</p>
<pre><code>/speckit.bdd.scenarios</code></pre>
</div>
<div class="step">
<h3>Scaffold step definitions</h3>
<p>Generates step definition stubs that raise <code>NotImplementedError</code> (or the framework equivalent). Tests are now runnable — still <strong>RED</strong>.</p>
<pre><code>/speckit.bdd.scaffold</code></pre>
</div>
<div class="step">
<h3>Plan the implementation</h3>
<p>Back to standard spec-kit: break the spec into an implementation plan and a task list, now informed by the scenarios above.</p>
<pre><code>/speckit.plan
/speckit.tasks
Implement until every scenario passes
Write code until your step definitions go GREEN.
/speckit.implement
Verify full spec coverage
Produces features/TRACEABILITY.md, mapping every spec requirement to the scenario that covers it, and flags any gaps.
/speckit.bdd.verify
What you need
- spec-kit
>=0.2.0 - Any AI coding agent supported by spec-kit (Claude, Copilot, Cursor, etc.)
Stats
Version
Install
Using the Specify CLI
specify extension add bdd --from https://github.com/RSginer/spec-kit-bdd/archive/refs/tags/v1.0.3.zip