Rendemo

View saved version →

---
name: author-a-tour
description: 'Use when the user asks to create or change a CODEBASE TOUR inside their own live product, or mentions data-rendemo markers, rendemo.tours.json, rendemo_create_tour, rendemo_add_tour_step, rendemo_list_tours, rendemo_probe_tour_targets, or the tour lockfile. A tour always runs in customer code and requires source markers. A crawled hosted replica is a sandbox demo and must use the sandbox-demos skill instead.'
version: 1.0.0
---

# Author a Rendemo product tour

A **tour** is step-by-step guidance on the user's own live product, which they perform for real.
It always uses `data-rendemo` markers in customer source and a `rendemo.tours.json` lockfile.
Recorded demos and hosted sandbox demos are demos, not tours.

**This skill covers two visits.** Building a tour that does not exist yet is sections 1-10. Changing
one that does — add a step, reword one, reorder them, drop one, retire the whole thing — is section 0
and "Editing an existing tour". `rendemo_list_tours` is what tells you which visit this is, and it is
the first call either way.

**This procedure assumes a repo.** If the user gives a URL or existing sandbox instead of customer
source, they are asking for a sandbox demo. Load `sandbox-demos` and use the sandbox-demo MCP tools;
do not create a tour project as a substitute.

## Do not open with a preamble

Someone who typed "build a tour of our app" has already decided. Opening with an essay on what a tour
is and five things it cannot do spends their attention before they have anything to attach it to, and
it is the single most common way this procedure wastes someone's time.

**Reading their repo needs no permission.** It is free, reversible and invisible. Go and read it. The
first thing in this procedure that is *not* free is writing markers into their source, and that is
where the gate belongs — see section 2, where you hand them a table of real elements in their real
product that they can actually judge. A step table is disclosure someone can act on. An absent-features
list is not.

So the first reply is: one clause of readiness, one clause of what you are about to do, then work.

**Write it from this template rather than composing it fresh.** Prohibitions do not survive contact
with a first turn — "do not narrate the machinery" has been stated twice and still produced *"I'll
start by checking what tours already exist here"*, which is a sentence about your own procedure that
tells the user nothing. A shape is harder to drift from than a rule:

> Signed in to **{workspace}**. Reading the repo for the {intent} sequence…

and, when the request names an audience, one clause more:

> Signed in to **{workspace}**. Worth knowing up front: who sees a tour is a conditional render in
> your own code — Rendemo has no rule engine — so "{their audience}" becomes your app rendering the
> element only when {condition}. Reading the repo for the {intent} sequence…

What is banned is naming your own apparatus: which skill or file you are in, which step of a
procedure you have reached, that you are "checking first", that you are about to hand off. Say what
you **found** and what you are **doing**. `rendemo_list_tours` still runs first — it is just not
something the user hears about unless it changed the answer.

## What a tour is — reference, not a script to read aloud

It runs in the product through one element:

```html
<script src="https://www.rendemo.com/embed.js"
        data-demo="<workspace>/<tour-slug>" data-mode="tour" async></script>
```

That resolves each step's `data-rendemo` marker on the live DOM, draws the same step card the published
demo draws, advances when the viewer does the real thing (`data-rendemo-do`), waits for a target that
has not appeared yet, skips steps whose `route` is not the current page, and resumes on the right step
across navigations and reloads.

**The five limits, and where each one belongs.** Every one 

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

View saved version →

---
name: drive-and-record
description: Use when the user wants a demo of their signed-in product and wants YOU to do the walkthrough rather than record it themselves or tell you which buttons to click — "make a demo of my app and you drive it", "record a demo of my product without me clicking", "walk through my dashboard yourself and record it", "drive my signed-in session and build the demo". The agent REHEARSES the workflow unrecorded on the user's own signed-in tab through the Rendemo Chrome extension, PROPOSES the take as a numbered plan the user approves in chat, then RECORDS that plan as one clean take that auto-directs — no free-roam replica to leak, so it is the right route for a data-dense product (CRM, inbox, leads). Read it BEFORE rendemo_start_drive_session / rendemo_drive / rendemo_propose_drive_plan / rendemo_record_drive_plan: it covers the intake questions to ask first, the paste steps to hand the user, the unrecorded read→decide→act rehearsal, how to write the plan and get a yes, the Record click, and the hand-off to the build pass. A user who would rather click through it themselves wants a plain recording (`new-demo`).
version: 2.0.0
---

