From trogonstack-eventmodeling
Step 1 of Event Modeling - Brainstorm all domain events from requirements. Extract every state-changing event the system could have. Use when starting event modeling from requirements or a new domain. Do not use for: arranging events in sequence (use eventmodeling-plotting-events), designing commands or read models (use eventmodeling-designing-event-models), or when a complete event list already exists.
How this skill is triggered — by the user, by Claude, or both
Slash command
/trogonstack-eventmodeling:eventmodeling-brainstorming-eventsThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
**When to Interview**: Skip if the user has provided detailed, well-documented requirements (written user stories, feature specs, business rules). Interview when requirements are vague, incomplete, or when domain expertise is uncertain.
When to Interview: Skip if the user has provided detailed, well-documented requirements (written user stories, feature specs, business rules). Interview when requirements are vague, incomplete, or when domain expertise is uncertain.
Interview Strategy: Ensure requirements are complete and team understands domain well enough to brainstorm comprehensively. Identify hidden complexity areas upfront.
When requirements need clarification:
Requirements Completeness (Impact: Determines if brainstorm is likely to be exhaustive)
Domain Expertise & Familiarity (Impact: Shapes who should participate and what guidance is needed)
Known Complexity Areas (Impact: Determines where to focus brainstorming effort and depth)
Explicit Business Rules & Constraints (Impact: Ensures no implicit assumptions; may reveal missing events)
Conditional Entry:
If user has provided:
- Written requirements or user stories (not just verbal)
- AND documented business rules or constraints
- AND named domain experts who will participate
Then: Skip interview, proceed directly to brainstorming
Else: Conduct interview
Phase 1: Requirements Assessment (Questions 1-2)
Phase 2: Complexity Mapping (Questions 3-4)
Append findings to the project's event modeling file:
File: .trogonai/interviews/[project-name]/EVENTMODELING.md
Use Write tool to add/update this section:
## 2. Brainstormed Events (eventmodeling-brainstorming-events)
### Requirements Assessment
[From Q1: Written requirements? Documented rules?]
### Domain Expertise
[From Q2: Who understands domain? Available for participation?]
### Role Catalog
#### Human Roles
- [Role 1]: [Description] → Actions: [list]
- [Role 2]: [Description] → Actions: [list]
#### System Actors
- [Actor 1]: [Description] → Triggers: [list]
### Event Streams (Stream Roots)
- Stream: [Name] (Identity: [id field])
- Events: [Event1, Event2, Event3]
- State changes: [State transitions]
### Business Rules & Constraints
[From Q3 & Q4]
- Rule 1: [Statement] → [Events it generates]
- Rule 2: [Statement] → [Events it generates]
- Constraint 1: [Limitation]
### Brainstorming Focus Areas
- [Focus area 1]
- [Focus area 2]
Update Interview Trail:
| 2 | eventmodeling-brainstorming-events | [today] | Event streams, business rules, constraints |
This section feeds into subsequent steps (plotting, storyboarding, etc.)
Setting: This is a collaborative brainstorming workshop. The facilitator guides participants to envision the system and extract events rapidly.
Phase 1: Understand Goals (5-10 min)
Phase 2: Free Brainstorm (15-20 min) Facilitator asks:
"What events could happen in this system? When something changes, what event occurs? Put down ANY event you think of."
Participants call out events (sticky notes or digital cards):
"Customer places order"
"Order confirmed"
"Payment received"
"Inventory updated"
"Order shipped"
"Delivery confirmed"
"Return requested"
"Refund issued"
Phase 3: Gentle Filtering (10-15 min) Facilitator introduces state-changing concept gently:
Facilitator: "Now let's think about these events. An event is something that
CHANGED THE STATE of the system. It's something important that happened that
others need to know about.
Let me ask: Does 'Customer viewed the catalog' change anything?
Participants: "Well... no, they just looked."
Facilitator: "Right, so it's not an event. But if they SELECTED an item
from catalog, that changes what's in their cart, so that's
a state change. Call that 'ItemAddedToCart'."
Does 'Payment received' change something?
Participants: "Yes! Order goes from confirmed to paid."
Facilitator: "Exactly! That's an event—state changed."
Key points to clarify:
Make it conversational:
Use examples from their world:
Don't be rigid:
Capture the "why":
When given domain requirements, perform the following analysis:
Before brainstorming events, define who interacts with the system. Every event model needs an explicit role catalog — without it, downstream steps (storyboarding, commands, scenarios) lack clarity on who does what.
Identify all human roles and system actors:
For each role/actor, document:
Present as a Role Catalog:
## Role Catalog
### Human Roles
1. **Customer** - Description: End user who browses, purchases, and tracks orders
- Key actions: Create order, confirm order, cancel order, submit review
- Cannot: Manage inventory, process refunds, respond to reviews as seller
2. **Seller** - Description: Merchant who lists products and fulfills orders
- Key actions: List product, confirm stock, respond to reviews, update pricing
- Cannot: Place orders, approve own reviews, process payments
3. **Support Agent** - Description: Internal staff handling escalations and manual overrides
- Key actions: Override order status, issue refunds, flag reviews
- Cannot: Place orders on behalf of customers (unless impersonating)
### System Actors
1. **Payment Gateway** (external)
- Triggers: Payment authorization, payment failure, refund confirmation
- Communication: Webhooks
2. **Inventory System** (internal)
- Triggers: Reserve inventory, release reservation
- Communication: Event-driven
This catalog feeds directly into:
Identify the main entities that will have event streams. These are NOT DDD aggregates—they're simply the logical roots of events:
For each stream root, note:
Map out critical workflows:
For each process, identify what state changes occur:
These become your domain events.
Examples:
Present findings in this structure (include facilitation notes for future workshops):
## Workshop Notes
**Participants**: [List roles: PO, Dev, QA, Domain Expert]
**Duration**: [Time spent]
**Key facilitation moments**: [What helped clarify understanding?]
---
# Domain Analysis: [Domain Name]
## Role Catalog
### Human Roles
1. **[Role Name]**: [Description]
- Key actions: [What this role can do]
- Cannot: [Permission boundaries]
### System Actors
1. **[Actor Name]** ([internal/external]): [Description]
- Triggers: [What events/commands it initiates]
- Communication: [Webhooks / Event-driven / API]
## Event Streams (Stream Roots)
List each stream root and its identity:
- **Stream**: Review (Identity: reviewId)
- **Stream**: SellerResponse (Identity: responseId)
- **Stream**: Seller (Identity: sellerId)
Note: These are just the logical groupings of events. The STATE needed for each command will be determined later—not all stream attributes are needed for all commands.
## Business Processes
1. **Process Name**: Description
- Actor: Who initiates?
- Steps: 1. → 2. → 3.
- Outcomes: What changes?
## Identified State Changes (Potential Events)
- [Stream] [Verb]: When? Why? (Use past tense: "ReviewPublished", "SellerResponseAdded")
## Business Rules & Constraints
- Rule 1: Condition and consequence
- Rule 2: Constraint description
## Questions for Domain Expert
- Any gaps in understanding?
- Unclear processes?
Present analysis in a clear markdown structure that can be directly used by the eventmodeling-designing-event-models skill.
NEVER use DDD Aggregate pattern for state design Every command handler must have its own minimal state projection derived from events. This is non-negotiable.
ANTI-PATTERN (Do NOT do this):
OrderAggregate { orderId, customerId, items[], total, status, paymentId, address, shippedAt, cancelledAt, ... }
Used by: ConfirmOrder, ShipOrder, CancelOrder, ApproveReturn
Problem: Loads unused data, couples unrelated commands, violates minimal state principle
CORRECT PATTERN:
ConfirmOrderState { status, orderId }
ShipOrderState { status, orderId, paymentId }
CancelOrderState { status, orderId, createdAt }
Each command loads ONLY what it needs.
Provide concrete examples and clear scope:
Use terms your business understands, not technical jargon:
Make implicit rules explicit:
Cross-check that the Role Catalog (from Step 1) covers all actors referenced in events and processes:
Include error and boundary conditions:
OrderPlaced, not PlaceOrder)UserUpdated, RecordDeleted) — events describe business moments, not database operationsnpx claudepluginhub trogonstack/agentskills --plugin trogonstack-eventmodelingProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.