@eventmodelers/cli 1.0.36 → 1.0.38

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-applying-conways-law/SKILL.md

@@ -11,16 +11,14 @@ allowed-tools:
 
 > **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed. Consult `learn-eventmodelers-api` only if you need to look up a specific endpoint or field this file doesn't cover — don't load it eagerly.
 
+This step applies the shared element rules in **`eventmodeling-core-rules`** — read it once per session if you haven't already; it defines what a COMMAND/EVENT/READMODEL/SCREEN/AUTOMATION is, how each is named, and the anti-patterns to reject, so this step doesn't restate them.
+
 ## Interview Phase (Optional)
 
 **When to Interview**: Skip if the user has already specified: existing team structure, team responsibilities, and autonomous boundary preferences. Interview when team structure is unclear or organizational alignment hasn't been discussed.
 
-**Interview Strategy**: Understand team organization and decision-making to design system boundaries that teams can own independently. Misalignment here creates bottlenecks and tight coupling later.
-
 ### Critical Questions
 
-When team structure or boundaries are unclear:
-
 1. **Team Structure & Ownership** (Impact: Determines how many swimlanes/systems to create)
    - Question: "How is your organization structured? (A) Single team owns everything, (B) Separate teams by domain (payments, inventory, etc.), (C) Separate teams by function (backend, frontend, etc.)"
    - Why it matters: Team structure directly shapes system boundaries; aligning them reduces coordination overhead
@@ -36,63 +34,7 @@ When team structure or boundaries are unclear:
    - Why it matters: External systems often become separate swimlanes; knowing which ones matters for boundary design
    - Follow-up triggers: For each integration → ask "Who owns the integration—existing team or new team?"
 
-### Interview Flow
-
-**Conditional Entry**:
-```
-If user has provided:
-  - Clear team structure (who owns what)
-  - AND specified desired level of autonomy
-  - AND identified external integrations
-
-Then: Skip interview, proceed directly to swimlanes
-
-Else: Conduct interview
-```
-
-**Phase 1: Organization Assessment** (Questions 1-2)
-- Understand team structure
-- Determine autonomy expectations
-- Establish boundary philosophy
-
-**Phase 2: Integration Mapping** (Question 3)
-- Identify external systems
-- Plan integration boundaries
-- Finalize swimlane count
-
-### Capturing Interview Findings
-
-Append findings to the project's event modeling file:
-
-**File**: `.trogonai/interviews/[project-name]/EVENTMODELING.md`
-
-Use Write tool to add/update this section:
-
-```markdown
-## 6. Conway's Law (eventmodeling-applying-conways-law)
-
-### Team Structure
-- Team 1: [Name] - Owns [domain]
-- Team 2: [Name] - Owns [domain]
-- Team 3: [Name] - Owns [domain]
-
-### Autonomy Goals
-[High / Moderate / Low]
-
-### Swimlanes
-- [Swimlane 1]: [Team] owns [events]
-- [Swimlane 2]: [Team] owns [events]
-- [Swimlane 3]: [Team] owns [events]
-
-### Cross-Team Communication
-- [Team A] → [Team B] via [event]
-- [Team B] → [Team C] via [event]
-```
-
-Update Interview Trail:
-```markdown
-| 6 | eventmodeling-applying-conways-law | [today] | Swimlanes defined, team boundaries confirmed |
-```
+Follow **`eventmodeling-interview-protocol`** to run this interview and record its findings — label this step "**6. Conway's Law** (`eventmodeling-applying-conways-law`)". Findings should cover: team structure and ownership, autonomy goals, the resulting swimlanes (which team owns which events), and cross-team communication paths.
 
 ---
 
@@ -100,339 +42,29 @@ Update Interview Trail:
 
 Given all events, inputs, and outputs, organize by ownership:
 
