Design overview

The design surface in Pathrule Studio is where a sentence becomes a real screen. You describe what you want, Studio builds it on a canvas, and you refine it by pointing at a layer and saying what should change. What comes out is a design document, not a picture: every layer has a stable identity, styles resolve through your tokens, and repeated structures stay components.

That matters because the design is also an input. Your coding agent reads it to implement it, and reads it again to check its work, so the design has to state intent that survives translation into SwiftUI, Compose, or a React tree.

What a design is made of

• Documents and screens. One document holds the screens that belong together. Each screen has an authored canvas size and sits on a shared plane.
• Layers with stable ids. A layer keeps its identity across edits, which is what lets an agent fix "the layer the finding named" instead of guessing at coordinates.
• Tokens, not literals. Colour, spacing, and type resolve through token variables so a change at the source moves every screen that uses it.
• Components and instances. A repeated structure is a component with properties and variants, and each use is an instance that can swap content without drifting from the original.
• A medium. A design is authored for web, iOS, Android, a social format, or an editorial page. The medium decides the grid, the safe zones, and which primitives are appropriate.

Design intent, not markup

An agent never plans from a screen's stored HTML. A production screen runs close to a megabyte, and reading it pushes an implementation toward writing CSS even when the target is SwiftUI or Compose.

Instead, the design is read as intent, in slices:

• The index lists every document and screen with node, instance, and token counts, plus the flow node for a screen that belongs to a journey.
• A screen returns box, layout direction, sizing, resolved appearance, token variables, component instances, and text, per node.
• A node drills into one subtree when a screen is too large to hold at once.

The single most important field in that payload is sizing. fill means a node takes the space its container gives it, hug means it wraps its content, and both are relationships that survive a device nobody drew. fixed is a number that only holds at the width the design was authored at. An implementation that turns fill into a pinned width because the design happened to be drawn at 402px looks correct in review and breaks on the next phone.

Readiness: what the design does not say

Every document reports whether a design system is attached, and every screen reports how much of itself is actually bound: how many distinct colour values are literal rather than token-bound, how many repeated structures were drawn by hand instead of as components, and whether the screen sits in a flow.

This exists so that an implementation can be honest. With no bindings available, the right move is to implement from the project's own tokens and list every unbound value in the run summary. Inventing a binding, or silently baking a literal, is what turns a design system into decoration.

Working on several screens at once

A document can run up to three design pages concurrently, each with its own AI turn, its own pending question, and its own recovery. A failure on one page does not reload another, and a style you paste is scoped to the page you pasted it into.

What to read next

• Bringing a design in from Figma for the transfer path and what survives it.
• Flows and prototypes for wiring screens together and playing the result.
• Verifying a design against the running app for the finish condition.
• Sharing a design for the encrypted public link.