--- name: building-canvases description: > Create or edit a PostHog canvas — a sandboxed browser application (data board, document, form, small tool, graphics experiment) stored in PostHog and rendered by the desktop/web app. Use when a task asks to build, generate, update, or fix a canvas, or when a canvas id is given as the publish target. Covers resolving or creating the target canvas, choosing an implementation approach (React + Quill vs plain HTML/browser APIs), the read → edit → validate → publish → build loop, and which companion canvas skills to load for the details. --- # Building canvases A canvas is a client-side browser application that runs in a sandboxed iframe inside PostHog. Its source lives in PostHog — not in a repository — and you read and write it through the `canvas-*` tools. Never write a canvas to a local file; publishing through the tool is what saves it. ## Resolve the target canvas - If the task names a canvas id (canvas-initiated tasks do), that is the target. Do not create another. - Otherwise — channel-composer tasks give the channel, not a canvas — list the channel's canvases with `canvas-list` (scope with `channel`; resolve a bare channel name with `channel-list` first). If one is clearly what the request refers to — an earlier iteration of the same board or tool — build on it instead of creating a near-duplicate, and say so in your reply so the user knows where the result landed. - Only when nothing existing fits, create one with `canvas-create` in the right channel, named with a short descriptive title drawn from the request — never "Untitled canvas". ## Choose the least complex implementation that meets the request - **React + Quill** — PostHog data products, dashboards, forms, application-like state, and anything that should look native to PostHog. Load the `building-react-quill-canvases` skill. - **Semantic HTML, CSS, and direct browser APIs** — static documents, focused experiments, generative graphics, `