Prototype how you like

Every screen on the Statecraft canvas is live — real components rendering against real styles. The canvas is the default editing surface; you can also drop into source in your IDE or prompt an AI agent against the same project. Pick whichever fits the moment.

Three ways to edit

Statecraft doesn't pick a single editing surface for you. The canvas, your IDE, and your agent are equivalent gateways to the same project — use them in the same session if you want:

• Visually on the canvas — the default for designers. Click an element to select it; the Properties panel exposes the props your design system declares (variant, size, colour token, copy). Drag and drop reorders elements inside a frame and across frames. See Editing states and Selecting & arranging elements for the visual surface in depth.
• Source-first in your IDE — every state lands on disk as a plain .jsx or .vue file when you sync the workspace locally. Edit in VS Code, Cursor, or Zed and saves bounce back to the canvas. Details below.
• By prompting an agent — Claude Code, Cursor, Codex, and most CLI agents work straight against the sync folder. Details below; deep reference at Build alongside an AI agent.

Everyone editing sees changes live, no matter the surface. A designer dragging an element, an engineer editing source, and an agent applying a refinement all show up on each other's canvas within a second.

States are screens, transitions are clicks

Whichever surface you're editing in, the shape of a prototype is the same: each screen is a state, each click is a transition, and the buttons you click are real components, not images of them.

Idle  ── submit ──▶  Success

That's the whole shape. Add more states (loading, error, empty) and more transitions between them, and you have the prototype your designer would sketch in Figma — except every click runs against production components.

Add a second state

The sidebar lists every state in the project. Click + Add state to create a new one. Statecraft seeds each new state with the same JSX as the one you had selected, so you can edit it incrementally rather than starting from a blank frame.

Rename the state to something the rest of the team will recognise — success, loading, cart-empty. State names appear in transitions and in the Play URL, so they're worth picking deliberately.

Wire a transition

A transition has three pieces: the element you click, the event name, and the destination state. To connect a button on screen A to screen B from the canvas:

1. On screen A, click the button to select it. In the Properties panel, set Transition to a name — submit works for most cases.
2. In the sidebar's Transitions section, add a new transition: from screen A, on submit, to screen B.
3. Click the Play button in the top-right toolbar. Play opens in a new browser window — click the button and the canvas advances to screen B.

Try it

Click the Play button in the toolbar to open the prototype in its own window. Every state is reachable; clicking any element with a transition on it advances to the destination state. Close the window when you're done to keep editing.

Play URLs are shareable as-is — send one to a stakeholder and they see the same click-through experience, no editor chrome, no sign-in. See Share with users and colleagues.

Common shapes

• Two-step form. idle → submit → success. The simplest flow, and the one most onboarding tutorials end up modelling.
• Multiple destinations from one screen. A login screen with login, signup, and forgot-password transitions, each pointing at a different state. Add three transitions from the same screen, one per element.
• Self-loops. A retry button in an error state that transitions back to loading — same source and destination state isn't allowed, but you can transition back to whatever started the flow.
• Branching on outcome. One loading state with two outgoing transitions: resolved → success and rejected → error. Click whichever element represents the outcome you want to demo.

What's next

Once the click-through works, show every state of the feature so a reviewer can see loading, empty, and error — not just the happy path. To send it out, see Share with users and colleagues. The deeper reference for the underlying model is in States & transitions.

<sync-folder>/<workspace>/
  <project-slug>/
    project.json              # project metadata
    transitions.json          # source/destination/event triples
    _status.md                # last render verdict from the canvas
    states/
      _order.json             # state order + display names
      idle.jsx                # one file per state
      submit.jsx
      success.jsx
    canvas/                   # off-graph scratch states (see below)
      _order.json
      sketch-1.jsx

<Button data-transition="submit">Place order</Button>