publish

Publish (internal apps & dashboards)

Use this skill when the user wants something that outlives the turn and is reachable in a browser — a small web app, an internal API, a status page, a dashboard you generated from a query. A turn's sandbox is torn down when the turn ends; publishing ships your files to a separate, long-lived runtime that keeps running and gets a stable link.

Publishing is a first-class primitive: the publish tool, alongside execute/read/write. Build the app in the workspace as usual (write files, install deps with execute, test it), then call publish on the directory. The app must listen on the PORT env var (the runtime sets it).

Match the house style (the default)

Anything browsable you publish should look designed, not defaulted. Before you build the UI, load the design skills and apply your organization's house style unless the user asked for a different look:

• The deployment's house-style skill — if a *-design skill is installed (list skills/), it carries the org's look as ready-to-paste CSS and design tokens. Start there for the look.
• skills/taste-skill/SKILL.md — the design process: reading the brief, layout, hierarchy, verifying the result, avoiding generic AI-design slop.
• skills/popular-web-designs/SKILL.md — when the user wants a specific visual reference (Stripe, Linear, Vercel…).

This is about the page a person sees — skip it for an internal-only API or a script with no UI.

Publishing

First publish, and every later update — same call, same name, a new immutable version:

publish({ dir: "dist", entrypoint: "node server.js", name: "status-board" })

Roll back to an earlier version (an instant pointer flip):

publish({ name: "status-board", rollbackTo: 3 })

Give an auto-named deployment a friendly link:

publish({ renameFrom: "s-1176-p-5050", name: "status-board" })

publish returns { id, name, version, url, dataDir? } — give the user the url (/d/<name>/).