Getting started with Prompt to Page.

Download the installer for your platform from the Download page. Prompt to Page is a free closed beta for macOS 14 (Sonoma) or later on Apple Silicon (M1 or later), and for 64-bit Windows 10/11. There is no Linux build and no Intel Mac build.

• macOS — open the .dmg, drag Prompt to Page to your Applications folder and open it from there. Since 0.2.5, builds are signed with an Apple Developer ID and notarized by Apple, so the app opens with no warnings and no Terminal step.
• Windows — run the .msi. This beta is not yet code-signed, so if SmartScreen shows “Windows protected your PC”, click More info → Run anyway, follow the installer and launch Prompt to Page from the Start menu. Windows needs the Microsoft Edge WebView2 Runtime, which is preinstalled on current Windows 10/11.

Upgrading from 0.2.4 or earlier? Those builds needed a one-time xattr command to clear the download quarantine. That step is gone — replace the app in Applications with the new download, or accept the in-app update. Prompt to Page checks for updates after launch (on by default, switchable in Settings → Updates) and installs a new version only when you choose to.

On first launch, Prompt to Page walks you through a short, one-time setup to connect a local model. After that, the app opens straight into your projects.

Prompt to Page needs a local language model. The first-run setup offers three routes, and shows whether Ollama or LM Studio is already running on this computer.

1. Choose a runtime

• Built-in (recommended) — Prompt to Page manages the runtime for you. Best if you don't already run models locally.
• Ollama — connect a model you have already pulled. Prompt to Page lists the models your Ollama instance is serving.
• LM Studio — connect to LM Studio's local server, started from its Developer tab. You don't need to turn on LM Studio's CORS option.

2. Get the model

With the built-in runtime, the setup wizard reads your RAM, free disk space and operating system and pre-selects a model that fits. Each model card shows its size and its Prototype quality on the design system you are working in — a measured level from Basic to Excellent, or Not measured — plus the other design systems it has been measured on. Select Download and start: the wizard downloads the file, verifies it and starts local AI, with a progress bar, Pause and Cancel setup; an interrupted download resumes. If you already have a .gguf file (or an MLX folder on macOS), choose Use a model already on this Mac / PC instead — useful when a managed network blocks the download.

3. Start prototyping

When the status bar reads Connected and names your model, setup is done and you're handed straight to the prompt. You can change runtime, model or port later in Settings → Local AI.

Prompt to Page defaults to the GOV.UK Design System and ships eight base packs: GOV.UK Design System, NHS.UK frontend, the U.S. Web Design System (USWDS), the NSW Design System, Bootstrap Italia, the Scottish Government Design System, the Digital Agency Design System (Japan) and a neutral, unbranded Abstract Design System. With the GOV.UK base selected, a Departmental components checkbox adds the Ministry of Justice (MOJ) overlay.

• Pick the design system when you create a project or a new page — the Design system chooser lists the packs as radio buttons.
• Every page keeps the design system it was created in and is never converted. A project can mix pages from more than one system; the active page decides what preview, generation, checks, sharing and export use.
• One line under the chooser states the Prototype quality of your current model on that design system — a measured level, or Not measured. It is a fact about that model on that system only: levels are never compared across design systems, and a model from Ollama or LM Studio reads Not measured everywhere.

Whichever system is active, prototypes are never real services. They render with an unbranded header and a pack-specific prototype marker (for example “this is not a real government service”); restricted fonts and protected marks are not bundled.

In the chat input beneath the preview, describe the page you want in plain English. Lead with what the page is for:

Create a start page for applying for a Blue Badge.

Prompt to Page generates the page in the active design system and renders it in the preview when generation finishes. Each prompt produces one page. To change it, send a follow-up — you don't start over (see Edit what exists, add what is missing):

Add a "Who can apply" section and an inset warning about evidence.

Writing good prompts

