create_artboard
ChatGPTCreates an artboard from the root JSX in code. The canvas is a whiteboard: one artboard holds one design. A set of separate items (options, concepts, logos, icons, illustrations, empty states, a component's states or variants, moodboard images) is one artboard per item, sized to that item and laid out side by side, never wrapped in a board, sheet, showcase or page frame and never given a page skeleton, title header or viewport. A group's caption is its own small text artboard. One frame holds several items only when the user asks for one composed piece (a slide, a poster, a diagram) or a library import's Design Guide nests them. A page with several sections starts as a two-level skeleton: the root holds one placeholder div per section, and each section holds placeholder divs for its parts, all sized and laid out (w-, h-, min-h-, flex, grid, gap) with no visual style and a specific Title Case label each that names the part it becomes (Plan Columns, never Plan Columns Skeleton), so the user sees the structure while you build. When unsure whether it is a component or a page, add the skeleton. The directives that build a section replace or delete its skeleton placeholders, so none survives next to real content. The result holds a tree per created or changed element, one line per element with its tag, data-node-id and data-node-label, and every id the document assigned: target those ids next without another read. A tree longer than 300 lines comes back as its root line plus "… N more elements — read the tree with get_element_tree"; read it before building into it. Its first line is the artboard root, which you build into with update_elements. Colour: a file token's cssVar, created first if none holds the value; a literal or palette class only if the user asks. Other values a token holds use its cssVar too. Icons: the file's library (import { X } from 'wonder-icons'), else react-icons, imported at the top; never emoji.
create_design_tokens
ChatGPTCreates design tokens in the file. All or nothing: an entry that fails changes nothing, and the result names it. An alias names a token of the same type, existing or earlier in the call. Where the source layers semantic names over a raw palette, keep both layers: create the raw token first, then the semantic token as its alias, never flattening the reference to its resolved value. Returns the created names and the file's tokens with each cssVar. Check the file's tokens and icon catalog before adding to them, and reuse a match by value and by role instead of adding a near-duplicate or a literal beside it.
create_file
ChatGPTCreates a Wonder design file on the server and returns its fileId, first pageId, branchName and a url for your reply; nothing opens on the user's screen. Never create a Wonder file on your own, even when no file is attached or open: create one only when the user asks for a new file or picks one when you ask. When the request names no file and none is open, look through the user's files with list_files for the file and page the work fits best, then ask where it should go with your host's question tool, falling back to your reply only when it has none, offering that place, another of their files and a new file (one choice per organization when they have more than one). It goes into organizationId, else nearFileId's organization, else the user's only one; when several fit and you named none, the result lists them. Rename it later with rename_file. Files cannot be deleted here: the user deletes them in Files.
create_folder
ChatGPTCreates a folder in the user's Files, at the organization's root or inside parentFolderId, and returns its folderId for create_file. Create one when the user asks, or when their files already live in folders (folderName in list_files) and the file you are about to create belongs in one that is missing. The organization is chosen as for create_file.
create_icons
ChatGPTAdds up to 20 icons ({ name, svg, keywords? }, markup within 500000 characters in all) to the file's icon library. The server sanitizes each svg: a viewBox is kept or synthesized, and monochrome paints become currentColor. Returns created names, skipped duplicates and per-item errors. Bind an icon by the componentName the catalog returns, never one built from its name: a name collision adds a suffix and a rename changes it, so read the names back after creating, importing or renaming icons. Check the file's tokens and icon catalog before adding to them, and reuse a match by value and by role instead of adding a near-duplicate or a literal beside it. Rename or delete tokens and icons only when the user asks, and add an icon only when the user asks or a design built from their code needs it.
create_page
ChatGPTAdd a page to a Wonder file, named by its fileId or by the pageId of any page in it. It runs on the server and needs no editor, and it never moves anyone's view: everyone who has the file open sees the new page appear in their page list and stays on the page they are on. The answer carries the new page's pageId, which every page-scoped tool takes at once. Put new canvas work on its area's page: the page you hold when it fits, else the file's page for that product area, flow or kind of work, even under a broader name. Add a page only when the user asks or none covers the area, and make it the page for the whole area, not this one design.
delete_design_tokens
ChatGPTDeletes design tokens by name. All or nothing: an entry that fails changes nothing, and the result names it. Deleting a token or icon unbinds its uses: bound elements keep the last value or markup and stop updating, and tokens aliased to a deleted token fall back to its value. Returns the deleted names, the count restyled and the remaining tokens. Rename or delete tokens and icons only when the user asks, and add an icon only when the user asks or a design built from their code needs it.
delete_elements
ChatGPTDeletes elements with their whole subtrees; an artboard root's id deletes the artboard. Pass every id in one call. Returns a result per id.
delete_icons
ChatGPTDeletes icons from the file's library by name. All or nothing: an entry that fails changes nothing, and the result names it. Deleting a token or icon unbinds its uses: bound elements keep the last value or markup and stop updating, and tokens aliased to a deleted token fall back to its value. Returns the deleted names and the remaining catalog. Rename or delete tokens and icons only when the user asks, and add an icon only when the user asks or a design built from their code needs it.
duplicate_elements
ChatGPTDuplicate an element and its entire subtree. The source may be an in-tree element or an artboard root: the subtree is what gets copied, and only where the copy lands differs. Copies of a component the source code reuses, and more copies of an element already on the canvas, are built once and placed with one duplicate_elements call whose propertyOverrides vary each copy's text and className; never write the same element out by hand at each place. Repeated items in a new design (cards, rows, features) are one .map() over an inline data array in a single insert, with the layout classes on the div that wraps it. On a new artboard, placement attributes apply to its root element only, never to a nested label. An artboard-root source with targetParent and position nests its subtree under the target. A variation is a copy of the original placed as its own artboard (duplicate_elements with newArtboard true) and changed there, so it sits beside the original for comparison and never replaces it. The result holds a tree per created or changed element, one line per element with its tag, data-node-id and data-node-label, and every id the document assigned: target those ids next without another read. A tree longer than 300 lines comes back as its root line plus "… N more elements — read the tree with get_element_tree"; read it before building into it. It returns {"trees": [...], "newDuplicateIds": [...]}: one tree per copy, never the container the copies landed in, and trees[i] belongs to newDuplicateIds[i], each copy's root id in copy order. When the copies' trees pass 1200 lines together, every tree comes back as its root line, and trees past even that are replaced by one final "… N more trees — read them with get_element_tree" entry. A copy that could not be read back holds its place with a one-line note naming its id.
fetch_image_content
ChatGPTReturns an image's pixels as base64 with its contentType, so you can look at it. Pass assetId or a public url. When a text summary is enough, fetch_image_description is cheaper.
fetch_image_description
ChatGPTReturns a text description of an image: cheaper than its pixels when you only need to know what it shows. Pass assetId or a public url. Image generation and vectorizing read a reference image themselves, so hand them the image (one the user attached or selected, one generated earlier in this conversation, a search result, or an image URL in element code), never its description, and never run fetch_image_description on it first.
find_elements
ChatGPTFinds elements by free-form queries ("hero section", "button that says Sign Up", "green rounded card"), several per call, each ranked on its own against labels, span text and className tokens. Each match carries an ancestry breadcrumb, and its JSX too with includeCode. Use it when you know what an element is but not its data-node-id.
finish_artboard
ChatGPTMarks an artboard you created or changed as finished and returns its design link. It changes nothing on the canvas: your edits were saved as they ran. Call it once per artboard, after its last edit, and never for one you only read.
generate_image
ChatGPTGenerates a raster image from a prompt and, unless placeOnCanvas is false, places it on the canvas as a new artboard. Returns the image URL, its size and the artboard's dataNodeId. Optional imageUrls guide a remix or a style. Photos and other raster images come from generate_image, a new vector drawn from a description from generate_svg, and a vector traced from one supplied image from vectorize_image; offer generate_svg when the user wants a restyle rather than a trace.
generate_svg
ChatGPTGenerates a vector SVG from a prompt. Generating an SVG and vectorizing an image are for an explicit request (an SVG, a logo, a mascot or an illustration; trace, vectorize or convert this image): each takes 30 to 90 seconds and a paid model call, places its own artboard and returns the dataNodeId to continue from. A design's own imagery uses icons or photos instead. Optional references (up to 14) ground the style or subject. Photos and other raster images come from generate_image, a new vector drawn from a description from generate_svg, and a vector traced from one supplied image from vectorize_image; offer generate_svg when the user wants a restyle rather than a trace.
get_additional_context
ChatGPTReturns the surroundings of one or more elements: their artboard, depth, parent, siblings, children and subtree size. Use it to decide whether to read deeper with get_element_tree or get_element_code. Unknown ids come back as error entries.
get_artboards
ChatGPTLists the page's top-level artboards with data-node-id, label, position and size (x, y, width, height in canvas pixels, y downward), descendant count and depth, and up to 8 top-level children. A null x, y, width or height is unknown, not zero: the editor has not measured that artboard yet, so read it again with get_artboards once it has rendered. The coordinates are the ones data-component-x and data-component-y take on an artboard root, so you can place a new artboard or move one by editing its root. Reusable components nested inside a container are not listed; find them with find_elements.
get_basic_info
ChatGPTRefreshes where the user is: email, organization, open file, page, branch and selected elements, plus the file's pages and openFiles (every open file with its own pageId; one is focused). Open a task with get_design_context and use this for cheap refreshes, such as before acting on the selection. It answers for the pageId or fileId you pass, else the file the user is viewing, and never fails on a page mismatch, so it also finds a file that moved.
get_design_context
ChatGPTOpens a canvas task in one call: user, organization, file, page, branch, selection, the file's tokens and icons, every artboard on the page with its geometry, and the design fundamentals. Pass guidelines: "none" when the task draws nothing on the canvas (it only reads it, or is code work); keep the default whenever it ends in something drawn, including a component built from code. Without a pageId it answers for the page the user is viewing; with no Wonder tab open, find the file with list_files and open_file first. Optional style adds that style's guidelines. A section that fails is reported on its own. The response includes openFiles: every document open in the editor, each with its own fileId, branchName and pageId. The entry marked focused is the one the user is looking at. A one-entry list is normal, not a degraded state. Two entries can share a fileId when the user has the same file open on two Wonder file branches; those are separate documents, so read branchName before choosing between them. The response also carries pages: every page of the file that answered, each with its id and name. Those ids appear nowhere else, so this is how you reach a page other than the one you are on. Pass one of them as your pageId to read or edit that page; any page is yours to work on, including one the user is not looking at. To read another file's pages, pass that file's pageId; the same call is then answered by that file and returns its pages instead. REPRODUCING CODE: before the first call that brings a screen, component or library from the user's code onto the canvas, load the code-to-design skill with get_skills. It carries what makes the result match the app instead of resembling it.
get_design_guidelines
ChatGPTReturns the design fundamentals and, with style, one style's detailed guidelines. Call it when the call that opened the task did not include the fundamentals, or once you have chosen a style. Styles: academia, art-deco, bauhaus, bold-typography, botanical, claymorphism, cyberpunk, enterprise, flat-design, glassmorphism, industrial, kinetic, luxury, material-design, maximalism, minimal-dark, modern-dark, monochrome, neo-brutalism, neumorphism, newsprint, organic, playful-geometric, professional, retro, saas, sketch, swiss-minimalist, terminal, vaporwave, web3.
get_design_tokens
ChatGPTReturns the file's design tokens: { tokens: [{ id, name, type, value, cssVar, aliasOf? }] }. Write a token by copying its cssVar exactly as the token read returns it: token brand/primary is var(--brand-primary), never var(--brand/primary), which does not resolve. Read them before creating tokens or writing a value a token may own, unless you already hold the current list. Check the file's tokens and icon catalog before adding to them, and reuse a match by value and by role instead of adding a near-duplicate or a literal beside it.
get_element_code
ChatGPTReturns the React+Tailwind JSX of one or more subtrees, one entry per id in order; an artboard root returns the whole artboard. depth caps the levels below each root. A subtree past the per-read ceiling is refused in that id's entry, which says what to pass instead: a depth for its upper levels, a smaller depth, or one of its children. Read a large element with a depth first and descend by id. The elements-omitted markers of a depth-bound read may count only the next level: when the document holds more below the cut than they say, the result's warnings give the true count of elements and levels, hidden ones included, and the depth or element to read next. Every byte you read stays in context, so request the narrowest subtree that answers the question, and use get_element_tree for structure alone. To build a design in the user's code, load the design-to-code skill: this JSX is a visual spec, not code to paste.
get_element_tree
ChatGPTReturns an indented tree of one or more subtrees, one line per element with its tag, data-node-id and data-node-label: cheaper than code, for finding ids and structure. A subtree past the per-read ceiling is refused in that id's entry, which says what to pass instead: a depth for its upper levels, a smaller depth, or one of its children. Read a large element with a depth first and descend by id. The elements-omitted markers of a depth-bound read may count only the next level: when the document holds more below the cut than they say, the result's warnings give the true count of elements and levels, hidden ones included, and the depth or element to read next. Your own create and edit calls return trees already. The result holds a tree per created or changed element, one line per element with its tag, data-node-id and data-node-label, and every id the document assigned: target those ids next without another read. A tree longer than 300 lines comes back as its root line plus "… N more elements — read the tree with get_element_tree"; read it before building into it. Read the tree for elements you have not seen this turn or after the user reports a problem. Use get_element_code for the JSX.
get_icons
ChatGPTReturns the file's icon library without markup: { icons: [{ id, name, componentName, colorMode, keywords? }] }. Place an icon with import { componentName } from 'wonder-icons'. wonder-icons imports and Wonder's own var(--…) token names exist only inside Wonder: never write them into code the user ships. Pass names to get those icons' svg and viewBox; unknown names come back under missing, and icons too large for one answer under omitted, to request again in smaller groups. Read it before placing icons, unless you hold the current catalog. Check the file's tokens and icon catalog before adding to them, and reuse a match by value and by role instead of adding a near-duplicate or a literal beside it.
get_skills
ChatGPTLoads the instructions for one design job. When you're about to create or change a Wonder design, or build one in code, call it with the skill that matches: - code-to-design: bring a screen or component from the user's code onto the canvas, or refresh one after the code changed. - design-to-code: build a canvas design in the user's code. - new-design: design a new screen, component, set of items or variations from a prompt. - edit-design: change, fix or give feedback on an existing design beyond a quick text, color, spacing or icon tweak. - design-library: create or change the file's design tokens or icon library. - generate-assets: generate an image or an SVG, or vectorize an image. A skill names the supporting skills it needs; load one by name when the work reaches it.
get_wonder_info
ChatGPTLoad information about Wonder as a product and platform. Call this before answering any user questions about what Wonder is, what it can do, or how it works.
list_file_move_destinations
ChatGPTList the workspaces this file can move into, considering your permissions, each workspace's plan limits and its file limit. Requires owner or admin access in the source. Pass a returned id as destinationOrganizationId to move_file.
list_files
ChatGPTLists every Wonder file the user can open across their organizations (in a worktree given its own files, only those), with id, name, organization, and folder when it has one. Pass nameContains when the request names a file. Open one with open_file and its fileId. It needs nothing open; which files are open comes from openFiles in get_design_context.
move_file
ChatGPTMove a file to another workspace, preserving its ID, pages, branches and history. Requires owner or admin access in the source and editor access in the destination. The file goes to the destination root, loses its pin and GitHub repository connection, and uses the destination's access, plan limits and file limit. Get an eligible destination from list_file_move_destinations.
move_page
ChatGPTMove a page, named by its pageId from the page list get_basic_info returns, to another place in its file's page list: right after the page afterPageId names, or to the position index gives. It runs on the server and needs no editor, and it never changes the page anyone is looking at. Reorder pages only when the user asked you to.
open_file
ChatGPTGet the landing page of any Wonder file the user can reach, so you can work on it. Takes the fileId from list_files. Returns the file's pageId and branchName, which you pass to every page-scoped call on that page exactly as if the file had been open all along. Canvas, token and icon tools run on the server with a pageId: no file needs to be open in an editor, open_file opens no tab, and nothing changes on the user's screen. The answer's note says so.
prepare_image_upload
ChatGPTReturns a one-time upload URL for an image on the user's machine. Upload the original file's raw bytes to uploadUrl with the returned method right away, since it expires in minutes: curl -sS -X PUT --upload-file "/path/image.png" "<uploadUrl>". The upload answers with a cdn.wonder.so imageUrl to use as an image source in update_elements. An image already on the public web needs no upload.
rename_elements
ChatGPTSets data-node-label on elements, several per call; renaming an artboard root renames the artboard. Rename only when the new label says more than the current one; a label that already names the element's role and content stays as it is.
rename_file
ChatGPTRename a Wonder file by its fileId. It runs on the server and needs no editor, and everyone who has the file open sees the new name. Rename it only when the user asked you to, or when you created it and its name no longer fits what it holds.
rename_page
ChatGPTRename a page of a Wonder file by its pageId, from the page list get_basic_info returns or the answer of the create_page that made it. It runs on the server and needs no editor, and everyone who has the file open sees the new name. Rename it only when the user asked you to, or when you created it and its name no longer fits what it holds.
take_screenshot
ChatGPTReturns an image of one element exactly as the canvas renders it: to see what your edits produced, or to read a design you are building in code. After the last edit to an artboard you built or changed, screenshot it once before finish_artboard, and once more after each fix; at most 4 per artboard, one call at a time.
update_design_tokens
ChatGPTChanges existing design tokens: each entry names a token and sets a new value, a new aliasOf (same type, no cycle), a newName, or a rename with one of the other two. All or nothing: an entry that fails changes nothing, and the result names it. A token or library icon is one definition with many bound uses: changing it restyles every element bound to it on every page, other designs included. Change the definition only when the user wants the change everywhere, and ask first when a restyle would need a token other designs use. Returns the updated names, the count restyled and the file's tokens. Rename or delete tokens and icons only when the user asks, and add an icon only when the user asks or a design built from their code needs it.
update_elements
ChatGPTEdits one artboard with JSX comment directives, each followed by its payload if it has one. The result returns each directive's touched tree with every data-node-id. Directives (X and Y are data-node-ids you have read): - {/ insert after X /}, {/ insert before X /}, {/ insert as first child of X /}, {/ insert as last child of X /} + one new element without a data-node-id, children nested inline. - {/ edit X /} + one self-closing element of X's kind: sets X's attributes, keeps its children. Omitted attributes keep their value; a declared className replaces the whole list. A leaf span may carry new text. - {/ replace X /} + X's full new subtree; children left out are removed. - {/ delete X /}, {/ move X after Y /}, {/ move X before Y /}, {/ move X to first child of Y /}, no payload. {/ insert as last child of hero /} <div data-node-label="Get Started Cta" className="flex gap-2 bg-[var(--brand-primary)]"><span data-node-label="Get Started Cta Text">Get started</span></div> A call cannot target an element it creates. The user may edit between turns: before your first edit or replace of an element in a turn, read its code with get_element_code and keep what the request leaves alone. Markup: div; span for all text; img (stock photos: images.unsplash.com); svg inside a labeled div, no text in it. Static Tailwind className (no md:/lg:). A Title Case data-node-label on every element. Colour: a file token's cssVar, created first if none holds the value; a literal or palette class only if the user asks. Other values a token holds use its cssVar too. Icons: the file's library (import { X } from 'wonder-icons'), else react-icons, imported at the top; never emoji. A refusal names the rule to fix. Directives apply when the call returns: build a new design one section per call, replacing or deleting each skeleton placeholder in the call that fills it. Wait for each call to return before the next on the same artboard.
update_icons
ChatGPTRenames library icons or replaces their keywords. All or nothing: an entry that fails changes nothing, and the result names it. Placed instances keep their binding and markup. Returns the updated names and the catalog. Bind an icon by the componentName the catalog returns, never one built from its name: a name collision adds a suffix and a rename changes it, so read the names back after creating, importing or renaming icons. Rename or delete tokens and icons only when the user asks, and add an icon only when the user asks or a design built from their code needs it.
vectorize_image
ChatGPTTraces one supplied raster image into a clean SVG; there is no prompt. Generating an SVG and vectorizing an image are for an explicit request (an SVG, a logo, a mascot or an illustration; trace, vectorize or convert this image): each takes 30 to 90 seconds and a paid model call, places its own artboard and returns the dataNodeId to continue from. Photos and other raster images come from generate_image, a new vector drawn from a description from generate_svg, and a vector traced from one supplied image from vectorize_image; offer generate_svg when the user wants a restyle rather than a trace.
