npx claudepluginhub thebushidocollective/han --plugin bddThis skill uses the workspace's default tool permissions.
Master the foundational principles and philosophy of Behavior-Driven Development.
Guides BDD collaboration with Three Amigos sessions, example mapping, discovery workshops, ubiquitous language, and Gherkin living documentation for devs, testers, stakeholders.
Guides through Behavior-Driven Development (BDD) workflow using Gherkin Given-When-Then scenarios, Three Amigos discussions, and 4-phase cycle from discovery to living docs. Invoke via /bdd for features or files.
Applies BDD with Gherkin scenarios and TDD Red-Green-Refactor to implement features, fix bugs, and write executable specs/tests before production code.
Share bugs, ideas, or general feedback.
Master the foundational principles and philosophy of Behavior-Driven Development.
Behavior-Driven Development (BDD) is a collaborative software development approach that:
Discovery: Collaborate to understand requirements
Development: Implement guided by examples
Delivery: Validate against real behavior
A practice where three perspectives collaborate to explore and define features:
Feature: Password Reset
Business: "Users who forget their password need a way to reset it via email."
Developer: "We'll need to generate secure tokens with expiration. How long should tokens be valid?"
Tester: "What happens if they request multiple reset emails? Can old tokens still be used?"
Business: "Tokens should be valid for 1 hour. Multiple requests should invalidate old tokens."
Developer: "Should we rate-limit reset requests to prevent abuse?"
Tester: "What if the email address doesn't exist in our system?"
Business: "For security, show the same success message whether or not the email exists."
Outcome: Concrete examples that become scenarios:
Scenario: Request password reset with valid email
Given a user account exists for "user@example.com"
When I request a password reset for "user@example.com"
Then I should receive a reset email
And the reset link should be valid for 1 hour
Scenario: Request password reset with non-existent email
When I request a password reset for "nonexistent@example.com"
Then I should see a success message
But no email should be sent
Scenario: Multiple password reset requests
Given I have requested a password reset
When I request another password reset
Then the previous reset link should be invalidated
And I should receive a new reset email
BDD scenarios serve as:
Feature: Promotional Discount Application
To attract customers and increase sales
As a marketing manager
I want to offer promotional discounts
Rule: Percentage discounts apply to order subtotal
Example: 20% off for orders over $100
Given I have a $150 order
When I apply a "20% off" promotion
Then my discount should be $30
And my order total should be $120
Rule: Minimum purchase amount must be met
Example: Promotion requires $50 minimum
Given I have a $40 order
When I try to apply a "$50 minimum" promotion
Then the promotion should not apply
And I should see "Minimum purchase not met"
Rule: Only one promotion per order
Example: Cannot stack multiple promotions
Given I have a $100 order
And I have applied "10% off"
When I try to apply "Free shipping"
Then I should see "One promotion per order"
And only "10% off" should be applied
Develop and use a shared vocabulary:
❌ Technical Jargon:
"When the user submits the form, we validate the input,
hash the password with bcrypt, insert a record into the
users table, and return a 201 response."
✅ Ubiquitous Language:
"When a customer registers, we verify their information,
create their account, and send a welcome email."
Discover terms through conversation:
Document terms in scenarios:
# Use "Member" not "User" (business term)
Given I am a Gold Member
# Use "Place order" not "Submit order" (domain term)
When I place an order
# Use "Pending" not "In progress" (system state)
Then the order should be Pending
Keep a glossary:
Member: A customer with a subscription
Guest: A customer without a subscription
Order: A collection of items ready for purchase
Cart: A temporary collection of items being considered
A workshop technique to explore features with examples:
Yellow Cards: User Stories/Features Blue Cards: Rules (acceptance criteria) Green Cards: Examples (scenarios) Red Cards: Questions (uncertainties)
Story: User registration
Rules (Blue):
Examples (Green):
Questions (Red):
Use concrete examples to drive development:
"Users should be able to search for products."
Scenario: Search by product name
Given products "Laptop", "Mouse", "Keyboard" exist
When I search for "lap"
Then I should see "Laptop" in results
But I should not see "Mouse" or "Keyboard"
Scenario: Search with no results
Given products "Laptop", "Mouse" exist
When I search for "phone"
Then I should see "No results found"
Scenario: Search is case-insensitive
Given a product "Laptop" exists
When I search for "LAPTOP"
Then I should see "Laptop" in results
Start from the outside (user-facing behavior) and work inward:
Scenario (Acceptance) ─┐
├─> Controller Test ─┐
│ ├─> Service Test ─┐
│ │ ├─> Code
│ │ │
│ ├─ Service │
│ │ │
├─ Controller │ │
│ │ │
Scenario Passes ───────┴────────────────────┴─────────────────┘
TDD (Test-Driven Development):
BDD (Behavior-Driven Development):
They complement each other:
❌ "BDD is just testing with Cucumber" ✅ BDD is a collaborative practice; tools are just enablers
❌ "BDD means writing tests before code" ✅ BDD means discovering requirements through examples before implementation
❌ "BDD scenarios should test everything" ✅ BDD scenarios should document key behaviors; use unit tests for details
❌ "Only testers write scenarios" ✅ Business, developers, and testers collaborate on scenarios
❌ "BDD slows down development" ✅ BDD reduces rework by building the right thing the first time
Remember: BDD is fundamentally about communication and collaboration. The goal is to build software that delivers real value by ensuring everyone has a shared understanding of what needs to be built.