The frame every prototype is assembled into, and how to replace ours with your own for a company or a project.

A prototype template is the chrome around a prototype: the frame, the flow index down the side, the step strip above each screen, the notes, the type and the palette. The agent writes the screens; Plansmith drops them into the template. Every prototype in a workspace looks the same because they share one.

Plansmith ships a template. A company or a project can replace it outright.

What the agent writes, and what the template owns

When the agent builds a prototype it writes small files under the plan: a manifest naming the flows and screens, one theme.css for the product's look, and one HTML fragment per screen. Saving assembles those into the template. That split is why a large prototype saves in seconds, and why a revision rewrites one screen instead of the whole document.

The template owns everything around the screens. It cannot change what a screen does: the runtime that walks between screens, the accessibility floor and the sandbox are Plansmith's, in every template.

The slots

A template is an HTML document with .ps-* styles and one empty <ps-slot> element per slot. Plansmith replaces each slot when it assembles a prototype:

Slot	Required	What lands there
`title`	yes	The prototype's title, from the manifest
`flow-index`	yes	The prototyped flows, one row each, a click to the flow's first screen; flows without a screen are counted, not listed
`screens`	yes	Every screen, in order, each under a step strip listing the screens of its flow (tagged with its spec, or reached from its entry by click), every step a click; a screen that declares variants gets its switcher above the frame
`runtime`	yes	The theme and the navigation runtime
`notes`	no	The agent's notes on the prototype
`provenance`	no	Which plan and specs it was built from

Each slot appears once, as a direct child of <body> or of a .ps-* container.

What a template cannot contain

A template renders inside every prototype in the workspace, including public share pages, so it is validated before it is stored and again every time it is used:

No scripts, frames, objects, forms, <base> or <meta http-equiv>, and no event handlers or inline style=.
No assets except the pinned Plansmith font and icon files. No CSS @import, no url() off the pinned assets.
Only .ps-* selectors (plus a short reset list), and no attribute selectors that read data-* or value.
At most 64 KB.

A template that breaks a rule is refused with the rule named. A stored template that stops passing (for example, edited through the file drawer) is skipped, the next tier is used, and the Settings page says so.

Replacing the template

Resolution is nearest wins, whole document: a project template beats the company template, which beats ours. Templates are never merged.

Company: Settings → Prototype template. Only an owner can change it, because it reaches every prototype in the workspace.
Project: Project settings → Prototype template. Anyone who can edit the project can change it.
From the conversation: ask the agent for something every prototype in the project should carry, such as "make every prototype here carry our header bar". The agent updates the project template and tells you it applies to new prototypes in that project; an owner can make it company-wide in Settings.

Both Settings pages show the template in force, a slot checklist, and a Preview that renders a sample twelve-screen prototype in the template you are editing. Remove falls back to the next tier and says which one.

New prototypes use the template in force. A saved prototype keeps the template it was built with until you rebuild it.

Reviewing a template together

Open Comments on the template document to start a thread or suggest a change. Viewers and comment-only members can participate. Accepting a suggestion follows the template's existing maintenance permissions and validates its HTML before saving.

An inherited template names the scope where a proposed override will be saved. If its source changes during review, refresh and review the proposal before accepting it. Template discussions notify eligible workspace owners. These settings pages have no agent action.

See Comments and suggested edits for replies, mentions and Inbox preferences.

Rebuilding an existing prototype

Open the plan's Preview tab and choose Rebuild with current template. The prototype is re-assembled from its screen files in the template now in force. Comments stay pinned to their elements and the share link keeps working.

A prototype saved before screen files existed has nothing to rebuild from; the button is absent and the agent regenerates it instead. A rebuild never overwrites newer work: if the agent saves the prototype while a rebuild is running, the rebuild stops and asks you to try again.

CLI, API and MCP

plansmith prototype template get                      # the workspace template, with its tier
plansmith prototype template get --project recipe-box
plansmith prototype template set --file template.html            # workspace (owner only)
plansmith prototype template set --file template.html --project recipe-box
plansmith prototype template reset --project recipe-box          # back to the company's, or ours
plansmith prototype rebuild PLAN-12 --project recipe-box

Over the API, GET, PUT and DELETE /v1/prototype-template and /v1/projects/{projectSlug}/prototype-template carry a { template } envelope with tier, html, bytes and maxBytes; a refused PUT answers with the findings, one per rule broken. POST /v1/projects/{projectSlug}/plans/{planShortId}/prototype/reassemble rebuilds a plan's prototype. The MCP servers expose plansmith_get_prototype_template; the local server adds plansmith_set_prototype_template, plansmith_reset_prototype_template and plansmith_rebuild_prototype.

Prototypes

How the agent builds one, and how to ask for changes.

Spec and Epic formats

The same nearest-wins rule for the documents the agent writes.

View as Markdown Open in Claude Open in ChatGPT

Prototype template