# Prototype template 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 [#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 [#the-slots] A template is an HTML document with `.ps-*` styles and one empty `` 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 `` or of a `.ps-*` container. ## What a template cannot contain [#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, `` or ``, 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 [#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 [#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](/docs/comments-and-suggestions) for replies, mentions and Inbox preferences. ## Rebuilding an existing prototype [#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 [#cli-api-and-mcp] ```bash 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`. How the agent builds one, and how to ask for changes. The same nearest-wins rule for the documents the agent writes.