/figma-canvas-authoring

name: figma-canvas-authoring
description: >-
  Legacy compatibility entry. Use only when design-in-figma is not installed; otherwise use design-in-figma.
  Create or update native, editable Figma designs with TemPad Dev MCP: screens,
  flows, components, and requested local design-system resources, including on
  an empty canvas. Use when asked to create, mock up, or edit native Figma layers, not Figma-to-code, critique
  without edits, or raw Plugin API automation.

Design in Figma

Deliver the smallest complete native Figma result that serves the user's situation. Keep the working experience in view as you research, compose, and repair. A successful tool call establishes a document change; the rendered result and its editable structure establish whether that change served the task.

Establish the task

Use the user's exact target and constraints. For an existing design, inspect `get_code` and its pixels before changing the composition; use `get_structure` for hierarchy, geometry, stable keys, or selected native facts. Write to a known page directly. Create or activate a page only when the task calls for it. Infer low-consequence gaps; ask when a missing decision would materially change the result. Keep unrelated account, filesystem, task, and page metadata out of product identity and content.

Require an editable Figma Design file and the intended tab's active MCP connection. Use the host's TemPad MCP tools for all canvas reads and writes. If unavailable, report the integration problem and stop. Do not launch the CLI, recreate its transport, use browser automation to set up the canvas, or emit raw Plugin API operations. Research and asset acquisition use the host's appropriate tools; website research uses the in-app browser when available unless the user selected another browser.

For new design work, call `manage_design_task` with `action: "begin"` before research or canvas work with a short task title and a fresh UUID `requestId`; reuse that UUID only to retry the same begin. Carry the returned `taskId` on related TemPad tool calls. The runtime handles status and placement feedback: do not report progress, send heartbeats, or choose coordinates for a placeholder. Use `list_design_sessions` when the intended Figma target is unclear, then pass its exact `sessionId` when beginning. Pausing a turn preserves the design task. Follow-up comments continue the same task, including after a completed pass while its review remains open. After completion, pause, or lease expiry, use `action: "resume"` with its latest `epoch`, carry the returned epoch as `taskEpoch`, and reread the affected canvas with `get_structure` or `get_code` before writing. Use `get_design_task` only when recovery needs the current state or epoch. Never replay a stale write. Stop in TemPad Dev permanently cancels the current task after any running operation settles. Never resume that cancelled task or automatically replace it. If further design work is necessary or the user requests it, explicitly use `action: "begin"` with a fresh requestId. No separate Figma unlock or new user turn is required. Done closes the review; a closed or replaced task cannot resume. Do not automatically begin a replacement for comments on such a task. Element feedback arrives as a numbered batch. Each item retains its file, page, and node identity from draft creation. Reread every target before applying the batch; do not substitute the current selection. Supported hosts receive submitted feedback through native conversation messages. Do not poll for it or set up a helper process or host control endpoint.

Begin without waiting to choose a canvas location. Once an existing design region is known, use `set_design_anchor` with its exact Frame node ID and `taskId`. Otherwise the first created top-level Frame anchors automatically. The region stays stable across reads and writes; call this tool again only to explicitly change design regions.

Ground and compose

For net-new or materially redesigned interfaces without an established system, read [style-grounding.md](references/style-grounding.md) and inspect relevant real product screens or a permitted implementation before the first Canvas write. The evidence must expose the interface relationships informing the new work. Search snippets, URLs, failed retrievals, and generated concepts do not establish a precedent. Subject imagery establishes its depicted content, not its surrounding application's design. Try another permitted source when retrieval fails; if none is inspectable, disclose the gap and stop. Supplied source pixels or implementation can satisfy this boundary; mechanical edits do not require unrelated research.

Resolve what the person needs to recognize or change, which content and states carry that work, and how the interface makes their consequences perceptible. Choose the screen or flow, visual language, density, and scrolling model from that situation. Use [visual-composition.md](references/visual-composition.md) when forming or reconsidering a composition. Familiar structures and distinctive ones both need a reason in the task. Research informs an independent solution; it does not authorize copying a composition or placing reference pixels on the canvas unless the user requested that treatment.

When selecting or changing fonts, or when script coverage is uncertain, read [typefaces.md](references/typefaces.md) to resolve candidates and native identities.

Choose representations by their role in the work. Once an image, icon, diagram, or visualization matters to the direction, read [visual-assets.md](references/visual-assets.md) and its selected branch. Do not silently replace the chosen content or medium to simplify sourcing or markup. For content-bearing graphics, preserve meaningful marks and editable relationships with native shapes, vectors, text, and groups; styled FRAME lookalikes do not acquire drawing semantics. Read [document-geometry.md](references/document-