<!-- GENERATED by `npm run skills:generate` from lib/copilot/skills/drive-and-record/SKILL.md.
     Edit that file, not this one. `npm run skills:check` fails the build if they have drifted. -->

# Rehearse, propose, record

The user has asked for a demo of their product and they do NOT want to walk it themselves, and they
do NOT want to tell you which buttons to click. You drive their signed-in product tab. What comes
out is a real recording — real screens, real transitions, real data — and because it is a recording
there is no free-roam replica for anyone to wander into, which makes this the SAFE choice for a
product whose screens are full of other people's data: a CRM, an inbox, a leads list.

The shape of the work is the shape a person uses: **rehearse first, then perform.** You explore the
product with the recorder OFF until you know the path. You write that path down as a plan and show
it to the user. Once they say yes, the extension performs the plan as ONE clean take — every step
back-to-back, a beat between them, nothing else. The recording holds the performance, never the
thinking. (The first takes that recorded the thinking were five minutes long with seconds of frozen
screen between clicks and every failed retry in the footage. That is what this shape prevents.)

This is one rung of the capture ladder in `new-demo`. Reach for it when all three are true: the demo
is behind a login, the user wants the agent to do the walkthrough rather than record it themselves,
and you can drive their browser through the extension. If the user would rather click through it
themselves, that is a plain recording (`new-demo`), and it is better when they have it in them.

## Ask first — two or three short questions, then get out of the way

You are about to navigate a product you have never seen toward a goal only the user knows. Ask
before you start. Keep it to three, lead with your read so they can just say yes, and never turn it
into an interview:

1. **What is this demo for?** Selling to prospects, onboarding new users, teaching one feature. The
   answer sets the story shape and the theme, exactly as in `new-demo`'s intent table.
2. **What is the one outcome it should land on?** The screen or moment that makes the case — the
   populated dashboard, the sent campaign, the analytics that prove it works. This is the payoff you
   steer toward; everything in the plan is in service of reaching it.
3. **Anything I must not touch?** A real destructive control, a customer's private record, a live
   send. You already refuse logout/delete-shaped navigation and destructive-looking clicks, but the
   user knows their product's landmines.

Do not ask a fourth question, and do not ask them to plan the steps — the steps are yours to find.

## Sta

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

View saved version →

---
name: embed-a-demo
description: 'This skill should be used when the user asks to "embed a demo", "add our demo to the pricing page", "install a Rendemo demo", "put the product demo on the site", mentions `<rendemo-demo>`, `embed.js`, or `rendemo_get_embed`, or wants an interactive Rendemo demo rendered inside their own app or marketing site. Sequences the whole install: pick the demo, detect the framework, write the wrapper, place the script tag.'
version: 0.3.0
---

# Install a published Rendemo demo on a site

A **demo** is a recorded replay a visitor **watches** in an iframe. If what the user actually wants is
step-by-step guidance on their own live product, which they **perform for real**, that is a **tour** —
a different artifact and a different skill (`author-a-tour`). Check that before you install anything;
embedding a recording for someone who asked to guide their users is a visible mistake.

This works end to end today. `https://www.rendemo.com/embed.js` is live, the `<rendemo-demo>`
custom element ships `inline` and `modal` modes, and `rendemo_get_embed` returns install code per
framework. Nothing in this procedure is aspirational.

The MCP cannot touch a filesystem. Every tool here hands back **text you write**.

## 1. Find the demo

Call `rendemo_list_projects`. Each project reports `demo: { id, status, protected }` or `null`.

- **Exactly one plausible match** by name and the user's stated intent → say which one you picked and
  keep going.
- **Ambiguous, or several published demos** → list name / step count / status and ask which. Do not
  guess: embedding the wrong demo on a pricing page is a visible mistake on a public page.
- `status` is not `published` → **stop and ask.** `rendemo_publish_demo` makes the demo
  world-visible at a public URL. That is not yours to decide. Offer it, wait for a yes.
- `demo: null` → the project has no demo yet. Publishing is the only path, so the same checkpoint
  applies.
- `protected: true` → **stop before writing anything.** A password-protected demo cannot be embedded
  at all: the access cookie is dropped inside a third-party iframe, so the visitor loops back to the
  password form forever. This is not a caveat to mention afterwards — it makes the whole install
  pointless, and the files you would write are files that can never work. Offer the alternatives
  instead: link to `/d/<id>` or `/site/<workspace>/<slug>` in a new tab, or remove the password.

