/page

name: page
description: Build and publish a self-contained HTML page to Superset, then answer the comments readers pin to it. Use when the user asks to make or publish a page, turn a report, dashboard, chart, doc, or analysis into a shareable link, update or re-version a page already published, or work through comments left on one, including "make me a page for this", "publish this as a page", "share it as a link", "add a version", "address the comments on that page".
argument-hint: what the page should show, or a page id/slug to update
allowed-tools: Bash(superset:*)

Superset Pages

A page is an **`.html` document** published to a URL people in the org can open. Publish a single file and it must be self-contained; publish a directory and its `index.html` is the document, with the images, stylesheets, and media it references by relative path published alongside it. Every publish mints a version, so a page has history. Readers can pin a comment to any element on it, and those comments come back to an agent to fix. That is what makes a page a working surface rather than an export.

Pages are served from their own origin under a strict content policy. Most of the work in this skill is respecting that policy; a page that ignores it looks fine locally and breaks silently once published.

When a page is the right surface

Publish a page when the work has a **reader** and wants a **link**: a report someone will skim, a dashboard for a standup, a comparison table, a diagram, a walkthrough of what you changed.

Other skills produce exactly that and stop at the terminal. A standup digest, a summary of a parallel run across several workspaces, a feature scorecard, the screenshots from a browser or desktop verification: each has a reader who is not in the session, and each is better as a link than as scrollback. Recurring ones gain the most, since republishing versions one page rather than littering the org with a new one every day. That only holds when the workspace and the path both stay the same, which is the identity of a page: a job that runs somewhere new each time needs `--page <id>` instead.

Don't publish when the artifact belongs in the repo (source, docs, config: put those in files and commit them), or when it genuinely needs a server, a database, or a login. A page has none of those.

If you're unsure, ask. Publishing is cheap and reversible, but a page the user didn't want is noise in their org's list.

The content policy, which is what actually bites

Every page gets its own origin, `https://<pageId>.frame.supersetusercontent.com`, and is framed with `sandbox="allow-scripts allow-same-origin allow-forms allow-popups"`. So the page is a real origin of its own, and a locked-down one. The policy is `default-src 'none'` with a short allowlist, and it is enforced identically in the desktop pane and the web viewer:

• **No network from script.** `fetch`, `XHR`, `EventSource` and WebSockets are

all blocked, and so is `fetch("data:...")`: a page cannot read its own inlined data URIs back out. Write pages that need no network at all: bake the data into the document as a literal, or decode base64 in JavaScript (`atob`, then `Uint8Array.from`).

• **No compiling code at runtime.** `script-src` carries no `'unsafe-eval'`,

so `eval()` and `new Function()` both raise an `EvalError`. This rules out inlining any library that builds functions at runtime, which includes several chart and templating libraries and a number of date and expression helpers. Check for it before you reach for a dependency: the page renders nothing and gives no visible reason why.

• **No scripts or stylesheets from a remote host, with one exception.**

`<script src="https://…">` is always blocked. `<link rel="stylesheet" href="https://…">` is blocked too, except from `fonts.googleapis.com`, so a Google Fonts `<link>` tag works as-is. A directory publish's own files load fine (relative `src`/`href`), and any remote font *file* is allowed, so an inline `@font-face { src: url(https://…) }` also works for fonts from elsewhere.

• **Images, video and audio may be remote** (`https:`, `data:` or `blob:`),

but prefer `data:` URIs for anything the page cannot do without: a reader with the network off sees nothing, and a remote image makes every reader's browser call that host directly, which hands a third party the IP address of everyone who opens the page.

• **Storage works** and is scoped to the page: `localStorage`,

`sessionStorage`, `indexedDB` and cookies persist across reloads and across versions of the same page. Use it for a chosen tab or filter, never for anything the page cannot rebuild from its own content.

• **No parent access.** The viewer is a different origin, so

`window.parent.document` and `window.top.location` throw. Superset injects one script into the page for comment anchoring; nothing else listens to `postMessage`, so don't build a handshake on it.

• **No form submission.** `form-action 'none'`: a `<form>` may exist for its

controls, but submitting it goes nowhere. Handle inputs in script.

Scripts and popups *do* work. Inline JS runs normally, so charts, filters, sorting, tabs, and interactive controls are all fine, as long as everything they need is already in the file.

The other hard limits

1. **`.html` only.** Any other extension is rejected at the CLI. 2. **One file, or one directory.** `superset pages publish ./report/` publishes a directory: `index.html` is the page, and every other file ships at its relative path, so `<video src="demo.mp4">`, `<link href="site.css">` and `<script src="app.js">` all work. Asset paths may not start with `versions/`, `files/`, `_superset/` or `~`, or be named `thumbnail.jpg`. Assets go up to 1 GiB each; on republish, unchanged assets are not re-uploaded. Prefer H.264 MP4 or WebM for video: iPhone `.mov` recordings may not play in every browser. Remote CDN links and external styleshee