// Use when writing or improving Gherkin .feature files, after business rules and examples have been discovered
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.
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 when designing test coverage matrices, assigning tests to Clean Architecture layers, planning the outside-in implementation order, or applying the Walking Skeleton strategy. Ensures every behaviour is tested at the right level with no redundancy. Load after writing Gherkin scenarios.
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 DISCOVER artefacts (triage reports, sprint proposals) for completeness, prioritization quality, and duplicate handling. Contains gate definitions G1-G6 and scoring rubric for the backlog-discoverer-reviewer lenses.
Install the full eleven-workflow skraft SDLC pipeline (discover → discuss → design → distill → deliver, each with an automated reviewer) into the current repo in one pass. Use when the user wants an end-to-end agent pipeline driven by a single issue label, or types /install-skraft-pipeline.
| 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