Skill

behavior-driven-development

Applies BDD with Gherkin scenarios and TDD Red-Green-Refactor to implement features, fix bugs, and write executable specs/tests before production code.

testing

code-quality

npx claudepluginhub fradser/dotclaude --plugin superpowers

Tool Access

This skill uses the workspace's default tool permissions.

Preview

This skill provides a comprehensive guide to applying Behavior-Driven Development principles to your coding tasks. BDD is not just about tools; it's a methodology for shared understanding and high-quality implementation.

Supporting Assets

references/bdd-best-practices.mdreferences/gherkin-guide.md

SKILL.md

Similar Skills

bdd

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.

3 files4 tools

universal-dev-standards

bdd-patterns

129

Provides BDD patterns using Given-When-Then, Gherkin feature files, scenario outlines, and step definitions for business-readable tests and specifications.

2 tools

bdd

Test-Driven Development (TDD)

Enforces strict test-driven development for new features, bug fixes, and refactoring, requiring failing tests before any production code.

codagent

Stats

Parent Repo Stars512

Parent Repo Forks39

Last CommitMar 4, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Behavior-Driven Development (BDD) Skill

How to Use This Skill

When the user asks for a feature, bug fix, or refactor, apply the following mindset:

Understand Behavior First: Do not start coding until you know what the system should do.
Define Scenarios: Create or ask for concrete examples (Gherkin) of the expected behavior.
Drive Implementation with Tests: Use the Red-Green-Refactor cycle.

Core Concepts

1. The BDD Cycle

The process flows from requirements to code:

Discovery: Clarify requirements through examples (The "Three Amigos").
Formulation: Write these examples as specific scenarios (Given/When/Then).
Automation: Implement using TDD.

See BDD Best Practices for a detailed guide.

2. Writing Scenarios (Gherkin)

Scenarios are your "Executable Specifications".

Keep them declarative (business focus).
Avoid technical jargon and UI details.
One behavior per scenario.
Store in .feature files, NOT as code comments - this makes them executable and accessible to non-technical stakeholders.

See Cucumber Gherkin Guide for syntax and storage structure.

3. Red-Green-Refactor (TDD)

The engine of implementation:

RED: Write a failing test for the scenario (or a unit thereof).
GREEN: Write the minimal code to pass the test.
REFACTOR: Clean up the code while keeping tests passing.

Quick Reference: The Iron Law

"No production code is written without a failing test first."

If you write code before the test:

You don't know if the test is capable of failing (false positives).
You are biased by your implementation.
You are writing legacy code from day one.