القائمة
Event Modeling workflow facilitation; use when the user wants to model a workflow, discover behavior, or turn a business process into an event model.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Process Forgejo PR feedback with reflection, guardrail-gap classification, and inline thread replies.
Fine-grained outside-in RED-GREEN-REFACTOR microcycles with specialist agents and single-diagnostic implementation.
UI-first BDD for event-model slices, RGR sequence, observed-failure evidence, drill-down unit tests, and non-behavioral exemptions for eddy.
Write implementation plans as test-addressed red-green-refactor cycles, with UI-first Cucumber REDs for event-model slices, rather than component waterfalls.
eddy Rust workspace conventions, Nix toolchain use, error handling, env parsing, tests, and docs coupling.
Event Modeling pattern advice; use when deciding whether something is an event, command, read model, state change, state view, automation, or translation.
| name | event-modeling-facilitation |
| description | Event Modeling workflow facilitation; use when the user wants to model a workflow, discover behavior, or turn a business process into an event model. |
Use this skill to guide a workflow modeling session from plain-language conversation to an Event Modeling artifact.
The user does not need to speak Event Modeling vocabulary. Facilitate in business language first. Treat Event Modeling as the internal method you use to structure the conversation and final model.
Keep the discussion focused on the domain:
Do not start by asking for commands, events, read models, slices, or GWTs. If the user uses those terms, respond in kind. If the user asks what a term means, explain it briefly.
At the start of a substantial modeling session, calibrate gently:
How familiar are you with Event Modeling: new to it, comfortable, or experienced?
If asking would interrupt momentum, infer from the user's language and adjust.
For each major concept, explain it once when it first becomes useful:
After the first explanation, use short terms. Re-explain only when asked, when the user appears uncertain, or when a modeling mistake suggests the concept needs reinforcement.
Use this sequence, but do not make it feel like a form.
Scope the workflow. Ask what workflow or use case they want to understand. Identify the starting point, ending point, and what success looks like.
Elicit the story. Ask simple sequencing questions:
RepairTicketOpened, PaymentFailed, or LessonSelected.If the user gives an action like "approve repair," ask what fact should be true afterward: "After someone approves it, what would you say happened?"
Arrange the timeline. Confirm the story left-to-right in plain language. Look for missing transitions, loops, alternate flows, and unclear ordering.
Discover views and needed information. Ask what each person or process sees, chooses from, or needs to know. Work backward from visible data to stored facts.
Discover actions. For each remembered fact, ask what person, process, timer, or external input caused it. Internally map these to commands, automations, or translations.
Identify rules with examples. Ask for concrete examples:
Translate state-changing examples into Given/When/Then. Translate view examples into Given/Then.
Check information completeness. For every field on an event or view, ask where it comes from. Accept only these source categories in the final JSON: command input, generated value, external input, read model value, or prior event attribute for read-model fields.
Summarize before writing. Before editing JSON, summarize in plain language and list the model elements you intend to create. Ask a focused confirmation question if there is unresolved ambiguity.
Map business language to modeling concepts without forcing the vocabulary on the user: