Design

Design overview

The Pathrule Studio design surface turns a sentence into a real, editable design that carries your project's tokens and components, and that your coding agent can read as intent instead of as a wall of HTML.

Ask ChatGPT Ask Claude View as Markdown

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.

Use the surface the work needs

Design is a Studio surface for design-led work, not a prerequisite for using Pathrule. A coding-only team can stay in Chat, Tasks, source control and the terminal. When a task does start from a design, the handoff carries the same product context forward instead of asking the team to maintain another summary.

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 appearance-specific markup

An agent reads structured intent rather than appearance-specific markup. That keeps implementation grounded in layout relationships and the target platform, whether the output is SwiftUI, Compose or a React tree.

The design is read in focused 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.