name: bdd-assistant
scope: partial
description: |
Guide developers through Behavior-Driven Development workflow.
Use when: writing BDD scenarios, using Gherkin syntax, Given-When-Then format, feature files, Three Amigos collaboration.
Keywords: BDD, behavior-driven, Given When Then, Gherkin, Cucumber, scenario, feature file, step definition, 行為驅動開發.

BDD Assistant

Language: English | 繁體中文

Version: 1.0.0
Last Updated: 2026-01-19
Applicability: Claude Code Skills

Purpose

This skill guides developers through the Behavior-Driven Development workflow, helping them:
- Conduct Discovery sessions to explore requirements
- Write effective Gherkin scenarios in Given-When-Then format
- Create reusable step definitions
- Integrate BDD with TDD for implementation
- Maintain living documentation

Quick Reference

BDD Workflow Checklist

┌─────────────────────────────────────────────────────────────────┐
│  🔍 DISCOVERY Phase                                              │
│  □ Stakeholders identified (Business, Dev, QA)                  │
│  □ User story discussed and understood                          │
│  □ Concrete examples collected (Example Mapping)                │
│  □ Edge cases identified                                        │
│  □ Questions answered or noted for follow-up                    │
├─────────────────────────────────────────────────────────────────┤
│  📝 FORMULATION Phase                                            │
│  □ Scenarios use correct Gherkin syntax                         │
│  □ Scenarios are declarative (WHAT, not HOW)                    │
│  □ Business language used (no technical jargon)                 │
│  □ Each scenario is independent and self-contained              │
│  □ Scenarios have 5-10 steps maximum                            │
│  □ Scenarios reviewed by stakeholders                           │
├─────────────────────────────────────────────────────────────────┤
│  ⚙️ AUTOMATION Phase                                             │
│  □ Step definitions created for all steps                       │
│  □ Step definitions are reusable                                │
│  □ Scenarios fail initially (RED)                               │
│  □ TDD used for unit-level implementations                      │
│  □ All scenarios pass (GREEN)                                   │
│  □ Code refactored and clean                                    │
└─────────────────────────────────────────────────────────────────┘

Gherkin Quick Reference

Declarative vs Imperative

# ❌ BAD - Imperative (too detailed, UI-focused)
Scenario: Login
  Given I navigate to "http://example.com/login"
  And I click on the username field
  And I type "[email protected]"
  And I click on the password field
  And I type "secret123"
  And I click the submit button
  Then I should see "Dashboard" in the page title

# ✅ GOOD - Declarative (behavior-focused)
Scenario: Successful login with valid credentials
  Given I am a registered user
  When I login with valid credentials
  Then I should see my dashboard

Three Amigos Quick Reference

Workflow Assistance

Discovery Phase Guidance

When exploring requirements:

1. Example Mapping
   🟡 User Story: "User can login" │ ├─ 🔵 Rule: "Users must be authenticated" │ ├─ 🟢 Example: Valid credentials → login success │ └─ 🟢 Example: Invalid credentials → error message │ ├─ 🔵 Rule: "Account lockout after failures" │ ├─ 🟢 Example: 3 failures → account locked │ └─ 🟢 Example: Locked account → cannot login │ └─ 🔴 Question: Password expiration policy?

2. Questions to Ask

3. What's the happy path?
4. What could go wrong?
5. What are the boundary conditions?
6. What's explicitly out of scope?

Formulation Phase Guidance

When writing scenarios:

1. Feature File Structure
   ```gherkin
   Feature: Feature name
   As a [role]
   I want [feature]
   So that [benefit]

   Background:
   Given common preconditions

   Scenario: Descriptive scenario name
   Given [initial context]
   When [action]
   Then [expected outcome]
   ```

2. Scenario Style Guidelines

3. One behavior per scenario
4. Use business language
5. Keep steps declarative
6. Aim for 5-10 steps maximum
7. Make scenarios independent

Automation Phase Guidance

When implementing:

1. Step Definition Best Practices
   ```typescript
   // ✅ Good: Reusable, parameterized
   Given('I have {int} items in my cart', (count) => { ... });

// ❌ Bad: Specific to one scenario
Given('I have 3 widgets in my cart', () => { ... });
```

1. BDD + TDD Integration
   BDD Scenario (feature level) │ └──▶ Step Definitions │ └──▶ TDD Cycle (unit level) 🔴 Write failing unit test 🟢 Implement minimal code 🔵 Refactor

Integration with Other Workflows

BDD + SDD

When working with Spec-Driven Development:

# Reference spec in feature file
# @spec SPEC-001
@SPEC-001
Feature: User Authentication
  Implements SPEC-001 user authentication requirements.

  @AC-1
  Scenario: Successful login
    # Acceptance Criterion 1 from SPEC-001
    ...

BDD + TDD

Scenario Level (BDD)           Unit Level (TDD)
─────────────────────          ─────────────────
Scenario: Checkout    ──────▶  test_calculate_total()
  Given cart items             test_apply_discount()
  When checkout                test_create_order()
  Then order created           test_send_email()

BDD + ATDD

ATDD: Acceptance Criteria (business sign-off)
  │
  └──▶ BDD: Feature Files (Gherkin scenarios)
         │
         └──▶ TDD: Unit Tests (implementation)

Configuration Detection

This skill supports project-specific configuration.

Detection Order

1. Check CONTRIBUTING.md for "Disabled Skills" section
2. If this skill is listed, it is disabled for this project
3. Check CONTRIBUTING.md for "BDD Standards" section
4. Check for existing .feature files in the codebase
5. If not found, default to standard BDD practices

First-Time Setup

If no configuration found and context is unclear:

1. Ask: "This project hasn't configured BDD preferences. Which BDD tool do you use?"
2. Cucumber (JavaScript/TypeScript)
3. Behave (Python)
4. SpecFlow (C#)

5. Other

6. After selection, suggest documenting in CONTRIBUTING.md:

## BDD Standards

### BDD Tool
- Cucumber.js

### Feature File Location
- `features/` directory

### Scenario Style
- Declarative (behavior-focused)
- Business language required
- Max 10 steps per scenario

Detailed Guidelines

For complete standards, see:
- BDD Core Standard
- BDD Workflow Guide
- Gherkin Quick Reference

For related standards:
- TDD Standards
- ATDD Standards
- Testing Standards

Anti-Patterns Quick Detection

Related Standards

• Behavior-Driven Development - Core BDD standard
• Acceptance Test-Driven Development - ATDD standard
• Test-Driven Development - TDD standard
• Spec-Driven Development - SDD workflow
• Testing Standards - Testing framework
• TDD Assistant - TDD skill

Version History

License

This skill is released under CC BY 4.0.

Source: universal-dev-standards