Not a list of features. Real scenarios showing how the platform works — from a problem you recognise to a result you can open on your board.
Automatic Domain Discovery using Claude Code — on autopilot, in ~15 minutes
Sara is a software architect. In two days she has a domain modeling workshop with the business team. The agenda: map out how their Customer Onboarding flow actually works so they can redesign it. Normally she'd spend a morning taking screenshots, writing descriptions, and organizing them into something usable. She tries something different instead.
npx @eventmodelers/agent-modeling-kit@latest installclaude mcp add chrome-devtools --scope user -- npx chrome-devtools-mcp@latesthttps://app.hercompany.com and "Focus on the customer onboarding flow." Then she goes to make coffee.The agent didn't read the docs or the code. It looked at the actual product, the way a real user would. And it built a starting point for the workshop in 15 minutes, on autopilot. Domain discovery doesn't have to mean writing boring documentation. Sometimes it just means letting an agent show you what's really there — including the things you didn't know were broken.
Run the full Event Modeling workflow in one conversation — and discover what the business actually needs before anyone writes a line of code
David is a senior developer about to start a new feature: a subscription management flow for a SaaS product. The business gave him a one-pager, a Figma mockup, and a Confluence doc with bullet points. He has sprint planning in two days. He types /orchestrate-event-modeling and answers five questions.
npx @eventmodelers/agent-modeling-kit@latest installThe agent didn't write the code. It asked the right questions — the ones that expose assumptions, reveal missing events, and force the team to agree on what "cancelled" actually means. That conversation, structured into 9 steps, is worth more than a sprint of code written against a misunderstood spec. Model first. Code second.
A shared board as the agenda, the whiteboard, and the minutes — all at once
The team used to start every refinement with the same question: "So — where were we?" Twenty minutes gone before a single decision. Now the first thing anyone does when a meeting starts is open the board. The model is the agenda. What's on it drives the conversation. What changes during the session is captured automatically. The meeting ends with something tangible — every time.
The board doesn't just capture what the team decided — it changes how they talk. When everyone is looking at the same visual model, the conversation becomes about the model. Not about opinions, not about who remembers it differently. The structure is the discipline. And every meeting ends with something real: a board that reflects what was agreed, recorded change by change.
Mark a slice as Planned on the board — the agent implements it, runs the tests, commits, and marks it Done. Automatically.
Alex has a complete Event Model on the board — events, commands, read models, and Given-When-Then specs from the session last week. The team has agreed on the model. Now it's time to build. Alex installs the build kit, starts the agent loop in a terminal, and goes back to the board. He marks the first slice Planned. Three minutes later he gets a notification: the slice is Done.
build and test before every commitnpx @eventmodelers/build-kit-node install for Node.js, npx @eventmodelers/build-kit-axon install for Axon/Java, or npx @eventmodelers/build-kit-supabase install for Supabase. The installer asks for your API token and Organization ID — everything else is automatic.cd .build-kit-node && ./ralph.sh. The loop polls for work every few seconds. Optionally start the realtime agent in a second terminal — it subscribes to board events over Supabase Realtime so the loop reacts instantly the moment a slice status changes, without any polling delay..slices/. Phase 2 reads it, determines the slice type, and runs the matching skill: /build-state-change for command handlers, /build-state-view for projections, /build-automation for reactors. The slice status flips to InProgress on the board the moment the agent starts.npm run build and the slice test suite. If everything passes, it commits with feat: <slice name>, merges to main, updates the slice status to Done on the board, and immediately starts watching for the next Planned slice. Alex's board turns green, one slice at a time — no manual handoff at any step.The model isn't documentation anymore. It's a build specification. Every event, command, and read model you place on the board is something the agent can implement — correctly, with tests, without you touching the IDE. The distance between we agreed on the design and the feature is in main collapsed from days to minutes.
Update a slice definition on the board, reset its status to Planned — the agent rewrites the existing implementation to match. The model is always the source of truth.
Lena is three weeks into the build. Several slices are already Done — command handlers implemented, tests passing, board green. Then the business comes back: the OrderPlaced event needs two new fields, the projection that reads orders needs to expose them, and the command that places an order needs an extra validation rule. In the old world this means reading the code, finding every place the event is used, updating each one, hoping nothing is missed. Lena opens the board instead.
discountCode and shippingTier to the OrderPlaced event, adds a validation rule to the command ("discount code must be active"), and updates the Given-When-Then scenario to cover the new failure case. The change takes four minutes. The board is now accurate..slices/, compares it with the new spec, and runs /build-state-change against the updated definition. The agent does not patch around the old code — it implements the slice correctly according to the current model. What the model says is what the code does.npm run build and the slice test suite. The new Given-When-Then scenario — "Given an inactive discount code, When PlaceOrder is submitted, Then the command is rejected" — is tested as part of the standard test run. The test was written on the board; the agent made sure it passes in the code.feat: update PlaceOrder — add discountCode, shippingTier, validation rule, merges to main, and sets the slice back to Done on the board. Lena opens the board. Green. She opens the code. It matches what the board says. She didn't touch the IDE once.The model isn't a diagram you draw once and forget. It's a living spec — and when it changes, the code changes with it. Not the other way around. Resetting a slice to Planned isn't undoing work: it's telling the agent that the definition has changed and the implementation needs to catch up. That discipline — model first, code follows — is what keeps the board and the codebase telling the same story, sprint after sprint.
Draw screens in minutes with the built-in sketch tool — align them on the event timeline, discuss flows with the team, and let AI build from what you sketched
Julia is a product designer sitting in a refinement session with two developers and a business stakeholder. They're trying to nail down a payment confirmation flow before anyone starts coding. Normally this means pulling up Figma, waiting for everyone to get the right link, arguing about prototypes, then someone screenshares — and half the screen is tool UI, not the actual design. Today Julia opens the sketch tool directly on the board. Ten minutes later there are four screens on the timeline, the team is pointing at specific UI elements, and the developer is already reading the model to see what data each screen needs.
A sketch on a whiteboard disappears when the meeting ends. A sketch on the event modeling board becomes part of the specification — aligned with the command it belongs to, visible to every developer who reads the model, and readable by the AI agent that builds from it. You don't need Figma to communicate a UI. You need the right screen in the right place, on the right timeline.