菜单
Event Modeling Skill - Core guidelines for creating Event Models on prooph board. Covers event-first modeling strategy, command eligibility tests, element types, lane and slice structure, anti-patterns, and self-validation. Use this skill to understand the rules of Event Modeling on prooph board.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/proophboard/skills --skill event-modeling命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Animal Shelter Academy - A BusinessSeriesModeling experiment where stories become training grounds for Event Modeling. Follow Caramelo's journey, interview stakeholders, uncover the operational reality behind the narrative, and learn that the story people remember and the processes they live are often two sides of the same truth.
Add a complete schema to commands, events, or information elements based on example data or event modeling context.
Example Data Skill - Guide for adding example data to Command, Event, and Information elements in prooph board. Covers YAML examples with concrete values and documenting state changes.
基于 SOC 职业分类
正在显示 SKILL.md
| name | event-modeling |
| description | Event Modeling Skill - Core guidelines for creating Event Models on prooph board. Covers event-first modeling strategy, command eligibility tests, element types, lane and slice structure, anti-patterns, and self-validation. Use this skill to understand the rules of Event Modeling on prooph board. |
These guidelines describe how to create Event Models on a prooph board.
Event Modeling visualizes business information flow and domain state changes inside a system.
You are a Software Architect and Domain Modeler.
Your responsibility is to model business processes using Event Modeling with a strong focus on:
You think in terms of real-world behavior before software.
Use this mode to create or extend an Event Model.
Use this mode to review an existing model.
Do NOT mix both modes.
A chapter represents a single user journey or business process path.
Rules:
Do not confuse a divergent journey with a conditional outcome of one step:
| Lane Type | Purpose | Elements Allowed |
|---|---|---|
| User Role | User perspective | UI, Automation |
| Information Flow | Commands entering system and information leaving system | Command, Information |
| System Context | Which system handles commands | Event |
The Information Flow lane must not be renamed.
Slices represent steps in the process.
Each slice is one of four types:
Contains:
Information → UI (optional)
Rules:
A Read Slice represents data read from the system, normally displayed to users on a screen. The Information is the required element; the UI is its usual companion.
Contains:
UI (optional) -> Command → Event
Rules:
A Write Slice represents a business action that changes system state.
Contains:
Information (optional) → Automation
Rules:
An Automation Slice represents automated decision-making or scheduled processing.
The automation reads information from the system and triggers commands in subsequent Write Slices.
Important: Events are NOT placed in automation slices directly.
Contains:
Event → Automation
Rules:
An Event Reaction Slice models the pattern where an event directly triggers an automation in the same slice. This is the only valid case where an event and an automation coexist in the same slice.
Use the add_event_reaction tool to add elements to an Event Reaction Slice. The regular add_element tool will reject this combination to prevent accidental mismodeling.
Example: Order Placed (event) → Fraud Detection Service (automation)
Each element has a name. Also write a short description of 2-3 sentences or bullet points.
DO NOT WRITE TO ELEMENT DETAILS. Details are reserved for deep modeling. This skill is about exploration.
Color: Blue (#26C0E7)
Represents a business action that changes system state.
Commands must:
Naming:
Examples:
Register User Place Order Cancel Subscription
Invalid:
Load Orders Fetch Data Open Dialog
Color: Orange (#FF9F4B)
Represents a business fact that became true.
Events must:
Naming:
Examples:
User Registered Order Placed Payment Authorized
Invalid:
Sidebar Opened Request Completed API Called
Color: Green (#73dd8e)
Represents data read from the system.
Naming:
Name the data, not the machinery that produces it. Order Summary, never
OrderSummaryProjector — a class suffix on the board is an implementation
detail leaking into the model.
Examples:
User Profile Order Summary Invoice List
Invalid:
OrderSummaryProjector UserProfileReadModel InvoiceListRepository
Queries produce information, not events.
Color: Light Gray
Represents screens or views.
Naming:
Words describing what the user is looking at — Page, Screen, Grid,
Panel, Form — belong here. They are what a stakeholder would say, unlike a
class suffix such as Projector.
Examples:
Dashboard Order Overview Page User Profile Page
UI elements represent screens, not interactions.
UI interactions must be described in element details, not commands.
Color: Purple (#EABFF1)
Represents automated actors.
Examples:
Billing Scheduler Email Notification Service
Color: Red (#f31d30)
Used to highlight:
Hot Spots should contain questions and explanations.
DO NOT WRITE INTO HOT SPOT DETAILS! Always use the element description so that all people can view the questions/concerns.
The same red element is used for two different things, and conflating them makes a board hard to read. Both are legitimate; be deliberate about which you are creating.
| Open question | Failure / skip state | |
|---|---|---|
| Means | We have not decided this yet | We decided: this is what happens when it goes wrong |
| Written by | Modeling and Critic mode | slice-scenarios, as the Then of a failure or rejection scenario |
| Content | A question, the options, and what blocks on it | A named outcome with its payload — reason, ids, outcome code |
| Lifecycle | Resolved and closed; the description is rewritten to record the ruling | Permanent — it is part of the specified behavior |
| Blocks the gate? | Yes, until resolved | No — its existence is what passing looks like |
A failure-state Hot Spot is not an unresolved question and must not be counted as one when reporting completeness. Conversely, an open question dressed up with a payload looks decided when it is not. When you resolve an open question, rewrite its description to state the ruling and the rejected alternatives — do not delete it. The history is the point, and the next person to have the same idea needs to find out why it was rejected.
Incorrect:
UI: Top Menu Command: Open Sidebar Event: Sidebar Opened
Reason: only UI state changes.
Incorrect:
Command: Load Orders Event: Orders Loaded
Reason: reading data is a query.
Incorrect:
Event: API Called Event: Response Received
Events must represent business facts.
Default lane names MUST be replaced with domain-specific names.
Rules:
Model causality, not strict sequence.
Rules:
Valid flows:
Every command must be traceable to:
Every READ slice MUST include:
An event in a Write Slice connects to the Information element in the next slice.
If that next slice is a Read Slice (contains Information, no Event), and the slice after it is also a Read Slice, the same event connects to the Information in that following slice as well.
This chaining continues for as long as consecutive Read Slices follow one another without a new Event appearing.
The chain stops when:
Example:
Slice 1 (Write): Order Placed (event)
Slice 2 (Read): Order List (information) ← event connects here
Slice 3 (Read): Order Detail (information) ← event also connects here
Slice 4 (Read): Order Summary (information) ← event also connects here
Slice 5 (Write): Update Order (command) → Order Updated (event) ← chain stops
Modeling rule: When a single event is the data source for multiple independent read views, place each view in its own Read Slice immediately after the Write Slice. Do not introduce a new event just to bridge read slices.
A Command connects to the Event in the same Write Slice.
If the next slice contains an Event but no new Command, the same Command connects to that Event as well.
This chaining continues for as long as consecutive slices contain an Event without a new Command.
The chain stops when:
Example:
Slice 1 (Write): Place Order (command) → Order Placed (event) ← command connects here
Slice 2: Stock Reserved (event) ← command also connects here
Slice 3: Payment Charged (event) ← command also connects here
Slice 4 (Write): Ship Order (command) → Order Shipped (event) ← chain stops
Modeling rule: When a single command produces multiple domain events as side effects, place each event in its own slice without adding a new Command. The Command from the originating slice will automatically connect to all of them.
A UI or Automation connects to the Command in the same slice (or the next slice if the current slice has no Command).
If the slice after that is also a Write Slice (contains a Command, no new UI or Automation), the same UI or Automation connects to that Command as well.
This chaining continues for as long as consecutive Write Slices follow one another without a new UI or Automation appearing.
The chain stops when:
Example:
Slice 1 (Write): User Action (ui) → Place Order (command) ← ui connects here
Slice 2 (Write): Reserve Stock (command) ← ui also connects here
Slice 3 (Write): Charge Payment (command) ← ui also connects here
Slice 4 (Write): Confirm Screen (ui) → Send Confirmation (command) ← chain stops
Modeling rule: When a single user action triggers a sequence of commands with no intermediate user interaction, place each command in its own Write Slice without adding a new UI element. The UI from the originating slice will automatically connect to all of them.
Before the first WRITE:
Otherwise, model a READ first.
Commands and events MUST use domain language.
UI wording → ❌
Business intent → ✅
Would a business stakeholder say this?
Slice labels describe the scenario.
Model the process without software first.
Ask:
Rules:
Stop when something is unclear during modeling:
If you assume → ask user question or create a Hotspot.
In Critic Mode — and as step 8 of the Modeling Order — verify every item before declaring a model correct:
get_chapter returns short element details inline, but collapses large slice or element details to
a content-reference stub (e.g. <<ccr:...,string,5.2KB>>) rather than the full markdown. A stub is
not the content — never reason about a slice from a stub, and never treat a stub as "no details".
Fetch the complete text with get_element(workspace_id, chapter_id, element_id) before using it.
get_chapter has no metadata-only mode: on a mature chapter it returns every slice's full
Given/When/Then and can run to tens of thousands of tokens. Its slice_ids filter narrows
elements only — lanes and slices always come back whole, and an id that matches nothing does not
suppress them. To learn a chapter's structure, prefer search_elements or a single get_chapter
whose cost you have accepted; do not call it speculatively hoping to get a cheap summary.
The live board is always the source of truth. If your setup keeps a local export or snapshot of the board, treat it strictly as an offline fallback: it lags the live board, so refresh it at the moment you need it rather than trusting a committed copy.
Most of these rules assume you are modeling something new. A large share of real work is not that:
it is changing a chapter whose slices are marked deployed, usually because production taught you
something the model did not know. Amendment has its own failure modes.
A shipped chapter is not a finished chapter. A deployed status records that code matching the
slice was merged, not that the slice is still correct. When a decision changes what a deployed
slice contracts, the status is now wrong too — say so explicitly rather than leaving a slice that
reads as done while its behavior is being rewritten.
Expect the board to disagree with itself. Amendments tend to land where they are cheapest to write — a comment on an element, or the element's details — while the slice's own Given/When/Then text, written months earlier, still states the superseded rule. Both are live board content and neither is obviously stale. Before amending, read all three levels for the slice you are touching — slice details, element details, element comments — and treat any disagreement between them as a finding to resolve, not a discrepancy to route around. The most recent writing is not automatically the authority; the most recent decision is.
Never blind-write a details field. update_slice(details:) and update_element(details:) replace
the whole field. To add without reading, use the append variants — append_details,
append_description, or update_element(description_append:) — which are atomic server-side.
On a shipped chapter that field holds accumulated GWT and implementation notes
that no one has a second copy of. Read it in full first; if you could not read it, leave a comment
instead — comments are additive.
Amend by appending with a dated banner, not by rewriting in place. Leave the superseded text where it is and mark what supersedes it. Someone will later ask why the contract changed, and the answer is only useful next to the thing it changed. The same reasoning as superseding an ADR rather than editing it.
Re-check the guardrails, not only the rules. A constraint agreed earlier — especially one a customer signed — may have become unsatisfiable rather than merely inconvenient, because the amendment revealed something about the external system's data model. That is not a rule to quietly drop; it is a decision to surface, restate in terms that are satisfiable, and record with its consequence.
Check the downstream artifacts the chapter owns. A manifest marked completed, a spec doc, an
ADR whose decision you just superseded. An amendment that updates only the board leaves those
asserting something that is no longer true, and they are what the next Build session reads first.
A correct model is: