This guide is for anyone brand new to Reprise who is learning to build demos through the Reprise MCP in Claude / Cowork. You build by typing plain-English prompts in chat — the MCP does the work behind the scenes. It covers Product Tours and Data Injection, plus how to send a friction report when something doesn't work.
How to use this article: Work top to bottom. Each section is a stage — setup, then your first tour, then polishing, then your first injection, then troubleshooting. Run each prompt, watch what happens, and ask follow-up questions in your own words.
Before you start — prerequisites
None of the prompts below work until these are in place:
- Real Google Chrome (not a bundled/automation browser — Chrome Web Store extensions require real Chrome).
- Reprise Builder: HTML extension installed → needed for Product Tours.
- Reprise Builder: Data Injection extension installed → needed for Data Injection.
- Reprise MCP connected in Claude / Cowork.
- Claude in Chrome (browser automation) connected, so the assistant can drive the browser alongside you.
Confirm your setup
Am I connected to the Reprise MCP? Who am I logged in as?
Check whether my browser is connected and which Chrome window you can see.
What can the Reprise MCP help me build? Give me the short version — Tours vs Data Injection — and when I'd use each.
1. Orientation — understand the tools before building
Good first prompts when you know nothing about Reprise. The goal is a mental model, not output.
I'm brand new to Reprise. In plain language, what is a Product Tour and what is Data Injection, and how are they different?
Walk me through, at a high level, the steps to build a Product Tour from start to finish — what happens on my end vs. what you do automatically.
What's the difference between a "draft" tour and a "published" tour, and when does each one get created?
Show me an example of a finished Reprise tour preview link so I know what I'm working toward.
2. Your first Product Tour (capture)
A Product Tour is a linear walkthrough built from captured screens of a real web app. The flow is: create → start capture → pair the extension → navigate and capture each step → publish → preview.
Create the tour
Create a new product tour called "[My First Demo]".
Start capture and pair the extension
The assistant will give you a pairing link or token to approve in Chrome.
Start capturing for this tour. Walk me through pairing the Reprise Builder extension if I need to.
Capture screens one at a time
Navigate to the page you want, let it fully load, then:
Capture this page as the first step. Title it "[Login screen]".
Now go to [the dashboard / this URL] and capture it as the next step, titled "[Dashboard]".
Tip: Always let the page fully load before saying "capture." A half-loaded page captures as a broken screen with no error. If a step looks wrong in the preview, it's almost always because the page wasn't settled or the wrong tab was captured.
Verify as you go
How many screens have I captured so far, and what are their titles?
Finish and publish
Stop capturing and publish the tour. Give me the preview link once every screen is fully processed.
3. Add guides and polish (editing a tour)
Guides are the tooltips/callouts that explain features. Default to pointing (tethered) guides that attach to a real element — floating cards in the middle of the screen are only for intros and outros.
On the dashboard screen, add a tooltip pointing at the [Revenue chart] that says "[This is where you track monthly revenue]" with a Next button.
List the elements you can attach a guide to on this screen.
Add a welcome message on the first screen and an end-of-tour call-to-action on the last screen that links to [our booking page].
Re-skin this tour for prospect [Acme Corp] — swap the company name and logo references to theirs.
Translate all the guide text in this tour into [Spanish].
Open the preview so I can click through the whole tour and check the guides.
4. Editing captured content — real examples
These prompts come from real Reprise MCP sessions. Editing always happens on the draft — nothing is published until you say so.
Change text and labels on a screen
On this screen, change the heading from "[Welcome back]" to "[Welcome, Acme team]".
Find and replace a value across the whole tour
Useful when a name, number, or label repeats on many screens.
Find every place "[Acme Corp]" appears across all screens in this draft and replace it with "[Globex]".
Anonymize / remove real data (PII scrub)
A very common pre-demo task: replacing real customer names with safe placeholders before sharing. In practice this means swapping the displayed text and the hover tooltips on tables.
This demo still has real employee names in it. Find the real names across all screens and replace them with these approved fakes: [Real Name 1 → Fake 1, Real Name 2 → Fake 2, ...].
Check this tour for any real names or PII still showing in the table hover tooltips, and list what you find before changing anything.
Good to know: Some content — like charts rendered on a canvas or large tables — has limits on how much the MCP can reach and edit automatically. If a scrub is very large (the same name repeated hundreds of times), the assistant may run it as a background task or flag the few spots that need the Reprise HTML editor. If you hit one of those walls, that's a great thing to capture in a friction report (see below).
5. Your first Data Injection
Data Injection swaps the data a live app loads — so charts, tables, KPI tiles, and dropdowns show the numbers your demo needs. Think in two phases: first get the plumbing working (does my placeholder data show up at all?), then load the real data.
Set the target
I want to inject custom data into the chart on [this dashboard URL]. Help me find the right request to swap.
Phase A — prove the plumbing with placeholder data
Set up the injection with obvious placeholder values first, so we can confirm it's wired correctly before I put in real numbers.
Activate the injection and tell me whether the placeholder values are showing on the page.
Tip: If placeholders don't appear, the wiring is wrong — not the data. If the page goes blank, the injection over-replaced. Fix the wiring before touching the actual numbers. This two-phase discipline is the single biggest time-saver.
Phase B — load the real demo data
The placeholders are showing. Now replace them with this data: [paste your numbers, e.g. 30 days of revenue].
Re-activate and confirm the real data is rendering on the page the way I intended.
Give me the Data Studio editor link for this dataset so I can keep tweaking it later.
6. Putting it together — injected data inside a tour
You can't inject directly into a tour, but you can capture a live app after injecting data into it.
I want my tour to show custom data. Walk me through injecting the data into the live app first, then capturing those screens into a tour.
7. Troubleshooting
The things that go wrong most often, phrased the way you'd actually ask.
I captured a step but it looks blank / broken in the preview. What happened and how do I fix it?
I said capture but the screen count didn't go up. Why?
The injection isn't showing my data on the page. Help me figure out if it's a wiring problem or a data problem.
The pairing isn't working — I don't think the extension connected. Walk me through it.
My preview is showing placeholders / loading spinners instead of my screens. What do I do?
Something errored out. Try that last step again.
Quick rule for injection: if the Data Studio editor matches what you intended but the page doesn't, it's a wiring problem. If the editor rows are wrong, it's a data problem.
8. Sending a friction report
When the MCP hits a real wall — a tool errors out, a documented step doesn't work, or a missing capability costs you time — you can file a friction report straight from the chat. These go to the Reprise team and are how the MCP gets better. Don't skip them; a 30-second report is the fastest path to a fix.
How to send one
Just describe what happened and ask the assistant to file it:
That last step failed in a way that cost me time. Please file a friction report describing what happened.
File a friction report: the table hover tooltips on rows past the first few can't be edited through the MCP, so I couldn't finish anonymizing the demo. I had to fall back to the HTML editor.
What goes in a friction report
The assistant fills these in for you, but it helps to know the shape so you can give it the right details:
- Summary — one short line describing the symptom you saw (not the fix you'd want). Keep it under ~80 characters.
- Category — one of: bug, tool_ergonomics, platform_gap, docs_gap, feature_request.
- Severity — blocker, major, or minor.
- Product — tour, data_injection, clone, or mcp_general.
- Reproducibility — confirmed, suspected, or one_off.
- Details — a sentence or two expanding the summary, plus any workaround you used.
Example reports
Real examples from past sessions, to show the level of detail that's useful:
- tool_ergonomics / major / tour — "Attribute listing caps at ~5 table rows, so rows beyond that are unreachable/uneditable."
- feature_request / major / tour — "No bulk find-and-replace for draft text or attributes."
- bug / minor / mcp_general — "Frequent 'MCP server connection lost' / proxy timeouts slowed every pass."
Tips
- One issue per report. If two unrelated things broke, file two.
- File it even if no one's watching. In automated/background runs the report is still saved.
- If sending fails (the endpoint is occasionally down), the report can be retried later — ask the assistant to try again or save the draft.
9. Wrap-up and practice
Summarize what I built today and give me all the links — tours and datasets.
Based on what I struggled with, what are the 3 things I should practice next time?
Give me a 5-minute exercise I can do solo to practice building a tour from scratch.