メニュー
Use before writing any Gherkin scenario, when business rules need to be explored and edge cases discovered through collaborative example mapping
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| 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
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.