DemoPage

View saved version →

---
name: create-demopage
description: Build or deepen the user's DemoPage (a live, narrated demo of their product for website visitors) by mapping the product's pages from its code, then approving the ones buyers should see. Use when the user asks to create, build, improve, or fix their DemoPage or product demo, or to add pages from a repo to DemoPage.
---

# Create a DemoPage from the product's code

DemoPage gives a vendor's website visitors a live demo inside the real product, narrated by an AI guide. The guide can only open pages in the vendor's catalog, and it narrates from each page's description. A deep catalog makes a deep demo. Your job is to map the product from its code, send the pages as candidates, and let the user choose what goes live.

The DemoPage MCP server (`demopage`) acts for the one vendor account the user signed in with. The tools are:

| Tool | Use |
| --- | --- |
| `demopage_status` | Website, live or not, page counts, last page check, demo link, and the next step. Call it first. |
| `demopage_list_pages` | Every page with its id, whether it is approved, and its last check. |
| `demopage_import_pages` | Send mapped pages as candidates, up to 100 per call. Nothing goes live from this. |
| `demopage_approve_pages` | Approve (or hold) pages by id. Before go-live, this also turns the demo link on. |
| `demopage_check_pages` | Load every approved page in a demo browser, the way demos open them. |
| `demopage_read_site` | Read the public website again (only before go-live). |
| `demopage_get_link` | The demo link and the embed snippet for the website. |
| `demopage_results` | The last 30 days: visits, live demos, questions asked most, pages kept out, leads. |

## Ground rules

- **The code stays here.** Send only what the tool schema asks for: a title, a full https address, a short piece of visible text, a one or two sentence description, and optional keywords or click path. Never send source code, file contents, environment values, secrets, internal hostnames, customer names, or customer data.
- **Repository access is a prerequisite.** This workflow works only when the current client can actually read the user's local repository or files the user deliberately attached. The DemoPage MCP server cannot read a repository. If no filesystem or attached source is available, say that plainly and stop; do not imply that ChatGPT or DemoPage inspected code it could not access.
- **The user approves.** Importing is safe: every page arrives held. Never call `demopage_approve_pages` until the user has seen the list and said which pages to approve. "Approve all" from the user is fine; your own judgment is not.
- **Read-only screens only.** Demos never save, send, pay, or delete anything; DemoPage blocks those actions in every demo. Do not map screens whose purpose is money, keys, or account security: checkout, billing, payment methods, invoices to pay, API keys or tokens, passwords, two-factor setup, sign-up, login, logout, account deletion. DemoPage refuses these anyway.
- **Real, canonical addresses on the product's domain.** Every `url` must be https on the website domain `demopage_status` reports, or one of its subdomains (for example `app.` for the product itself). Remove every query string and fragment before sending it; they can contain tokens, emails, or other sensitive state. Never localhost, staging, preview, or internal hosts.

## Steps

### 1. Check the account

First verify that this client has a filesystem or attached source it can inspect. If it does not, explain that the MCP connection can manage DemoPage but cannot supply code access, and suggest running this skill in Cursor, Claude Code, or Codex from the repository, or attaching a bounded set of route/navigation files.

Call `demopage_status`.

- If the call asks the user to sign in, tell them their AI tool will open "Sign in with DemoPage"; they sign in with their DemoPage account and choose Allow.
- If there is no account: send the user to https://ap

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: demopage-results
description: Summarize how the user's DemoPage demos are doing (visits, live demos, leads, the questions buyers asked most, and pages kept out) and suggest what to add next. Use when the user asks about DemoPage results, demo leads, what buyers asked, or how their demo is performing.
---

# DemoPage results

1. Call `demopage_results` from the `demopage` MCP server. If there is no demo link yet, say so and offer the `create-demopage` skill.
2. Report, in plain sentences:
   - the funnel for the last `days` days: visitors who saw the demo (`seen`), opened it, typed a request, and sent it (`sent`); demos `started` and `finished`; `leads`; and clicks on the call to action (`cta`) and booking link (`booking`);
   - the questions buyers asked most, with counts;
   - pages kept out of demos and why;
   - the latest leads: email, company, and what they wanted.
3. Suggest the next move. For each top question the demo couldn't answer well, and each page kept out, name the screen in this repo that answers it, if there is one. Offer to import or correct those pages with `demopage_import_pages`; the user approves them before they go live.

Lead emails are the vendor's own leads. Show them only to the user, and never copy them into files, commits, or other tools unless the user asks.