Creating State Machine Animations from Claude Code Prompts
Claude Code animation work starts with one command: claude mcp add exode -- npx -y claude-exode-mcp. After that, a prompt that names states, inputs and transitions becomes a real state machine in your .exode file, because Claude Code calls Exode tools to create the states, add the boolean or numeric inputs, and wire conditional transitions. Validate the graph, then export the component.
Claude Code is the client where the state machine workflow feels most natural, because you are already in a terminal next to the project and the agent can read the surrounding code. A prompt can reference a real component, a real prop and a real interaction, instead of describing them.
This guide covers the install, the prompt structure that works, one worked example end to end, and the checks worth running before you export.
Install the server in Claude Code
One command adds the server at user scope. Claude Code also supports a project-level .mcp.json, which is the better choice for a team, because the config travels with the repository and everyone gets the same server.
# user scope
claude mcp add exode -- npx -y claude-exode-mcp
# then start Claude Code and check the server loaded
claude
/mcpThe /mcp command inside Claude Code lists the connected servers and their tools. If exode is missing, the server failed to start, and running the npx command by hand in a terminal prints the error.
The prompt shape that produces a state machine
A state machine has five parts: the object, the states, the inputs, the transitions and the motion inside each state. A prompt that covers those five parts produces a graph you can read. A prompt that covers one of them produces something you have to redo.
Say what must not change. Agents are enthusiastic editors. "Keep the existing press behaviour and do not change the layout" saves a review round, and it gives the model a constraint it can check against the file.
- Object: which named object or artboard the work applies to.
- States: the names you want, usually two to five, in the words your team uses.
- Inputs: booleans, numbers or triggers, and what sets them.
- Transitions: which condition moves which state to which.
- Motion: how it should feel, plus anything that must stay untouched.
Worked example: a save button
Here is a request that produces a complete, valid machine in one pass. It is deliberately small; the same structure scales to a multi-step onboarding flow.
In artboards/save-button.exode, work on the object "SaveButton".
States: Idle, Saving, Saved.
Inputs: boolean "saved", trigger "submit".
submit moves Idle -> Saving. saved becomes true moves Saving -> Saved.
saved becomes false moves Saved -> Idle.
Inside each state:
- Idle: icon is an outline bookmark.
- Saving: icon rotates 360 degrees once, 600ms, ease in-out.
- Saved: icon fills in, and the button settles with a small spring overshoot.
Do not change the button size or its text. Use the existing shape objects.Claude Code will call add_input for the boolean and the trigger, create the three states, then add_transition for each edge with its condition. The rotation and the fill are animated on the state, so they play when the state is entered rather than needing their own timeline.
Check the machine before you export
Two tools catch most of the problems people hit. validate_artboard checks that every transition points at a state that exists, that every condition references an input that exists, and that animation tracks reference real objects. lint_artboard finds structural gaps such as states with no animation attached, and can repair some of them.
A useful habit: after any prompt that adds states or inputs, send "run validate_artboard on this file and fix what it reports". It takes a second and it catches the orphaned references that make a state machine quietly do nothing.
- validate_artboard: broken cross-references and bounds.
- lint_artboard with autoFix: missing animations and orphaned states.
- get_artboard_summary: a one-screen report of what exists.
Export, and judge the motion in the app
export_react_code produces a self-contained component from the file. For the rest of the stack, the same .exode plays through the Vue, Svelte, Angular, Solid, React Native, SwiftUI and Flutter runtime packages, so the machine is defined once.
Exporting is not the same as finishing. The graph can be correct and the motion still wrong, because timing is a design decision the model cannot evaluate. Play it, adjust the curve or duration, and export again.
Where Claude Code is the weaker choice
For a purely visual pass, a designer in the editor moves faster than an agent describing coordinates. Use Claude Code for the structure and the wiring, which is the tedious part, and the editor for the feel.
If the animation is a few CSS transitions in an existing component, the server is overhead. Claude Code can write those directly, and ExodeUI has nothing to add until the motion needs states or ports to another platform.
Rive publishes its own MCP setup for its editor. If the team already works in Rive, that connector is the one to use.
Frequently asked questions
We make ExodeUI and its MCP server. Treat what an agent produces as a draft, the same way you would treat code from a new teammate.
ExodeUI runs in the browser and on desktop. One .exode file plays in React, Vue, Svelte, Angular, Solid, React Native, SwiftUI and Flutter.