## 2. Detect the framework — do not ask, look

`rendemo_get_embed` takes exactly these values, and passing the wrong one produces a snippet that
will not compile:

| value | evidence to look for |
|---|---|
| `next-app-router` | `next` in dependencies **and** an `app/` directory containing `layout.tsx`/`layout.jsx` |
| `next-pages` | `next` in dependencies **and** `pages/_app.tsx`/`_app.jsx`, no `app/` router |
| `react` | `react` in dependencies, no `next` |
| `vue` | `vue` in dependencies |
| `svelte` | `svelte` in dependencies |
| `html` | no package.json, or plain static HTML |

Read `package.json` and glob for the router directory. If a repo has both `app/` and `pages/`
(a mid-migration Next app), pick the router that owns the page the demo is going on, and say which
you picked and why.

`mode` is your call from the intent: `inline` for "put the demo on the page", `modal` for
"a Watch-the-demo button". Ask only if the intent genuinely does not say.

## 3. Get the code

`rendemo_get_embed({ projectId, framework, mode })`. It fails with a clear message if the project has
no demo or the demo is not published — that means you skipped step 1, go back.

It returns `scriptTag`, `scriptLocation`, `snippet`, `wrapper`, `url`, `posterUrl`, and `events`.
**Use the returned strings verbatim.** Do not retype them from memory or from this file; the tool is
the single source of the contract and this skill is not.

## 4. Write the files

Three writes, in this order:

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

View saved version →

---
name: new-demo
description: This skill should be used when someone asks for a product demo, walkthrough, tutorial, onboarding flow or "show how my product works" and there is no Rendemo project yet — including "make me a demo", "demo my app", "turn this into an interactive demo", "record a walkthrough of X", or a bare product URL with a request to demo it. Read it BEFORE choosing how to capture (a user recording with the Rendemo Chrome extension beats a browser capture code, which beats a headless crawl) and before rendemo_crawl_site, rendemo_start_browser_crawl or rendemo_list_projects on an empty workspace. Covers the two questions to ask first, the intent-to-theme recipes, the extension handoff script to hand the user verbatim, the build pass from auto-directed draft to published link, and translating plain-words feedback into edits — so the user never has to open Rendemo at all.
version: 1.0.0
---

<!-- GENERATED by `npm run skills:generate` from lib/copilot/skills/new-demo/SKILL.md.
     Edit that file, not this one. `npm run skills:check` fails the build if they have drifted. -->

# Starting a demo from a conversation

Someone has asked you for a demo. They have not asked for a project, a capture, a sandbox, a theme
or a publish step — those are our nouns, and every one you make them learn is a reason to give up.
The job is to get from "I want a demo of X" to a live link they can send someone, with the person
doing exactly one thing: showing you their product once.

Assume they will never open Rendemo. Everything below exists to make that assumption true.

**One rule before any of it: waiting is a tool call, not a turn.** Recording, crawling and building
all take minutes, and every tool here that waits on one — `rendemo_watch_captures`,
`rendemo_get_crawl_status` — holds the connection open and returns when something actually happens.
When one comes back still-not-finished, call it again immediately. Do not summarise the wait, do not
ask the user to check, and do not end your turn: nothing on the other side will resume it, and the
work you were waiting on completes into an empty room. A result that says NOT A STOPPING POINT means
exactly that.

## Two questions, then get out of the way

Ask both before any tool call. They are cheap, they are the only things you cannot infer, and each
one decides something you would otherwise get wrong.

**1. What is this demo for?** Not "what should it cover" — what job it does. The answer picks the
story shape, the theme, the motion and the ending, all at once:

| They want | The story is | Open on | End on | Theme candidates | Motion |
|---|---|---|---|---|---|
| To sell it — prospects, outbound, a website | the shortest path to the payoff | a title card naming the outcome | book a demo / talk to us | `atrium` `broadsheet` `kiosk` | `cinematic` |
| To onboard new users | first-run order, nothing clever | wherever a new account actually lands | into the product itself | `vellum` `signal` | `calm` |
| To teach one feature | one screen, deep | the screen the feature lives on | related docs, or back to the app | `signal` `console` | `calm` |
| A launch or landing-page loop | a highlight reel that autoplays | the most striking moment in the product | sign up / join the waitlist | `marquee` `sticker` | `kinetic` |
| To answer "how do I…" for support | the exact task, no detours | the task's entry point | back to support / the next task | `ledger` `vellum` | `calm` |