-### 1. Identify System Boundaries
-Determine what constitutes a separate system/bounded context:
-
-```
-System Boundaries:
-
+> **This step's "swimlane" is the same boundary `eventmodeling-brainstorming-events` governs, described from the ownership angle instead of the board-mechanics angle.** That skill's Swimlane Rules restrict the board's actual `swimlane`-type lane to marking integration with another system — this step doesn't loosen that cap or add a lane per team. Under Conway's Law, "team" and "system" name the same boundary: a system this chapter's process integrates with is, by definition, owned by some other team. The diagrams below are a narrative/analysis device for documenting *who owns what* across those boundaries — not an instruction to create one board swimlane lane per team named here.
 
- Order Management System                             
-  - Owns: Order entity and its lifecycle             
-  - Events: OrderCreated, OrderConfirmed, Cancelled  
-  - Owns: Order state machine                        
-
-
-
- Payment Processing System                           
-  - Owns: Payment authorization and processing       
-  - Events: PaymentAuthorized, PaymentFailed         
-  - Owns: Payment state machine                      
-
-
-
- Inventory System                                    
-  - Owns: Stock levels and reservations              
-  - Events: InventoryReserved, InventoryAllocated    
-  - Owns: Inventory state machine                    
-
-
-
- Fulfillment System                                  
-  - Owns: Shipments and delivery                     
-  - Events: OrderShipped, DeliveryConfirmed          
-  - Owns: Shipment state machine                     
-
-```
+### 1. Identify System Boundaries
+Determine what constitutes a separate system/bounded context: for each candidate system, name what it owns, list the events it produces, and note the state machine it's responsible for. A full worked example (Order/Payment/Inventory/Fulfillment domain) is in `references/examples.md`.
 
 ### 2. Create Swimlane Diagram
-Visual representation of system boundaries:
-
-```
-                Event Stream Timeline
-                →
-
-Order Team      OrderCreated   OrderConfirmed   OrderCancelled
-                                                   
-Payment Team                 PaymentAuthorized    PaymentFailed
-                                    
-Inventory Team                InventoryReserved
-                                    
-Fulfillment Team              OrderShipped    DeliveryConfirmed
-
-Each team owns their swimlane events
-Coordination via events crossing swimlanes
-```
+Lay the events out on a timeline with one row per team, showing which events each team owns and where coordination crosses from one team's row into another's. A full worked example is in `references/examples.md`.
 
 ### 3. Map Team Responsibilities
-Define what each team owns:
-
-```
-Order Management Team
- Commands they handle:
-   - CreateOrder
-   - ConfirmOrder
-   - CancelOrder
- Events they produce:
-   - OrderCreated
-   - OrderConfirmed
-   - OrderCancelled
- Read Models they maintain:
-   - OrderStatusView
-   - OrderListView
- Systems they call:
-    - Payment System (to confirm payment)
-    - Inventory System (to check stock)
-
-Payment Processing Team
- Commands they handle:
-   - AuthorizePayment
-   - ProcessPayment
-   - RefundPayment
- Events they produce:
-   - PaymentAuthorized
-   - PaymentFailed
-   - PaymentRefunded
- Read Models they maintain:
-   - PaymentStatusView
-   - TransactionHistory
- Systems they depend on:
-    - Payment Gateway (external)
-    - Order System (for context)
-
-Inventory Team
- Commands they handle:
-   - ReserveInventory
-   - ReleaseReservation
-   - AllocateStock
- Events they produce:
-   - InventoryReserved
-   - ReservationReleased
-   - StockAllocated
- Read Models they maintain:
-   - InventoryLevelView
-   - ReservationView
- Systems they depend on:
-    - Order System (triggers)
-    - Warehouse System (stock source)
-
-Fulfillment Team
- Commands they handle:
-   - CreateShipment
-   - MarkShipped
-   - ConfirmDelivery
- Events they produce:
-   - ShipmentCreated
-   - OrderShipped
-   - DeliveryConfirmed
- Read Models they maintain:
-   - ShipmentTrackingView
-   - DeliveryScheduleView
- Systems they depend on:
-    - Inventory System (items to ship)
-    - Carrier APIs (tracking)
-```
+For each team, define: the commands they handle, the events they produce, the read models they maintain, and the other systems they call or depend on. A full worked example (Order/Payment/Inventory/Fulfillment teams) is in `references/examples.md`.
 
 ### 4. Identify Inter-System Communication
