event-modeling-spec
Event Modeling
Produces a single visual blueprint of an entire system — one timeline read left-to-right that developers, designers, and stakeholders all share.
2 Core Ideas
- Events on a timeline — The system is a sequence of business facts persisted over time. Events are the source of truth.
- State for UIs — Users see views (screens, reports) built from events, not events directly.
4 Building Blocks
| 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.
More from jrollin/claudio
skill-testing
>
1spec-create
Create a new feature specification following a phased workflow. Use when starting a new feature that needs requirements, design, and task planning. Invoke for spec-driven development, feature specification, requirements-design-tasks workflow.
1spec-impl
Task-by-task implementer that reads a completed spec and executes each task atomically. Use when a feature spec exists and you're ready to implement. Invoke for spec implementation, task execution, spec-driven development.
1agent-browser
when asking to check ui or tests automation in browser
1event-modeling-tasks
Use when translating a completed event model into implementation tasks. Invoke when an event model with slices and specifications exists and needs to become a development plan, task breakdown, or spec-create compatible output.
1