---
name: Product Demo
slug: product-demo-2
category: Frontend
description: Product Demo shoots, animates, titles, and can score product demo videos with Remotion for landing pages, docs, onboarding, app store listings, or social posts. Use it when editing compositions under src/compositions/ or when a render needs an intro, title, audio, or fixes for flicker and tiling.
github: "https://github.com/Alexwtlf/agentic-product-demo/tree/main/.claude/skills/product-demo"
language: TypeScript
stars: 180
forks: 2
install: "npx degit https://github.com/Alexwtlf/agentic-product-demo/tree/main/.claude/skills/product-demo ~/.claude/skills/product-demo"
installs_to: ~/.claude/skills/product-demo
source_path: .claude/skills/product-demo/SKILL.md
collection_size: 1
category_size: 705
added: 2026-09-07T05:20:29.363Z
last_synced: 2026-09-07T05:20:29.363Z
canonical_url: "https://dirskills.com/skills/product-demo-2"
---

# Product Demo

Product Demo shoots, animates, titles, and can score product demo videos with Remotion for landing pages, docs, onboarding, app store listings, or social posts. Use it when editing compositions under src/compositions/ or when a render needs an intro, title, audio, or fixes for flicker and tiling.

**Install:**

```bash
npx degit https://github.com/Alexwtlf/agentic-product-demo/tree/main/.claude/skills/product-demo ~/.claude/skills/product-demo
```

## README

# Product demo videos

One pipeline, three layers: the **story** (what the clip shows), the
**motion** (how the interface behaves inside the frame), and the **title**
(the two seconds that open it). Reference implementation:
`src/compositions/Demo.tsx` + `src/motion.ts` + `src/title-card.tsx` +
`scripts/render.sh`.

New clips copy that pipeline. Do not invent a second one.

---

## 1. Settle the brief. Read what you can, ask what you can't.

**Do not start a composition until the four things below are settled.** But
*settled* is not the same as *asked* — and asking for what you could have
found yourself is the fastest way to make a person regret starting.

### Read before you ask

If you can reach the product — its repo, its running app, its live site —
**read it and propose the whole plan.** Take the running order from the
marketing site and the screens from the app; neither answers the other's
question, and question 2 below has the measurement showing why. Then put the
plan up and ask for one confirmation.

### Say that describing the flow beats letting you guess

**Tell them this in your first message, in one line.** Reading the product
gives you a *plausible* flow. It cannot give you the right one, because the
code does not record which path converts, which step people get stuck on,
which feature shipped last week and needs the attention, or which screen the
founder is quietly embarrassed by. Only they know that, and most people do not
volunteer it because they assume the agent has it covered.

> If you already know the flow you want — the steps, in order — say it and the
> clip will be much closer to what you have in mind. If not, I'll read your
> product and propose one.

**It is an offer, not a gate.** If they do not answer it, read and propose as
normal; do not ask again. The point is that they were told the option existed
before you spent their time on a plan built from inference.

The same applies to anything else they already know: a line of copy that has
to appear, a screen that must not, a feature that is being deprecated. Invite
it once, up front, then get on with it.

Ask outright only for what is not in the artifact:

- **what the clip is for** — a launch, a section nobody scrolls to, an
  onboarding step. Intent is not in the code.
- **which file the ending shows**, but *only* when the ending is media the
  product generated and the disk offers several with nothing to choose
  between them. An ending that is just the finished screen needs no asset and
  no question — see question 3.

Everything else — what is on screen, which flow, which features, how long —
you can draft, and drafting it is your job. Propose, mark what you inferred,
and be specific about what you would change on a "no". A person correcting a
concrete plan gives you better answers in one line than an interview extracts
in four.

**Never generate an asset to stand in for a payoff**, and never substitute a
lookalike. Proposing a real file that already exists is not inventing; making
a new one is. If the disk is empty, that is the moment to ask.