-Show how systems talk to each other:
-
-```
-Communication Patterns:
-
-Order System  →  Payment System
- Order System produces: OrderConfirmed event
- Payment System consumes: OrderConfirmed
- Payment System reacts: Issues AuthorizePayment command
- Payment System produces: PaymentAuthorized event
-
-Order System  →  Inventory System
- Order System produces: PaymentAuthorized event (indirectly)
- Inventory System consumes: PaymentAuthorized
- Inventory System reacts: Issues ReserveInventory command
- Inventory System produces: InventoryReserved event
-
-Inventory System  →  Fulfillment System
- Inventory System produces: InventoryReserved event
- Fulfillment System consumes: InventoryReserved
- Fulfillment System reacts: Issues CreateShipment command
- Fulfillment System produces: OrderShipped event
-```
+For each pair of systems that interact, document the triggering event, what the consuming system does in reaction (which command it issues), and the event that results. A full worked example is in `references/examples.md`.
 
 ### 5. Define System Interfaces
-What each system exposes:
-
-```
-Order System Interface
- Commands it accepts:
-   - CreateOrder (from UI)
-   - ConfirmOrder (from UI)
-   - CancelOrder (from UI or Processors)
- Events it produces:
-   - OrderCreated
-   - OrderConfirmed
-   - OrderCancelled
- Read Models it provides:
-    - OrderStatusView
-    - OrderListView
-
-Payment System Interface
- Commands it accepts:
-   - AuthorizePayment (from Payment Processor/Order System)
-   - ProcessPayment (from Order System)
- Events it produces:
-    - PaymentAuthorized
-    - PaymentFailed
-    - PaymentProcessed
-
-Inventory System Interface
- Commands it accepts:
-   - ReserveInventory (triggered by PaymentAuthorized event)
- Events it produces:
-    - InventoryReserved
-    - InventoryFailed
-```
+For each system, list the commands it accepts (and from where — UI, another system, a processor) and the events/read models it produces or provides to others. A full worked example is in `references/examples.md`.
 
 ### 6. Identify Processors vs Systems
-Show where automation lives:
-
-```
-Processors (autonomous automation):
-
-1. PaymentProcessor
-   Triggered by: OrderConfirmed event
-   Logic: Calls external payment gateway
-   Produces: AuthorizePayment command
-   Lives in: Payment System
-
-2. InventoryProcessor
-   Triggered by: PaymentAuthorized event
-   Logic: Checks stock, reserves inventory
-   Produces: ReserveInventory command
-   Lives in: Inventory System
-
-3. FulfillmentProcessor
-   Triggered by: InventoryReserved event
-   Logic: Creates shipment records
-   Produces: CreateShipment command
-   Lives in: Fulfillment System
-
-4. NotificationProcessor
-   Triggered by: OrderCreated, OrderConfirmed, OrderShipped events
-   Logic: Sends emails/SMS
-   Produces: No commands (info-only)
-   Lives in: Notification System (cross-cutting)
-```
+For each autonomous processor/automation, document what triggers it, its logic, the command(s) it produces, and which system it lives in. A full worked example (Payment/Inventory/Fulfillment/Notification processors) is in `references/examples.md`.
 
 ## Output Format
 
