/create-canvas

name: create-canvas
description: Build a freeform canvas to explore, compare, and iterate on anything.

Create canvas

Build a freeform workspace for exploration and iteration through conversation. The model changes content in source files. The canvas makes that content live, named, movable, and easy to reference.

Start with the project

• Read repository rules, routes, component APIs, themes, design tokens, and tests.
• Look for an existing canvas before creating another.
• Use the project's framework, components, typography, design tokens, themes, and access controls.
• Respect restrictions on edits, commands, and browser access.
• Ask before changing scope, adding dependencies, changing shared code, or exposing the canvas publicly.
• If safe isolation is unclear, ask before proceeding. Never mount an unsafe preview.
• Choose sensible defaults for other decisions. Do not ask the user to repeat clear requests.
• Keep canvas code together. Separate camera and placement logic from previews, test data, and their registry. Do not build a framework.
• Start with one safe live preview, a readable label, and a separate move handle. Make sure that it mounts.
• Add the registry and requested content next. Then add copying, camera controls, existing themes, and saved layout.

Keep content in source

A registry is a typed list of canvas items. Each entry defines a stable ID, unique readable name, component, safe test data, initial position, and dimensions.

• Keep the registry easy to find. Adding an item must not require changes to the camera or gesture code.
• Add, duplicate, rename, and remove items through source edits. Do not add runtime editor controls or delete shortcuts.
• Keep membership, names, dimensions, and implementations in source. Browser storage must not create or hide items.
• Never evaluate stored strings or model responses as code at runtime.
• Update the existing workspace for follow-up requests. Preserve names, IDs, positions, and unrelated experiments.
• If a reference is ambiguous, ask which item the user means.
• For “try another version,” preserve the original. Give each variation a new ID, unique readable name, and independent state.
• For “change this version,” update that item in place. Rename it only when asked.
• For removal requests, remove only the requested registry entry. Preserve shared components and unrelated work.
• When comparing one feature, keep other data, content, dimensions, and the global theme the same.
• For broader alternatives, name the layout differences. Do not create a full variant matrix unless requested.
• Place additions in nearby empty space using measured bounds. Reveal them with the camera without rearranging existing items or resetting the view.
• Preserve positions after content expansion, resizing, and reload. Allow intentional overlap. Keep move handles accessible when items overlap.

Keep the workspace quiet

• Fill the viewport with a plain background, subtle preview boundaries, and minimal fixed controls.
• Use each preview's intended dimensions. Do not stretch content into oversized frames.
• Do not add decorative cards, banners, or background patterns.
• Put each name above its preview, such as `Pricing card · compact`. Do not use vague names or opaque IDs as labels.
• Give the name button behavior without button styling or a separate copy button.
• Copy the exact name on click, Enter, Space, or touch. Do not copy an ID, code, or URL.
• Explain copying on hover and keyboard focus. Hover alone must not copy. Touch activation must not require hover.
• Use the clipboard API when available. Announce brief “Copied” feedback only after success. Keep the name visible during feedback.
• If clipboard access fails or is unavailable, offer selectable text. Do not crash or claim success.
• Put a visible move handle beside the label. The label copies without dragging. The handle moves the item, not its body.
• Convert pointer movement to canvas coordinates at the current zoom.
• Support keyboard movement on the focused handle. Provide visible focus and accessible instructions.
• Use `cursor: default` on canvas navigation surfaces and handles, including during gestures.
• Preserve native text, link, input, and resize cursors inside previews. Do not apply cursor rules to all descendants.
• Include pan, zoom, fit-all, reset-camera, one global theme selector, and saved layout.
• Use the existing theme API for light, dark, and named themes. Apply the same theme to canvas controls, previews, menus, and dialogs.
• Do not invent themes or add per-preview themes. If themes are unsupported, omit the selector and explain why.
• If portal themes fail through public APIs, report the limit.
• Unless requested, omit resizing, width presets, comparison arrangements, drawing, connectors, catalogs, property editors, multi-selection, snapping, and undo/redo.
• For requested mobile or desktop previews, define their dimensions in the registry.

Preserve live content

• Reuse production components through public APIs. Do not change their source, exports, hooks, or styles to support the canvas.
• Keep production components independent of canvas code.
• Keep experiments local to the canvas. Move them into production only when asked.
• Before mounting, use synthetic data, mock services, safe providers, and existing callbacks to prevent real requests and writes.
• Never use personal data or production credentials.
• If safe isolation is unavailable, omit the preview and explain why. An iframe or separate document alone does not provide isolation.
• Preserve clicking, typing, text selection, shortcuts, focus, nested scrolling, and touch input.
• Preserve the real behavior of disabled and read-only examples.
• Do not remount previews or erase input when moving items, copying names, changing themes, or changing the camera.
• Preview drafts do not need to survive reload.
• Keep portals in their native roots at screen-space size. Let the library manag