Design canvas loop

The canvas is the working surface. A .tsx file (React 19, transpiled by Bun), under .design/<project-or-feature>/. Commands iterate in place on the active canvas (the one open in the project tab), so feedback like "move the CTA up" lands on the file you're looking at, not a new mock somewhere else.

A Bun dev server mounts every canvas in a shared shell. A canvas opens live in Preview mode — click buttons and links to try the mock. Switch to Edit and press V for the Select tool, then click any element to select it (⌘/Ctrl-click reaches the deepest element, double-click drills in one level) and scope the next /design:edit "<feedback>" to that selection. The server tracks the active tab and your selection over WebSocket and writes <designRoot>/_active.json for the slash commands to read.

INS

MDCC-DGM/INSInspectorDiagram

localhost:4711

A · hero

B · pricingplan card

C · footer

• Cmd+Click the element
• selection persists to _active.json
• /design:edit reads from here

Design commands

Setup verbs prepare the project; daily verbs cover canvas editing, drawing, media, import and export. smoke catches regressions. The generated command index lists the current set. The bare /design form was a v0.8 one-version compat stub redirecting to /design:edit. Removed in v0.9.

Setup. One-shot bootstrapping.

LP

MDCC-DGM/LPLoopDiagram

canvas loop/design:*

initone-time

setup-dsdesign system

newscaffold canvas

edititerate in placeactive

criticpanel review

handoffship to code

repeatnext surface

Daily. The canvas loop.

Validate.

Edit directly in the window

Not every change needs a command. Maude carries a built-in editor for small, precise tweaks — and it writes straight back to the source .tsx, so there's no AI round-trip and nothing to reconcile. (Where each control lives is on Around the window.)