• Name the journey type — apply, report, check, register or request.
• Say which page you mean — a start page, a question page, or a check-your-answers page. The empty chat offers prompt suggestions grouped by page type.
• Use real content. “Blue Badge”, “Carer's Allowance” and “pothole” give better results than placeholders — but keep it synthetic: no real personal data.

Prompt to Page writes the active design system's own markup — the real classes and components, drawn from the pack's component library and checked against its class rules. As it generates you see live progress — a percentage and tokens per second — while the output streams into the chat. When generation finishes, the completed page renders in the preview with the design system's real components, layout, spacing and colours. Partial markup is never shown in the preview.

Two domains stay separate: the app you work in is its own interface, and the design system's styling only ever appears inside the preview — which is precisely what you'll export. Prototypes use an unbranded header rather than any crown, crest or logotype, so they read clearly as prototypes and not as live services.

Attempts are labelled in the chat (for example Attempt 2 · Retry). Regenerate retries the last request, and you can Edit or Reuse an earlier prompt as the start of a variation.

Once a page has content, edits are scoped to a single section: only the part you point at is regenerated, and everything else on the page is protected. If a change fails the pack's checks, the page is left exactly as it was.

• Edit section — click Edit section on the preview toolbar (or Alt/Cmd-click a section), choose the section, and a Refining: chip in the chat names exactly what will change. Describe the change and generate.
• Or just describe the change. If it is clear which section you mean, only that section regenerates; if it is ambiguous, you are asked to click the section; a whole-page change (make the whole page friendlier) always asks for confirmation first — full-page regeneration never happens silently. You can also remove a section or split one in two.
• Add section — click Add section, choose a visible Add here point (before, between or after the page's existing blocks), and an Adding: chip names the location; then describe the section. Or type an additive request such as add an eligibility section — a named position (at the end, before the form) is used when it matches exactly one point. The new content is created without sending the rest of the page to the model, and the page stays unchanged unless the new markup passes the pack's checks. Undo reverses it; Esc cancels and keeps the request with a Choose placement button.
• Keep each request to one operation: add the new section first, then edit existing content in a separate request.

Version history and code view

Every change to a page saves the previous version. Open Version history on the preview toolbar to see recent versions, each labelled by the request that replaced it, and Restore any of them — restoring is itself undoable. The code view shows the page's HTML and lets you edit it directly (⌘/Ctrl+Enter applies your changes), with a Copy HTML button for the current page. Whole-project checkpoints are separate: pin one from the save-state chip in the header or with ⌘/Ctrl+S, and restore an earlier one from the same menu.

A prototype is usually several linked pages, not one.

• Pages — open the Pages panel to add pages with New page, rename and reorder them, set the start page, or delete one.
• Navigate — click links in the preview to move between pages; Back and Forward step through your history. A link to a page that doesn't exist yet shows a not-found message so you can create it.
• Journey map — the Journey tab plans links between pages, and its Reconcile view lists Planned not implemented, Implemented not planned, Broken targets and Unreachable from start, with an apply step that writes the missing links into the page. Link pages on the preview toolbar lets you pick a link or button in the preview and choose the page it should go to.
• Exits — on a freshly generated journey page, every primary control points at the next page in the plan and every back link at the previous one. Any other link or form whose destination isn't a page in the project is stamped as an unresolved exit: outlined in the preview and the testable prototype, and kept on the page's issue list until you retarget or regenerate it.

Rather than describe every page, pick a template to generate a complete journey — several pages wired together, with realistic content. Six templates across five patterns are included:

• Apply — e.g. apply for a Blue Badge
• Apply with an eligibility check — an apply journey that screens eligibility first
• Report — e.g. report a pothole
• Check — e.g. check your State Pension age
• Register — e.g. register to vote
• Request — e.g. request a document

Once generated, refine any page, add pages, or reorder the journey. The journey map keeps planned and implemented links in step.

Every page is scanned with axe-core using its WCAG 2.2 AA rule set, against the rendered page — so colour-contrast and target-size results reflect what users actually see. Open the Accessibility tab and run the check:

• Critical / Serious / Moderate / Minor — each issue names the failing element, cites the success criterion (for example WCAG 4.1.2) and links to remediation guidance. Highlight in preview jumps to the affected elements.
• Manual checks — a separate list covers what axe cannot decide (keyboard, screen reader, zoom and reflow, content), with how to test each one.
• Re-run the check after any change.

The Validation tab checks the markup against the active design system's class and structure rules and repairs some common model mistakes, catching components that look right but aren't built the system's way. It checks the markup, not whether the component was the right choice.

Open Share & Export to get your work out of the app. Everything below is produced on your computer.

• Project file — Export project file writes a portable .govproto file containing the project's pages and chat history; Import brings it back on any machine. Projects also save automatically — the file is for backup or hand-over.
• Testable prototype — Download testable prototype produces a self-contained ZIP of clean HTML files that click through like a real service, with form state carried between pages, internal links rewritten to the exported files, and local font-stripped frontend assets so it opens offline.
• Prototype Kit project — on GOV.UK projects, Download Prototype Kit project writes a GOV.UK Prototype Kit project that runs with the kit's own dependencies.
• Assessment evidence — Download assessment evidence produces a ZIP whose EVIDENCE.html carries a cover, the Brief (your journey-plan description or first prompt — never invented), a journey overview, every page at real fidelity, the Components actually used, the accessibility position at export time with the manual checks still owed, and Limitations. Print it to PDF from a browser. It never claims WCAG or assistive-technology conformance.
• Copy code — Copy HTML copies every page's markup for any design system; Copy Nunjucks (GOV.UK and NHS.UK packs) copies kit-ready templates for the GOV.UK Prototype Kit or the NHS prototype kit.

Kit and Nunjucks hand-offs use the receiving project's dependencies; restricted fonts and protected marks are not bundled in any export.

Share for testing

In the same panel, Start share server serves a snapshot of the current prototype from your computer. By default it is reachable only on this computer; tick Allow other devices on my network to open this prototype before starting to add a LAN URL and a QR code that a phone on the same Wi-Fi can scan. Each session uses a unique secret link, there is no upload and no hosting, and the server stops when you stop it or quit the app. The snapshot is taken when the server starts — stop and start it again after editing pages.

Prompt to Page produces prototypes, not production code. The output is real design-system markup and it is meant to be edited, tested and thrown away — it has none of the security, performance or content assurance a live service needs.

• It doesn't make a page accessible. The automated checks find mechanical defects. Manual testing, assistive-technology testing and research with disabled people are still yours to do — see Accessibility and validation.
• It doesn't do content design. Generated wording is a placeholder for a content designer's judgement, not a replacement for it.
• It doesn't check that the component is the right one. Validation catches classes and structures the design system doesn't have. Whether a radio should have been a checkbox, or a journey should branch where it does, is a design decision.
• It doesn't review clinical or policy safety. NHS.UK output in particular still needs the clinical-safety and content review the NHS service manual asks for. Keep early prototyping to non-clinical patterns — contact preferences, appointment admin, general information — rather than triage, symptoms or anything advising urgent care.
• It isn't a source of real data. Use synthetic content. See the privacy notice for what not to paste in.

Generation, preview and automated checks happen on-device using the local model you set up, and keep working without an internet connection. Every connection the app can make is disclosed and separately controlled. Model setup downloads from the revision-pinned Hugging Face addresses in the model catalogue. A separate update check runs automatically after launch by default and can be turned off in Settings → Updates. Optional lifecycle analytics are off unless you opt in under Settings → Privacy, and they never include your prompts or prototypes. Feedback and error reports are sent only when you explicitly press Send, after seeing the report. The share server binds to your computer — or to your local network, if you allow it — only while you run it. See the full privacy notice.

Short answers to the most common questions. There's a fuller list on the FAQ page.