Agent-Skills.md

Agent Skills: Behavior-Driven Development (BDD) Skill

Applies behavior-driven development principles including Gherkin scenarios and test-driven development. This skill should be used when the user asks to implement features, fix bugs, or when writing executable specifications and tests before writing production code.

UncategorizedID: fradser/dotclaude/behavior-driven-development

Repository

fradser/dotclaude
FradSer
52140

Install this agent skill to your local

pnpm dlx add-skill https://github.com/FradSer/dotclaude/tree/HEAD/superpowers/skills/behavior-driven-development

Skill Files

Browse the full folder contents for behavior-driven-development.

Download Skill

Loading file tree…

superpowers/skills/behavior-driven-development/SKILL.md

Skill Metadata

Name
behavior-driven-development
Description
Applies behavior-driven development principles including Gherkin scenarios and test-driven development. This skill should be used when the user asks to implement features, fix bugs, or when writing executable specifications and tests before writing production code.

Behavior-Driven Development (BDD) Skill

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.

How to Use This Skill

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

  1. Understand Behavior First: Do not start coding until you know what the system should do.
  2. Define Scenarios: Create or ask for concrete examples (Gherkin) of the expected behavior.
  3. 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:

  1. RED: Write a failing test for the scenario (or a unit thereof).
  2. GREEN: Write the minimal code to pass the test.
  3. 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:

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