Press V for the Select tool, then click any element to select it (plain click = the top-level object, ⌘/Ctrl-click = the deepest element, double-click drills in, Enter/Shift+Enter/Tab walk the tree, Esc steps back). The Inspector comes with the selection and speaks designer: position, size, layout, fill, type, border, effects. The Layers tab of the left panel (Canvases · Layers · Assets) is the browsable tree of the artboard's elements with type icons — including group rows for wrapper <div>s, so nothing nests at the wrong depth. Component instances render purple (◆ the instance root, ◇ its members) with the component's name. Click to select, hover to highlight, toggle visibility, lock a layer (a locked layer can't be selected or dragged on the canvas — unlock it from its row), or double-click its name to rename it (written back to the source as data-dc-element).

The code is one fold away: open the Inspector's › Advanced and it adds the element (tag, classes, selector, id), where it is used, the tokens bound and the raw CSS rows — the same rows an agent edits. There is no separate setting to flip; the frame is the designer's view and the fold is the code.

The CSS token editor

The CSS rows under Inspector › Advanced are a real token editor, not a textarea:

• Figma-style rows. Each property leads with a glyph. Numeric fields scrub left/right to change (or you type the value), and spacing fields accept Webflow-style modifiers.
• Bind to a Variable. Click a field's token chip to open a popover with two tabs — Custom for a literal value, Variables for the design system's tokens. The list is searchable, and each Variable shows its provenance so you know where it's defined. Multi-DS projects resolve the right system, and applying a token works across design systems.
• One colour picker. Every colour field — fill and border alike — opens the same Figma-style picker: Custom (saturation/hue area, opacity, eyedropper, Hex · RGB · HSL, colours on this page) and Libraries (the design system's colours as a list of named rows). A fill adds Solid · Gradient · Image — drag a gradient's stops, and pick an image from your Assets, a file or a link.
• Scannable diff. Values you've set stand out; untouched rows recede, so the difference from the default is obvious at a glance. The leading dot on each row carries its status and resets it.

Edits commit on blur and write back to the canvas source, so what you see in the browser is what's in the file.

Edit text in place. Double-click any text element to retype its copy directly on the canvas — the new string is written back to the source too.

Convert children to absolute position. When a generated flex or grid layout fights your manual tweaks, right-click the container and choose Convert children to absolute position (Figma's "Remove auto layout"). Every child's box is frozen where it currently sits — rewritten to position:absolute — so you can drag them anywhere. One undo reverts the whole conversion. Works on plain containers; repeated (list) or component children are left alone.

Dev server runtime files

The server writes three runtime files into <designRoot>/ that orchestrator commands rely on:

SRV

MDCC-DGM/SRVDevServerSchema

_server.json

pidnumber

portnumber

urlstring

startediso-8601

_active.json

activepath

open_tabspath[]

selectedelement | null

last_changeiso-8601

_history/<slug>/

000-envelope.mdbrief

NNN-screen-*.pngsnapshot

chat.mdtranscript

server writes

inspector pushes

rollback reads

Dev-server runtime files — keys and roles

File	Keys	Role
_server.json	pid (number), port (number), url (string), started (iso-8601)	Written by the dev-server; read by the orchestrator to detect a live instance.
_active.json	active (path), open_tabs (path[]), selected (element | null), last_change (iso-8601)	Pushed by the injected inspector; read by /design:edit to scope the next edit.
_history/<slug>/	000-envelope.md (brief), NNN-screen-*.png (snapshot), chat.md (transcript)	Auto-snapshot stack per canvas; read by /design:rollback.

These are user-facing runtime state. Schemas are kept backwards-compatible across releases.

When to use which

• Bootstrap a new project. /design:init, then /design:setup-ds <name> "<brief>"
• Generating new mock. /design:new
• Iterating on what's on screen. /design:edit
• Second opinion without editing. /design:critic
• Locked-in design. /design:handoff migrates it to production code
• Undo. /design:rollback
• Browse all canvases at once. /design:browse (or the Canvases panel in the app)
• Forgotten a command name. /design:help

Design system

A project's design root holds:

• .design/system/. Tokens, type, color, radii, shadows, density, layout constants. Auto-loaded whenever Claude generates, reviews, or migrates UI in the repo.
• .design/ui/. Reference UI prototypes and shared components (desktop / mobile / tablet).

These are pointed at by the design-system and ui-kit skills, also auto-loaded.

Driving Maude from Claude Code

Claude Code, Codex and the AI chat panel work the same way: files are the API. A canvas is a .tsx under .design/, its layout and notes sit in the sibling .meta.json, annotations are *.annotations.json. Claude edits those files directly (with Edit, not a whole-file Write) and runs a maude design <verb> for what a file edit cannot do: rendering and export, generation, sync, Version history, the trash, opening something in the window, and checks.

• Every write is checked. A change under .design/ runs maude design check --strict and the file is restored if the check fails.
• Every verb has a tier. maude design help prints it. auto verbs run without a prompt in the AI chat panel, prompt verbs show a permission card, and human verbs (accounts, hub, install) are terminal-only.
• One lookup for any capability. The studio-actions skill, generated from Maude's action registry, names the file to edit or the verb to run for each thing the window can do.
• Selection is shared. <designRoot>/_active.json holds the open canvas and the selection, so "make this wider" lands on the right element.
• Other people's text is data. history, comments and exports wrap it in UNTRUSTED DATA markers; it is never an instruction.

Moving a project from Maude 1 is maude migrate v2 (dry run first). See Coming from Maude 1. The checks on a design system are in the Design-system schema.

Configure

Per-repo behavior lives at .design/config.json (handoff targets, opt-out scopes per canvas, the design-system list, theme, tokens path). It's written by /design:init and /design:setup-ds. See Bootstrap for the full shape and Multi-DS for the designSystems[] layout.

TR

MDCC-DGM/TRCommandTree

/design:

daily.every feature cycle

├─assets├─board├─browse├─chat├─comments├─critic├─draw├─edit├─export├─generate├─handoff├─help├─history├─import├─new├─open├─photo├─present├─reel├─rollback├─screenshot├─system├─to-lottie├─to-rn├─trash└─video-analyze

setup.run once

├─init├─setup-docs└─setup-ds

validate.regression gates

└─smoke

hub.

└─hub-workspace

31 commands · grouped in CATEGORIES.md