behavior-driven-development
Behavior-Driven Development with Given-When-Then scenarios and acceptance criteria
What this skill does
# Behavior-Driven Development (BDD) Skill
## When to Use
Use this skill when:
- Defining acceptance criteria for features
- Creating executable specifications
- Translating requirements into testable scenarios
- Working with stakeholders on feature definitions
- Part of the unified workflow process
## Overview
BDD bridges the gap between business requirements and technical implementation using natural language scenarios that become executable tests.
## BDD Process
### 1. Discovery Phase
Work with stakeholders to discover scenarios:
**Ask:**
- What is the business value?
- Who are the users/actors?
- What are the main scenarios?
- What can go wrong?
- What edge cases exist?
### 2. Scenario Definition
Write scenarios in Given-When-Then format:
```gherkin
Feature: User Authentication
Scenario: Successful login with valid credentials
Given a registered user with email "[email protected]" and password "SecurePass123"
When the user submits the login form with correct credentials
Then the user should be redirected to the dashboard
And the user session should be created
And the user should see a welcome message
Scenario: Failed login with invalid password
Given a registered user with email "[email protected]"
When the user submits the login form with incorrect password
Then the user should see an error message "Invalid credentials"
And the user should remain on the login page
And no session should be created
Scenario: Account lockout after multiple failed attempts
Given a registered user with email "[email protected]"
And the user has failed to login 4 times
When the user submits the login form with incorrect password again
Then the account should be locked for 15 minutes
And the user should see "Account temporarily locked"
```
### 3. Examples and Data Tables
Use examples for multiple test cases:
```gherkin
Scenario Outline: Password validation
Given a user registration form
When the user enters password "<password>"
Then the validation should show "<result>"
Examples:
| password | result |
| abc | Too short (min 8 characters) |
| abcdefgh | Missing uppercase letter |
| Abcdefgh | Missing number |
| Abcdefg1 | Valid |
| Abc123!@# | Valid |
```
### 4. Acceptance Criteria Checklist
For each feature, create acceptance criteria:
```markdown
## Acceptance Criteria
- [ ] User can login with valid email and password
- [ ] Invalid credentials show appropriate error
- [ ] Account locks after 5 failed attempts
- [ ] Locked account shows lockout duration
- [ ] Session expires after 24 hours
- [ ] Logout clears session properly
- [ ] Remember me keeps session for 30 days
```
### 5. Integration with Workflow
**In Spec Phase:**
```
1. Define feature specification (SDD)
2. Write BDD scenarios (this skill)
3. Get stakeholder approval
```
**In Implementation Phase:**
```
1. For each scenario:
- Write step definitions (glue code)
- Implement steps using TDD
- Verify scenario passes
2. Ensure all acceptance criteria met
```
## BDD Scenario Structure
### Given (Context)
- Initial state
- Preconditions
- Setup data
- User context
### When (Action)
- User action
- System event
- API call
- Trigger
### Then (Outcome)
- Expected result
- State changes
- Side effects
- Assertions
### And/But (Additional steps)
- Multiple givens, whens, or thens
- Additional context or assertions
## Best Practices
**DO:**
- Write from user's perspective
- Use business language, not technical jargon
- Focus on behavior, not implementation
- Keep scenarios independent
- Use concrete examples
- Cover happy path and edge cases
**DON'T:**
- Include implementation details
- Make scenarios too long (>5-7 steps)
- Create dependencies between scenarios
- Use vague language
- Test technical details (use unit tests)
## Tools Integration
**Gherkin/Cucumber:**
```bash
# Feature files in features/ directory
features/
├── authentication.feature
├── user_profile.feature
└── payment.feature
```
**Jest/Vitest:**
```javascript
describe('User Authentication', () => {
it('should login with valid credentials', () => {
// Given
const user = createUser({ email: '[email protected]', password: 'SecurePass123' });
// When
const result = login(user.email, 'SecurePass123');
// Then
expect(result.success).toBe(true);
expect(result.redirectTo).toBe('/dashboard');
});
});
```
**Playwright/Cypress:**
```javascript
test('User can login successfully', async ({ page }) => {
// Given
await page.goto('/login');
// When
await page.fill('[name="email"]', '[email protected]');
await page.fill('[name="password"]', 'SecurePass123');
await page.click('button[type="submit"]');
// Then
await expect(page).toHaveURL('/dashboard');
await expect(page.locator('.welcome')).toBeVisible();
});
```
## Example Workflow Integration
```bash
# 1. Start workflow
/workflow:start-development-workflow "Add user authentication"
# 2. Create spec (SDD)
/workflow:create-workflow-spec
→ Creates OpenAPI spec for auth endpoints
# 3. Define behaviors (BDD)
/workflow:behavior-driven
→ Creates authentication.feature with scenarios
# 4. Get approval
→ Review spec + scenarios with stakeholders
# 5. Implement (TDD)
/workflow:implement
→ For each scenario:
- Write failing test (RED)
- Implement (GREEN)
- Refactor (REFACTOR)
# 6. Verify
→ All scenarios pass
→ Acceptance criteria met
```
## Output Format
**BDD Scenarios File:**
```
Save to: features/<feature-name>.feature
Or: docs/bdd/<feature-name>.md
Include:
- Feature description
- User stories
- Scenarios (Given-When-Then)
- Examples/data tables
- Acceptance criteria checklist
```
## Error Handling
- **Ambiguous scenarios:** Ask for clarification
- **Too technical:** Refactor to business language
- **Missing edge cases:** Suggest additional scenarios
- **Conflicting requirements:** Flag for stakeholder review
## Integration Points
- **SDD (spec-driven):** Specs define what, BDD defines how users interact
- **TDD (test-driven):** BDD scenarios become test suites
- **Task Management:** Each scenario can become a task
- **Documentation:** Scenarios serve as living documentation
Related in General
modeling-omnistudio-epc-catalog
IncludedSalesforce Industries CME EPC product-modeling skill for Product2-based catalog creation. Use when creating EPC products, configuring product attributes, building offer bundles with Product Child Items, or reviewing EPC DataPack JSON metadata for product catalog changes. TRIGGER when: user creates or updates Product2 EPC records, AttributeAssignment payloads, AttributeMetadata/AttributeDefaultValues, Offer bundles, or ProductChildItem relationships. DO NOT TRIGGER when: designing OmniScripts/FlexCards/Integration Procedures (use building-omnistudio-omniscript, building-omnistudio-flexcard, or building-omnistudio-integration-procedure), implementing Apex business logic (use generating-apex), or troubleshooting deployment pipelines (use deploying-metadata).
relationship-science-coach
IncludedUse this skill for direct, practical adult relationship coaching: couples conflict, repair, trust, marriage, dating, flirting, attachment patterns, emotional connection, sex, desire differences, eroticism, kink negotiation, affection, love languages, breakups, and long-term passion. Draw on Gottman, EFT and Hold Me Tight, attachment science, modern sex research, Perel, Nagoski, Kerner, Schnarch, Love and Stosny, and flexible love-language tools. Be concrete and low-hedge. Redirect only for imminent danger, abuse, coercive control, minors, non-consent, self-harm, stalking, or medical/legal/psychiatric decisions.
building-sf-integrations
IncludedSalesforce integration architecture and runtime plumbing with 120-point scoring. Use this skill to set up Named Credentials, External Credentials, External Services, REST/SOAP callout patterns, Platform Events, and Change Data Capture. TRIGGER when: user sets up Named Credentials, External Services, REST/SOAP callouts, Platform Events, CDC, or touches .namedCredential-meta.xml files. DO NOT TRIGGER when: Connected App/OAuth config (use configuring-connected-apps), Apex-only logic (use generating-apex), or data import/export (use handling-sf-data).
venue-templates
IncludedAccess comprehensive LaTeX templates, formatting requirements, and submission guidelines for major scientific publication venues (Nature, Science, PLOS, IEEE, ACM), academic conferences (NeurIPS, ICML, CVPR, CHI), research posters, and grant proposals (NSF, NIH, DOE, DARPA). This skill should be used when preparing manuscripts for journal submission, conference papers, research posters, or grant proposals and need venue-specific formatting requirements and templates.
let-fate-decide
IncludedDraws the 12 Houses of the Zodiac Tarot spread to inject entropy into planning when prompts are vague, ambiguous, or casually delegated. Interprets the spread to guide next steps. Use when the user says 'let fate decide', 'YOLO', 'whatever', 'idk', or other nonchalant phrases, makes Yu-Gi-Oh references, or when you are about to arbitrarily pick between multiple reasonable approaches. Prefer over ask-questions-if-underspecified when the user's tone is casual or playful rather than precision-seeking.
net-ops
IncludedCross-platform network troubleshooting (Windows, macOS, Linux) via local or remote shell. Use for: DNS broken, can't resolve hostnames, nslookup/dig works but apps fail, NRPT, WFP, scutil, /etc/resolver, systemd-resolved, /etc/resolv.conf, NetworkManager, VPN DNS leak residue (ProtonVPN/Mullvad/WireGuard/AnyConnect), AV/firewall blocking DNS or DoH, Tailscale DNS interaction, intermittent connectivity, remote diagnostics over SSH.