| name | event-storming |
| description | AI-simulated event storming workshop with multi-persona support. Use when discovering domain events, commands, actors, and bounded contexts. Supports three modes - full-simulation (5 persona agents debate), quick (single-pass analysis), and guided (interactive with user). Orchestrates persona agents and synthesizes results. |
| allowed-tools | Read, Write, Glob, Grep, Skill, Task |
Event Storming
When to Use This Skill
Use this skill when you need to:
- Discover domain events for a business process
- Identify commands and actors in a system
- Find bounded context boundaries
- Simulate a multi-stakeholder event storming workshop
- Prepare for actual event storming facilitation
- Analyze an existing codebase for domain events
Keywords: event storming, domain events, commands, actors, bounded contexts, aggregates, domain discovery, workshop simulation, multi-persona, DDD
What is Event Storming?
Event Storming is a workshop-based method for collaborative domain discovery. Participants use sticky notes to map out:
- Events (Orange) - Things that happen in the domain
- Commands (Blue) - Actions that trigger events
- Actors (Yellow) - Who issues commands
- Aggregates (Yellow) - Business entities that handle commands
- Read Models (Green) - Information needed for decisions
- Policies (Purple) - Business rules and reactions
- External Systems (Pink) - Outside integrations
- Hot Spots (Red/Pink) - Areas of confusion or conflict
Workshop Modes
This skill supports three modes of operation:
| Mode | Description | Token Cost | Use Case |
|---|---|---|---|
full-simulation |
All 5 personas debate in parallel, 6 phases | ~15K tokens | Comprehensive discovery |
quick |
Single analysis pass, no personas | ~3K tokens | Quick domain overview |
guided |
Interactive with user, personas on-demand | Variable | User wants control |
Mode Selection Guide
Use full-simulation when:
- Starting a new project or major feature
- You need comprehensive domain discovery
- Multiple perspectives are valuable
- Time is less critical than thoroughness
Use quick when:
- You need a fast domain overview
- Token budget is constrained
- Domain is relatively simple
- You'll refine later
Use guided when:
- You want to drive the process
- You have specific questions
- You want to invoke specific personas
- Interactive exploration is preferred
Multi-Persona Simulation
The full-simulation mode uses 5 specialized agents to simulate different stakeholder perspectives:
| Persona Agent | Role | Perspective | Contributions |
|---|---|---|---|
domain-expert |
Subject Matter Expert | Deep business knowledge | Domain events, business rules, edge cases |
developer-persona |
Technical Implementation | System constraints | Technical events, integration points |
business-analyst |
Process & Requirements | Process flow | Commands, actors, acceptance criteria |
product-owner |
Product Vision | User value | Priorities, MVP scope, user stories |
devils-advocate |
Challenger | Identify gaps | Hot spots, missing scenarios, contradictions |
6 Workshop Phases (Full Simulation)
Phase 1: Chaotic Exploration
All personas brainstorm events independently. No constraints, no ordering.
Orchestration:
Launch 5 parallel Task agents:
- Task(domain-expert, "Identify all domain events for: {domain}")
- Task(developer-persona, "Identify technical events for: {domain}")
- Task(business-analyst, "Identify commands and actors for: {domain}")
- Task(product-owner, "Prioritize and identify MVP scope for: {domain}")
- Task(devils-advocate, "Challenge and identify gaps for: {domain}")
Phase 2: Timeline Ordering
Synthesize and order events chronologically. Create the timeline.
Phase 3: Command Discovery
Identify what triggers each event. Map commands to events.
Phase 4: Actor Identification
Map who issues each command. Define roles and systems.
Phase 5: Bounded Context Discovery
Group related events/commands. Identify natural boundaries.
Phase 6: Hot Spot Resolution
Devil's advocate challenges. Resolve conflicts and gaps.
Detailed phase guidance: See references/workshop-facilitation.md
Sticky Note Color Convention
| Color | Represents | Example |
|---|---|---|
| 🟧 Orange | Domain Event | "Order Placed", "Payment Received" |
| 🟦 Blue | Command | "Place Order", "Process Payment" |
| 🟨 Yellow (small) | Actor | "Customer", "Admin", "System" |
| 🟨 Yellow (large) | Aggregate | "Order", "Customer", "Product" |
| 🟩 Green | Read Model | "Order Summary", "Product Catalog" |
| 🟪 Purple | Policy | "When order placed, reserve inventory" |
| 🟫 Pink | External System | "Payment Gateway", "Email Service" |
| ❗ Red/Pink | Hot Spot | Areas of confusion or conflict |
Detailed conventions: See references/sticky-note-types.md
Orchestration Pattern
Since Claude Code subagents cannot spawn other subagents, the main conversation orchestrates:
Main Conversation
↓
Invokes event-storming skill
↓
Skill guides parallel Task tool calls:
├── Task(domain-expert, prompt)
├── Task(developer-persona, prompt)
├── Task(business-analyst, prompt)
├── Task(product-owner, prompt)
└── Task(devils-advocate, prompt)
↓
Skill synthesizes results with provenance tracking
↓
Outputs event catalog with [persona] attribution
Quick Start
Full Simulation Mode
I want to run a full event storming simulation for an e-commerce order management system.
Please:
1. Launch all 5 persona agents in parallel
2. Have them analyze the domain
3. Synthesize their findings
4. Identify bounded contexts
5. Resolve any hot spots
Quick Mode
Give me a quick event storm overview for a subscription billing system.
Focus on the core happy path events.
Guided Mode
Let's do a guided event storming session for a hospital appointment system.
Start with the patient booking journey and I'll guide from there.
Output Format
The event storming session produces a structured event catalog:
# Event Storm: [Domain Name]
## Event Catalog
### [Bounded Context Name]
**Events:**
- [Event Name] [Domain Expert] - [Description]
- [Event Name] [Developer] - [Description]
**Commands:**
- [Command Name] → [Event Name] [Business Analyst]
**Actors:**
- [Actor Name]: [Commands they can issue]
**Aggregates:**
- [Aggregate Name]: [Events it produces]
**Policies:**
- [Policy Name]: [Trigger] → [Action]
## Bounded Contexts Identified
1. [Context Name]
- Core Domain / Supporting / Generic
- [Events in this context]
## Hot Spots
- [Issue] - [Resolution or TODO]
Full template: See references/templates/event-storm-output.md
Integration with Other Skills
Event storming connects with:
- domain-storytelling - Stories feed into event discovery
- modular-architecture - Bounded contexts become modules
- fitness-functions - Module isolation tests
- adr-management - Document bounded context decisions
Workflow:
Domain Storytelling → Event Storming → Modular Architecture
(understand "what") (design "how") (implement "where")
Best Practices
- Start with events - Events are facts, commands are debatable
- Use past tense - "Order Placed" not "Place Order"
- Explore boundaries - Events help find module boundaries
- Embrace chaos - Initial brainstorming should be messy
- Track provenance - Know which perspective each insight came from
- Resolve hot spots - Don't leave conflicts unaddressed
References
references/workshop-facilitation.md- Phase orchestration and timingreferences/persona-prompts.md- Prompt templates for each personareferences/sticky-note-types.md- Color conventions and usagereferences/bounded-context-discovery.md- Context identification patternsreferences/templates/event-storm-output.md- Output format with provenance
Version History
- v1.0.0 (2025-12-22): Initial release
- Multi-persona simulation with 5 agents
- Three workshop modes (full, quick, guided)
- 6-phase workshop structure
- Provenance tracking for insights
- Integration with domain-storytelling and modular-architecture
Last Updated
Date: 2025-12-22 Model: claude-opus-4-5-20251101