A theme is not optional polish — **publishing refuses until one is set**, deliberately, so that no
two demos default into looking alike. Intent is how you choose one well instead of guessing.

**2. Does the demo need to show anything behind a login?** Their dashboard, their account, their
data. People rarely volunteer this, and the public marketing site is almost never the product they
meant. It decides the capture route below, and getting it wrong costs a whole crawl.

**Sugg

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

View saved version →

---
name: sandbox-demos
description: This skill should be used when creating or editing a SANDBOX DEMO — a hosted, autoplayable demo built from a site Rendemo crawled into a replica — rather than a codebase tour. Use it when the user says "make a demo of <some website>", gives a URL and no codebase, mentions `rendemo_crawl_site`, a crawl, a sandbox or a replica, or is authoring against an existing sandbox demo — and before `rendemo_add_sandbox_demo_step`, `rendemo_list_sandbox_pages`, `rendemo_find_in_sandbox` or `rendemo_check_sandbox_demo`. A sandbox demo writes no markers into customer source and has no lockfile to commit. Tours are reserved for codebase guidance authored with `author-a-tour`. Covers surveying what the crawl actually captured, choosing steps and target elements that survive a rebuild, writing the step card, and verifying before publish.
version: 2.4.0
---

<!-- GENERATED by `npm run skills:generate` from lib/copilot/skills/sandbox-demos/SKILL.md.
     Edit that file, not this one. `npm run skills:check` fails the build if they have drifted. -->

# Sandbox demos

A sandbox demo and a codebase tour can both guide a visitor step by step, but they are different
products and are authored almost nothing alike. On a codebase tour you write a `data-rendemo` marker into the customer's source and the
overlay finds it. **A sandbox has no source anyone can edit** — its pages are a build artifact,
extracted from a crawl and served from our storage — so a sandbox step instead records the target
element's identifying *facts*, and a build pass re-resolves those facts against the current markup
and stamps the marker itself, at publish and again after every rebuild.

Everything below follows from that. You are not writing markers; you are choosing elements durable
enough to be re-found later, and you cannot see the page — you are reading an index of it.

`demo-craft` governs how the finished demo behaves: cards, emphasis, pointers, effects, and the
player. Read it too. This skill covers what is unique to a sandbox-backed demo: surveying replica
pages, choosing durable targets, validating them after rebuilds, and publishing the hosted result.

## Ask before you dress it

The look of the demo is the author's call, not yours — and "the author" is the person you are
talking to, not the model's taste. Before styling anything (and ideally while the crawl runs, when
you have their attention and nothing else to do), ask two or three short questions and then commit
the answers with `rendemo_set_demo_presentation_theme`:

1. **Vibe** — offer the two or three themes that fit their product and let them pick. The menu:
   - `broadsheet` — editorial, hairline rules, paper tone. Analytics, research, fintech; anything sold on credibility.
   - `console` — terminal: monospace labels, hard corners. Developer tools, infra, security, APIs.
   - `atrium` — glassy, architectural, mostly negative space. Premium B2B with a design-conscious buyer.
   - `ledger` — spreadsheet discipline, tabular figures. Fintech, accounting, insurance, compliance.
   - `kiosk` — presentation scale, type sized for a room. Sales calls, trade-show loops, TV playback.
   - `sticker` — anti-corporate: solid ink borders, hard offset shadows. PLG, consumer, creator tools.
   - `vellum` — the calm one, built for light product UI. Wellness, HR, education, health.
   - `signal` — the utility default, tuned for unknown products at unknown embed sizes.
   - `marquee` — cinematic: letterboxed, chapter cards, no persistent chrome. Launch films, landing-page autoplay.
   - `blueprint` — technical drawing: thin strokes, numbered callouts. Hardware, robotics, logistics, IoT.
2. **Motion** — `motionIntensity`: `calm` (settle, no theatre), `cinematic` (the default sweep), or
   `kinetic` (fast, for short attention). One sentence: "calm, cinematic, or fast and punchy?"
3. **Accent** — `accentMode`: `brand` (their colour does the pointing — th

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