菜单
Use when designing systems with Event Modeling methodology, creating event models, or when user mentions event modeling, commands/events/views blueprints, system timeline design, or CQRS system design workshops.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Onboard a developer to an unfamiliar repository, big-picture first. Produces a Purpose/Context section (what the repo is and why it exists), a Big Picture built with C4 diagrams (L1 System Context, L2 Container, optional L3 Component) plus event-reaction flow diagrams for async triggers (stream/queue/schedule/object-event), a Navigating-the-Code section (conventions, lean directory map, testing strategy), a Running-It-Locally checklist with the fast pre-PR loop, a Deploying-It section (deployment model, function/trigger inventory, managed-service graph, envs/secrets, CI/CD), and a Security Posture map — every claim cited to exact files, diagrams before code. Use for "onboard me", "help me understand this repo", "give me an overview", "explain this codebase's architecture", "what architecture pattern does this use", "how is this repo structured", "how do I run this locally", "what's the testing strategy here", "how is this service deployed", "how does CI/CD work here", or "what's the security posture". Read-on
Orchestrate implementation of one hexagonal Rust slice by dispatching agents in the correct order — build the domain core (model + use case + ports) first, then fan out the driven and driving adapters in parallel, then wire bootstrap serially. Use when you want to implement a ports-and-adapters slice with parallel adapter work that does not interfere. Trigger for "implement this slice hexagonally", "build the domain then the adapters in parallel", "scaffold a ports-and-adapters feature end to end". For the layering RULES themselves use rust-hexagonal; this skill is the DISPATCH recipe.
Structure and write user documentation with the Diátaxis framework (Tutorials, How-to guides, Reference, Explanation). Use when documenting content for users, designing the architecture of a docs set, or deciding what kind of doc a piece of content should be. Trigger for: "document this for users", "write a tutorial", "write a how-to guide", "structure our docs", "organize the documentation", "what kind of doc is this", "how should I document X", "audit our docs", "are these docs in the right place". NOT for: API rule extraction from code (use spec-extract), feature specs (use spec-create), or onboarding a developer to a repo (use onboarding).
Design or review Rust services using hexagonal (ports and adapters) architecture with idiomatic ownership, errors, and testing. Use when structuring a Rust project, deciding where a trait or dependency belongs, or auditing layering between domain and infrastructure.
Structure Rust code into cohesive modules and functions. Use when writing new Rust feature code, adding a module or a non-trivial function, deciding how to organize a file, splitting a god-file into a directory module, breaking a long function into an orchestrator plus phase functions, keeping an owned resource (transaction, lock, accumulator) from leaking across boundaries, or reviewing module/function structure. Apply while writing, not only when refactoring. Architecture-agnostic — any Rust code, hexagonal or not.
Interview the user relentlessly about every aspect of a plan, walking down each branch of the design tree and resolving dependencies between decisions one-by-one until a shared understanding is reached. Use when pressure-testing a plan, design, or feature idea before implementation, or before running spec-create. Trigger for "grill me", "interview me about this plan", "poke holes in my design", "challenge my assumptions", "stress-test this approach". NOT for writing code or implementing tasks (use spec-impl).
| name | event-modeling-spec |
| description | Use when designing systems with Event Modeling methodology, creating event models, or when user mentions event modeling, commands/events/views blueprints, system timeline design, or CQRS system design workshops. |
Produces a single visual blueprint of an entire system — one timeline read left-to-right that developers, designers, and stakeholders all share.
| Block | Color | What it is |
|---|---|---|
| Trigger | White | What starts a use case: UI wireframe, HTTP endpoint, or robot. Start simple — a named white box is enough |
| Command | Blue | An intention to change state, with parameters |
| Event | Orange | A business fact persisted. Past tense, business language, realistic data. Most important piece |
| View | Green | A read-only query that curates event data for a UI, report, or automated process |
Not in the blueprint: Aggregates, entity diagrams, database schemas — those are implementation details.
A slice = the smallest implementable unit. Each pattern instance is one slice:
Command — User changes something: Trigger → Command (blue) → Event(s) (orange)
Multiple roles can trigger the same command (e.g., Role 1 via UI, Role 2 via API).
| Section | Include |
|---|---|
| Trigger | ✅ UI wireframe or API endpoint |
| Command | ✅ with parameters |
| Event(s) | ✅ produced by the command |
| View | — |
View — User sees something: Event(s) (orange) → View (green) → Trigger
Views are passive — they read and curate events, never reject them.
| Section | Include |
|---|---|
| Trigger | ✅ UI or API response |
| View | ✅ with source events and fields |
| Command | — |
| Event(s) | — (listed as View sources) |
Automation — System reacts (we reach out): Event(s) → Todo-list View → 🤖 Robot → Command → Event(s)
The todo-list is a view that shows unprocessed items. A row appears when Event A exists without Event B for the same ID (e.g., "PaymentAuthorized where PaymentCaptured missing"). The robot reads each row, calls one command. The produced event (Event B) causes the row to disappear — guaranteeing each item is processed exactly once. No business logic in the robot — it just reads and calls.
| Section | Include |
|---|---|
| Trigger | — (robot is the actor) |
| Todo-list view | ✅ what populates it, what removes a row |
| Robot | ✅ named (e.g., "Payment Capturer") |
| Command | ✅ called by the robot |
| Event(s) | ✅ produced, removes the row |
Translation — External system notifies us: Event(s) [source] → View → 🤖 Translator → Command → Event(s) [ours]
Same structure as Automation but crosses system boundaries: an external system's events are the source. Read side: one source system only. Write side: can publish to multiple via Pub/Sub.
| Section | Include |
|---|---|
| Same as Automation, plus: | |
| External source | ✅ which system and event type |
Key distinction: Automation = we reach out. Translation = they notify us.
Example Translation: Stripe emits payment_intent.succeeded → Todo view "UnprocessedStripePayments" → 🤖 Stripe Translator → RecordPayment → PaymentRecorded in our domain.
A swim lane is a horizontal row on the board representing a domain (e.g., Booking, Payment, Inventory). Events sit on their domain's lane.
During the workshop, lanes evolve:
A lane can have sub-domains (e.g., "Loyalty" within "Guest") — note these in the Swim Lane Ownership table.
| Step | Action |
|---|---|
| 1. Brainstorm | List all state-changing events. Filter out observations ("Guest viewed page" is NOT an event) |
| 2. Plot | Arrange events left-to-right in chronological order of a typical user journey |
| 3. Storyboard | Add wireframes at top. What does each role see at each moment? |
| 4. Identify Inputs | For each wireframe action, add a Command (blue) connecting the trigger to the produced Event(s) |
| 5. Identify Outputs | For each screen that displays data, add a View (green) connecting source Events to the trigger |
| 6. Conway's Law | Reorganize lanes by domain/bounded context. Assign team ownership |
| 7. Specifications | Write Given-When-Then for every slice (see below) |
Every slice gets a specification — the contract for implementation. Use realistic data, never placeholders.
Command: Given (prior events = preconditions) → When (command) → Then (produced event) View: Given (accumulated events) → Then (query result) Automation: Given (todo list rows) → When (robot calls command) → Then (event produced, row removed)
Failure cases: When a command's preconditions aren't met (Given events don't exist), the command is rejected. Failure events (e.g., PaymentDeclined) are optional — model them as separate Command slices only if the system needs to react to the failure.
After modeling, verify:
Generate the event model document using references/output-template.md. The document includes a reader preamble so stakeholders unfamiliar with Event Modeling can understand the notation.
| Reference | Load When |
|---|---|
references/output-template.md | Generating an event model document — template with reader preamble, per-pattern section guide, and slice format |
references/event-model-example.md | Full Hotel Booking example — 18 slices across 5 swim lanes with completeness check |
| Mistake | Fix |
|---|---|
| Including observations as events | Only persist facts that mutate state |
| Skipping wireframes — jumping to events | Always start from UI (Step 3 before Step 4) |
| Using DDD aggregates or entity diagrams | Event Modeling uses swim lanes by domain, not aggregates |
| Business logic in the automation robot | Robot reads todo and calls command. Logic lives in handler |
| Views that validate or reject | Views are passive — they only read and curate |
| Missing specifications with realistic data | Every slice needs Given-When-Then with concrete values |
| Automation vs Translation confusion | Automation = we reach out; Translation = they notify us |
| Trigger section on Automation slices | Automations have no user trigger — the robot is the actor. Omit the Trigger section |
| Todo-list view missing population/removal logic | Always write "Feeds from: Event A where Event B missing for same ID" — name both events explicitly |
