القائمة
Core BDD concepts, philosophy, and the Three Amigos practice
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when kotlin coroutines for structured concurrency including suspend functions, coroutine builders, Flow, channels, and patterns for building efficient asynchronous code with cancellation and exception handling.
Use when building modular Angular applications requiring dependency injection with providers, injectors, and services.
Use when handling async operations in Angular applications with observables, operators, and subjects.
Use when building Angular 16+ applications requiring fine-grained reactive state management and zone-less change detection.
Guides end-to-end feature development through 8 phases: discover requirements, explore codebase patterns, clarify ambiguities with the user, design architecture, implement with TDD, run multi-agent code review, validate all quality gates, and write a blog post. Use when asked to add a feature, implement a new capability, build functionality, or develop a feature end-to-end.
Use when creating or modifying Han plugins. Covers plugin structure, configuration, hooks, skills, and best practices.
| name | bdd-principles |
| user-invocable | false |
| description | Core BDD concepts, philosophy, and the Three Amigos practice |
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.