メニュー
Use before writing any Gherkin scenario, when business rules need to be explored and edge cases discovered through collaborative example mapping
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SOC 職業分類に基づく
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/SebastienDegodez/meetup-coding-with-ai --skill discovering-bdd-scenariosコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
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.
| name | discovering-bdd-scenarios |
| description | Use before writing any Gherkin scenario, when business rules need to be explored and edge cases discovered through collaborative example mapping |
Discover "what we don't know we don't know" before writing scenarios. Use Example Mapping to surface business rules, edge cases, and open questions through concrete examples.
Core principle: If you're not exploring concrete examples, you're not doing BDD. Rules without examples hide assumptions.
Map each user story with four card types before writing Gherkin:
| Card | Color | Content |
|---|---|---|
| User Story | Yellow | One story per session |
| Business Rule | Blue | "Age must be ≥18 for vehicles" |
| Concrete Example | Green | "16yo requesting car → refused" |
| Open Question | Red | Blockers — never proceed with unresolved reds |
[Yellow] Story: Insurance subscription eligibility
|
+-- [Blue] Rule: Must be 18+ for car/motorcycle
| +-- [Green] 17yo requesting car → refused
| +-- [Green] 18yo requesting car → accepted ← boundary
| +-- [Red] Exactly 18yo: accepted or refused?
|
+-- [Blue] Rule: Electric vehicles allowed at 16+
+-- [Green] 16yo e-scooter → accepted
+-- [Green] 15yo e-scooter → refused ← boundary
+-- [Red] Electric motorcycle: follows age 16 or age 18 rule?
Per rule: create 2-3 Green cards — happy path | boundary | error path.
Explore each rule from three angles to find blindspots:
| Role | Questions to ask |
|---|---|
| Problem Owner (PO/BA) | What is the business intent? What are the acceptance criteria? |
| Problem Solver (Dev) | What are the technical constraints? What edge cases exist? |
| Skeptic (QA/Tester) | What failure modes exist? What assumptions are we making? |
Template: "Is there any other context which, when this event happens, produces a different outcome?"
BA: "When a driver requests eligibility, the request is accepted or refused."
Dev: "What if no vehicle type is specified?"
QA: "What if the birthdate is in the future?"
BA: "What if the driver has no license information?"
→ Three new Red cards discovered.
Before moving to Gherkin, verify:
REQUIRED: designing-bdd-scenarios — structure the discovered examples as Gherkin