-Present as:
-
-```markdown
-# System Organization: [Domain Name]
-
-## System Boundaries
-
-### System: Order Management
-- **Team**: Order Team
-- **Responsibilities**: Create, confirm, cancel orders
-- **Commands**: CreateOrder, ConfirmOrder, CancelOrder
-- **Events Produced**: OrderCreated, OrderConfirmed, OrderCancelled
-- **Events Consumed**: PaymentAuthorized, InventoryReserved (for state updates)
-- **Read Models**: OrderStatusView, OrderListView
-- **Scope**: One stream type (Order)
-
-### System: Payment Processing
-- **Team**: Payment Team
-- **Responsibilities**: Authorize and process payments
-- **Commands**: AuthorizePayment, ProcessPayment, RefundPayment
-- **Events Produced**: PaymentAuthorized, PaymentFailed, PaymentRefunded
-- **Events Consumed**: OrderConfirmed (from Order System)
-- **Read Models**: PaymentStatusView, TransactionHistory
-- **Dependencies**: External payment gateway
-- **Scope**: One stream type (Payment)
-
-### System: Inventory Management
-- **Team**: Inventory Team
-- **Responsibilities**: Stock management and reservations
-- **Commands**: ReserveInventory, ReleaseReservation, AllocateStock
-- **Events Produced**: InventoryReserved, ReservationReleased, StockAllocated
-- **Events Consumed**: PaymentAuthorized (from Payment System)
-- **Read Models**: InventoryLevelView, ReservationView
-- **Dependencies**: Warehouse system
-- **Scope**: One stream type (InventoryReservation)
-
-[Continue for each system]
-
----
-
-## Event Flow Across System Boundaries
-
-### Flow: Order → Payment → Inventory → Fulfillment
-
-```
-Time →
-
-Order System
-OrderCreated →
-OrderConfirmed →
-                              (triggers)
-Payment System
-PaymentAuthorized →
-                       (triggers)
-Inventory System
-InventoryReserved →
-                       (triggers)
-Fulfillment System
-OrderShipped
-DeliveryConfirmed
-```
-
----
-
-## Team Responsibilities Matrix
-
-| Team | Creates Commands | Produces Events | Owns Read Models |
-|------|-----------------|-----------------|------------------|
-| Order | CreateOrder, ConfirmOrder | OrderCreated, OrderConfirmed | OrderStatusView |
-| Payment | AuthorizePayment | PaymentAuthorized | PaymentStatusView |
-| Inventory | ReserveInventory | InventoryReserved | InventoryLevelView |
-| Fulfillment | CreateShipment | OrderShipped | ShipmentTrackingView |
-
----
-
-## Inter-System Communication
-
-### Order → Payment
-- Trigger: OrderConfirmed event
-- Action: Payment System listens via Processor
-- Result: AuthorizePayment command issued
-
-### Payment → Inventory
-- Trigger: PaymentAuthorized event
-- Action: Inventory System listens via Processor
-- Result: ReserveInventory command issued
-
-[Document all communication patterns]
-
----
-
-## Dependencies
-
-### External Systems
-
-| System | Owns | Called By | Purpose |
-|--------|------|-----------|---------|
-| Payment Gateway | Payment provider | Payment System | Authorization |
-| Warehouse | Inventory source | Inventory System | Stock info |
-| Carrier API | Shipping | Fulfillment System | Tracking |
-
----
-
-## Independent Development
-
-Each system can:
-- Develop independently
-- Use different tech stacks
-- Scale independently
-- Deploy independently
-- Own their events
-- Maintain their read models
-
-Coordination via:
-- Events (async messaging)
-- Processors (listen and react)
-- Read models (shared views)
-```
+Present the analysis as a markdown document titled "System Organization: [Domain Name]" with these sections: **System Boundaries** (one entry per system, giving its owning team, responsibilities, commands, events produced/consumed, read models, dependencies, and scope); **Event Flow Across System Boundaries** (a time-ordered diagram showing which system's events trigger the next system downstream); a **Team Responsibilities Matrix** (one row per team: commands, events, read models); **Inter-System Communication** (one entry per system pair: triggering event, reacting system/action, resulting command); a **Dependencies** table of external systems (what they're called for); and a closing **Independent Development** note on how the boundaries let each team build, scale, and deploy independently, coordinating only via events, processors, and shared read models. A full worked example of this document (Order/Payment/Inventory/Fulfillment domain) is in `references/examples.md`.
 
 ## Quality Checklist