If they answer in fragments ("dashboard, they filter it, end on the published
report"), that is enough — translate it into keyframes yourself. Never hand
them a form to fill in, and never ask them to mark up the composition.

### What has to be settled, however you get there

#### Question zero: the whole product, or one feature?

Ask it in plain words, not as a taxonomy:

> A demo of the whole product, or a scene about one feature?

**A product demo** strings three to five features into movements on a
through-line. The viewer leaves knowing what the product *is*.

**A feature clip** walks one flow start to finish. The viewer leaves knowing
how to do one thing.

They are not the same clip at different lengths. A product demo cut as a
feature clip shows one capability and hides the rest; a feature clip stretched
into a tour skims four things and teaches none.

#### Then infer where it lives — and say so, don't ask

The answer above predicts the destination almost every time. Take the default,
state it in one line with the plan, and let them correct it with a word:

| they said | assume | which means |
| --- | --- | --- |
| whole product | a **standalone** launch video | plays once after a click. No loop seam to protect, sound is available, up to 90s, may end on a card or a logo |
| one feature | a clip **in a page section** | autoplays, so muted and looping. Seamless (hard rule 5), short enough to survive the fifth repeat, title from the section's heading, rhythm matched to its siblings |

Both crossings are real and both happen — a 42s tour living in a page row, a
feature walkthrough posted as a standalone short. That is why you say which
one you assumed. **What you must not do is assume silently**: a launch film
built as a page loop comes out short, silent and ending exactly where it
started, and nobody names the cause — they just say it feels slight.

*"Say it, don't ask it" is about the shape of the exchange, not about hiding
the choice.* Offering it as a pre-selected option with the consequence spelled
out is saying it — see "Put it up as one block" below. What is banned is the
open question with no default, which makes them do your work.

**1. What is being made on screen?** One sentence. Not the product feature —
the thing the viewer watches get built. "A revenue report", "a UGC ad for a
supplement brand", "a deploy going out".
*If this is vague the clip becomes a montage of output, which proves the
product can generate something but never shows what the visitor would
actually do.*

**2. What does it walk, in order?**

*Feature demo:* the real steps of the one flow. Paste URL → binder. Pick face
→ lock sheet. Query → filter → publish.

*Product tour:* which features become movements, in what order, and what
carries the viewer between them — a piece of state that survives the cut, a
line of copy, one character who reappears. A tour with no through-line is a
slideshow of screenshots.

Either way the copy comes **from the live product, not invented**.
*Getting this wrong is the only defect that cannot be fixed in the edit.*

> **Read both the site and the app. They answer different questions.**
>
> The **marketing site** tells you *which* features matter and *in what
> order* — the running order of its sections is the company's own ranking of
> what it sells, and its headline is the promise the clip has to keep.
>
> The **app** tells you what those features actually look like: the real
> screens, the real steps, the real copy on the buttons.
>
> Neither alone is enough, and the failure modes are opposite. Build a tour
> from the site and you get a montage of claims with no screens under them.
> Build it from the nav and you tour whatever happens to be in the sidebar —
> Settings, Library, Analytics — while the three things the front page leads
> with go unmentioned. This has been measured: a tour drafted from a sidebar
> alone opened on the product's *third* priority, skipped two of its four
> headline features, and included a screen the front page does not mention.
>
> So: take the running order from the site, take the screens from the app,
> and say which came from where when you propose it.

**3. How does it end?** Usually you already know, and should not ask.

**The default: it ends on the finished thing.** The flow completes and the
last state stays on screen long enough to be read — the report published, the
sheet locked, the short exported. That is drawn by the composition like every
other frame; there is no separate asset and nothing to request. Hold it
2–3 seconds. A clip that cuts the instant the last button is pressed feels
like it was interrupted, and the viewer never sees the thing they were
promised.

Then: a page clip folds back to the dark ground it opened on (hard rule 5); a
standalone one may end on a card, a logo, a CTA.

**The exception, and the only time to ask: when the payoff is media the
product generates** — a rendered video, a generated image, a character. Then
it has to be a **real file that already exists**. Never generate a stand-in
and never substitute a lookalike, because a fabricated payoff misrepresents
the one thing a viewer is actually judging: output quality.

*That case is also where these clips lie. A clip arguing "same face in every
scene" that ends on a different person destroys its own claim in the last
four seconds, and no edit repairs it. If the payoff is generated media, check
that the thing in the ending is the thing from the flow before you shoot.*

### Put it up as one block, not as an interview

Everything above is *what* has to be settled. This is *how* to put it, and the
form matters as much as the content: three prose questions in a row read as an
interrogation, and people answer interrogations badly.

**If the harness has a structured question tool — Claude Code's
`AskUserQuestion` — use it.** One block, three questions, each option carrying
a one-line consequence, and **your own inference marked `(Recommended)` and
listed first**. Everywhere else in this section says *state your assumption and
let them correct it with a word*; a pre-selected recommendation is that, done
properly. It is not an interview — it is your plan, pre-filled, one click from
being corrected.

Without such a tool, ask the same three in **one message**, marking which
answer you would take if they say nothing.

**The three, and nothing else:**

| header | question | options |
| --- | --- | --- |
| `Scope` | A demo of the whole product, or a scene about one feature? | **Whole product** — 3–5 features as movements on a through-line; they leave knowing what it *is*. · **One feature** — one flow start to finish; they leave knowing how to do one thing. |
| `Where` | Where does it live? Sets the loop seam, the sound and the length ceiling. | **In a page section** — autoplays, so muted and seamless; 8:5 tile, 14–25s for a feature, 35–60s for a tour. · **Standalone** — plays once, sound is real, up to 90s, may end on a card. |
| `Flow` | Do you already know the steps you want walked? | **No, read my product and propose** — running order from the site, screens from the app. · **Yes, I'll describe them** — fragments are fine: "dashboard, they filter it, end on the published report". |

Mark the recommendation on `Where` from the answer you expect on `Scope` — a
tour is nearly always standalone, a feature clip nearly always a page loop.
Both crossings are real, which is exactly why it is offered rather than
assumed silently.

`Flow` is the §1 invitation in a form people actually answer. Recommend "read
my product" — that is the honest default — but the option to describe it has
to be visible, because the code cannot tell you which path converts or which
screen the founder is embarrassed by.

**Never put length or pace in that block.** Both get answered "short" and
"fast" on reflex, and a demo that rushes the steps it exists to show is the
result. Derive the number, show the arithmetic, name the alternatives — the
section below is how.

**A fourth question only when the ending is media the product generates and
the disk offers several files with nothing to choose between them.** Options
are the real filenames. Never a generated stand-in.

Do not add a question for the title, the pace, the palette or the delight
budget. Those are yours to decide and to say in passing.

### The three with defaults — state your choice, don't ask

Decide these yourself and say what you picked in one line. Only ask if the
user has already shown they care.

- **Title text.** Defaults to the headline of the section the clip sits in,
  with a kicker drawn from its body copy. 2.2s.
- **Length.** Derive it from the flow, never default to it. Budget one step
  at the pace below, add 66 for the title and ~30 for the outro, and set
  `<CLIP>_LEN` to the total.

  | pace | simple step | movement with its own beats |
  | --- | --- | --- |
  | punchy | 70 | 170 |
  | **standard** (default) | **100** | **240** |
  | cinematic | 140 | 330 |

  A *simple step* is one action and its answer — a click, a panel arriving.
  A *movement* has internal beats: a list assembling row by row, a belt
  rotating through seven formats.

  **Show the arithmetic, don't just announce a number.** A number with no
  derivation reads as arbitrary and the user has nothing to push against:

  > Four steps and a reveal, standard pace: 66 + 4×100 + 240 + 30 = 736
  > frames, 24.5s. Say "punchy" for ~18s or "cinematic" for ~32s.

  That line is the whole interaction. **Do not ask which pace they want** —
  pace is taste with no right answer, and offered as a question it gets
  answered "fast", which is how a demo ends up rushing the steps it exists
  to show. State the default, name the alternatives, move on.

  In a page section: a feature demo lands at 14–25s, a product tour at
  35–60s, and clips sharing a row should share a rhythm — match a sibling if
  there is one. Standalone: the ceiling lifts to 90s, because nobody is
  watching it for the fifth time.

  *If the total falls outside the band for the kind you were told,* say so and
  check — usually it means a step was missed or a movement is really two.
- **Where the delight budget goes.** One hero beat per phase. Name which
  element the phase is about and spend it there.

### Then show the shot list, and wait

Before you write a line of a composition, put the beat sheet back in the chat.
Not code — the plan. One line per phase: the frame it starts on, what happens,
and which single element carries that phase.

> ```
> t0    title     "Acme Studio" · "Ask a question, publish the answer"
> 0     query     types "Revenue by channel, last quarter", hits Run
> 96    results   five channel rows stagger in, the counter lands on 1,940
> 184   filter    "Paid only" lights, three rows dim, the total recounts
> 274   publish   press, the confirmation springs into its slot
> 380   out       folds back to the dark ground
> ```
> Four steps and a hold: 66 for the title, four steps just under the standard
> 100, and 34 to fold out — 480 frames, 16s. Ends on the published report. Say
> "punchy" for ~12s.

That list is `src/compositions/Demo.tsx`, frame for frame. Open it next to this
and every number lines up.

Then stop and let them read it. This is the only cheap moment left: a wrong
flow costs one message here and a rebuilt composition later, and §1 question 2
is the defect that cannot be fixed in the edit. A correction at this point is
someone moving a line in a list.

Keep it to the phases. Do not list every entrance and colour ramp — a shot
list nobody finishes reading is not a checkpoint, and the point is that they
answer.

### Then read the screen you are about to rebuild

The shot list says *what happens*. This decides *what it looks like*, and it is
the step that determines whether someone who uses the product every day
recognises their own software. Skip it and you get this kit's template wearing
the product's name in the title bar: plausible, generic, and not theirs.

**Nothing that appears on screen may be invented.** Not a row, not a card, not
a label, not a count, not a colour. If you cannot find where something on
screen comes from, you have not finished reading — that is not a licence to
write a convincing version.

**First, adopt the palette. It is one command and it is not optional.**

```sh
npm run adopt                          # finds the stylesheet
npm run adopt ../src/app/globals.css   # or point at it
npm run adopt ../src/app/globals.css --curves
```

This rewrites `src/theme.css` from the product's own tokens and, with
`--curves`, copies its `cubic-bezier` easings into `src/motion.ts`. Run it
before you draw anything, and **read the report it prints** — a `!` line means
that token fell back to this kit's placeholder, and a placeholder purple next
to a real brand colour looks less like the product than plain grey would. If
something falls back, find the product's name for it and add it to `ALIASES`
in `scripts/adopt-theme.mjs` rather than hardcoding a hex in a composition.

Two failures to expect. A product whose theme lives in JS rather than CSS —
`tailwind.config.ts`, a `tokens.ts` — gives the script nothing; read the values
and write `src/theme.css` yourself, keeping the kit's token *names*. And a
stylesheet that defines only a light palette: the script says
`no dark block found`, and you then owe the user a sentence about which stage
the clip runs on, because a light app on the dark ground the title card and
the outro sit on is a luminance cliff at both ends.

**Do not skip it because the placeholder palette looks fine.** It does look
fine — it was designed to. That is exactly why demos ship in it.

Then four things to find, in this order.

**1. The screen's own source, and what it actually renders.** Start at the
route and follow the component tree to the end. A route is often a thin
wrapper — `/app/studio/marketing` can turn out to be another workspace opened
with a prop, and the thing you are drawing lives two files away.

**2. The data behind every list on screen.** Rows, cards, chips, steps, tabs
and empty states almost never live in the page. They sit in a constants or
meta module, and that module holds the real names, the real subtitles and the
real order. Take a string you can see and grep it back to where it is defined:

```sh
grep -rn "Brand guidelines" src/ | head
```

Then use the **whole** list, in its order. Drawing five of eight items is the
same defect as inventing five — the viewer counts.

**3. The theme this surface runs in.** Light or dark is a property of the
screen, not of the product: a marketing page and an app shell routinely
disagree, and one product can hold both. A product also usually has more than
one accent — taking `--primary` because it is first in the stylesheet is
exactly how a purple surface comes out green. Read the component and see which
token it reaches for.

**4. The arrangement, out of the markup itself.** Column count, group
headings, the anatomy of a single card — index, title, subtitle, state — and
the order they sit in. This is the part that makes it *their* screen rather
than a screen, and it is the part an agent skips, because reading a component
tree for layout is slower than inventing one that looks reasonable.

It is all there. A grid class carries the column count. Padding, gap and the
type scale carry the density, which is most of why a rebuild looks like a
different product even when every label is right. Nesting carries the grouping.
Read the classes on the elements you are drawing and resolve them — a
`grid-cols-2 gap-4 p-6` with `text-sm text-muted-foreground` under a
`text-lg font-semibold` is a card you can rebuild exactly, and guessing at it
is how eight documents in two columns became five rows in one.

> **The case, and it is this repo's own.** An agent shooting Athana's Marketing
> Studio pulled the button labels out of the code — `Render`,
> `Rendering scene…`, `Describe the shot you want first` — and stopped there.
> It then drew a five-row "Brand binder" it had made up, on a dark ground, in
> the product's green. The real binder is eight documents with their own
> subtitles, sitting in `src/lib/brand-knowledge-meta.ts`; the surface is light;
> and it is purple, because it belongs to Mira and Mira has her own token. All
> three facts were in the repo the agent was already reading. The clip rendered
> clean, passed the gate, and was worthless — the same product's in-house
> pipeline, given the same codebase, had reproduced all of it.

**Do not ask for a screenshot.** Everything a screenshot would tell you is in
the markup, and asking for one is how an agent gives itself permission to skip
step 4. The arrangement is the JSX; the density is the padding, the gap and the
type scale on those elements; the ground and the accent are the classes and the
tokens they resolve to. Read them. It is more work than gla