Menu
Use when writing or improving Gherkin .feature files, after business rules and examples have been discovered
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when running mutation testing, killing mutants, verifying test quality, checking mutation score, or analyzing survivors after the test baseline is green
Use when selecting architecture patterns for a new feature, performing Event Modeling, defining bounded contexts, choosing DDD tactical patterns, evaluating pattern fitness, or understanding how patterns compose. Covers Event Modeling methodology, DDD strategic design, DDD tactical patterns, Clean Architecture, CQRS, and Event Sourcing.
Use when reviewing DESIGN artefacts (event models, ADRs, component diagrams, context maps, interface contracts) for quality, DDD compliance, architectural correctness, and prohibition of negative or baseline-restating ADRs. Contains gate definitions and scoring rubric for the solution-architect-reviewer lenses.
Use whenever an agent must run a toolchain command (build, test, mutation) and needs the concrete invocation. Resolves build/test/mutation commands from the detected stack so no agent hardcodes `dotnet test`, `dotnet build`, or any toolchain command. Loaded by acceptance-designer and software-engineer.
Use this skill BEFORE drafting any agentic primitive module (skill, persona scoping file, scope-attached rule file, orchestrator workflow) or when refactoring an existing one. Activate whenever the task asks to design, restructure, or critique an agentic module across any agent harness (Claude Code, Copilot, Cursor, OpenCode, Codex). This skill drives an 8-step disciplined design process whose output is mermaid diagrams + an interface sketch + a persisted plan that the calling thread (or a coder persona it loads) then turns into natural-language modules. Do not skip to natural-language drafting before the design artifacts exist.
Use when documenting architecture decisions as ADRs, evaluating trade-offs between alternatives, or managing the lifecycle of existing decisions. Covers ADR template, status transitions, consequence analysis, and quality criteria.
| name | designing-bdd-scenarios |
| description | Use when writing or improving Gherkin .feature files, after business rules and examples have been discovered |
Structure discovered examples as executable Gherkin. Covers Background, Scenario Outline + Examples, and scenario writing rules.
Prerequisite: discovering-bdd-scenarios — rules and examples must be known before structuring.
Core principle: Representative selection over exhaustive enumeration.
| Rule | Check |
|---|---|
| One scenario, one behavior | Split multi-behavior scenarios |
| Declarative, not imperative | Business outcomes, not UI/API/HTTP details |
| Concrete examples | Specific values ("$500", "17 ans"), not abstractions |
| Short (3-5 steps) | Longer = testing multiple behaviors |
| Background for shared Given | Factorize repeated preconditions only |
Scenarios describe external observables only:
| ❌ Forbidden | ✅ Allowed |
|---|---|
| Class names, method names | Business actions and actors |
| HTTP endpoints, status codes | Business outcomes |
| Repository, database tables | Data in business terms |
| ❌ BAD (implementation) | ✅ GOOD (business outcome) |
|---|---|
POST /api/eligibility returns 200 | Eligibility request is accepted |
EligibilityHandler returns rejected | Driver is refused for being too young |
Contexte:
Étant donné nous sommes le "01/01/2026"
Only Given steps. Never When/Then.
Plan du Scénario: Vérification de l'âge minimum
Étant donné un conducteur âgé de <age> ans
Et le véhicule est une "<vehicule>"
Quand je demande une éligibilité
Alors la demande est <resultat>
Exemples: Conducteurs refusés
| age | vehicule | resultat |
| 17 | Voiture | refusée avec le motif "Conducteur trop jeune pour ce véhicule" |
Exemples: Conducteurs acceptés
| age | vehicule | resultat |
| 18 | Voiture | acceptée |
Group Examples by intent (accepted vs rejected), not by data shape.
Use outlines for boundary conditions. Avoid when scenarios diverge structurally.
Use when Given steps are unique and not shared with other scenarios.
Per business rule, target 3-4 cases (not 10+):
| Type | Count | Target |
|---|---|---|
| Happy path | 1 | Most common success |
| Key alternatives | 1-2 | Boundary values, rejections |
| Error path | 1+ | Target 40%+ of total scenarios |
For each threshold, test both sides:
| Rule | Below boundary | At boundary | Above boundary |
|---|---|---|---|
| Age ≥18 | 17 (rejected) | 18 (accepted) | — |
| Power >100ch | 100 (accepted) | — | 101 (rejected) |
Clarify the operator (≥ vs >) before writing scenarios.
| Mistake | Fix |
|---|---|
| Exhaustive enumeration (20+ scenarios) | Select representative examples per rule |
| No Background | Factorize shared Given steps |
| Individual scenarios for boundary variations | Use Scenario Outline + Examples |
| Only rejection scenarios, no acceptance | Include Golden Path per rule |
| Boundary operator ambiguous | Clarify with boundary pair (100ch OK, 101ch KO) |
| Implementation details in titles or steps | Business language only — spec-leakage rule |
| Proceeding without explicit approval | Present scenarios, wait for explicit validation |
REQUIRED: discovering-bdd-scenarios — run first to discover rules and examples
PAIRS WITH: outside-in-tdd — scenarios feed acceptance tests
PAIRS WITH: red-synthesize-green — TDD cycle after approval