---
description: Make a polished narrated walkthrough/demo/pitch video of a running app with Zyng (the `zyng` MCP server). Apply whenever the user wants a product walkthrough, demo, or pitch video of their app, or says "record my app", "make a demo video", "zyng this", or "publish a pitch".
globs:
alwaysApply: false
---

# Zyng — make a polished narrated walkthrough (do not shortcut to a raw screen recording)

Anyone can screen-record an app; your job is the hard part: a POLISHED, watchable walkthrough. You get
there by asking for the STORY first, planning it, and showing the user before spending anything. You author
the steps from the app's source; Zyng records + renders a managed narrated MP4 on the user's credits. The
two secrets (the API token and any site password) are the user's — never handle their raw values.

Needs the `zyng` MCP tools (`guide`/`plan`/`account`/`voices`/`capture_clips`/`review`/`estimate`/`publish`).
If they are missing, tell the user: `pipx install zyng-mcp && python -m playwright install chromium`, mint a
token at app.zyng.work, add the `zyng` server to the MCP config (see zyng.work/connect), then stop until the
tools load. The app must be running locally (ask for the URL if unknown).

## The flow — follow it in order; never jump straight to capture -> publish
1. **`account`** — confirm credits (stop if `balance_seconds` is 0).
2. **ELICIT the story** from the user: which 3-5 features matter, the one-line HOOK (the promise), and the
   AUDIENCE. Do not guess — a demo of everything is a demo of nothing.
3. **`plan({hook, audience, features, cta})`** — write the returned `storyboard_html` to a file, have the
   user OPEN it (with the `summary`), and WAIT for approval. The `segments` are your publish skeleton.
4. **`voices`** — suggest the standard voice; offer a premium one only if `eligible_premium` is true.
5. **`estimate(segments)`** — tell the user the credit cost and whether their balance covers it.
6. **`capture_clips`** — ONE clip per feature, never one long take. Author selectors from the frontend
   source (ids / test-ids / link text, never pixel-guess), frame each clip with `"embed":"frame"`, and
   bracket every login or critical transition with an `expect` step
   (`{"do":"expect","selector":"text=Dashboard"}`) so a stalled flow FAILS the capture instead of silently
   recording a stuck screen you would pay to render. On `ok:false`, fix the selector from source and retry.
7. **`review(spec, clips, estimate)`** — write the returned `review_html` to a file and have the user OPEN
   it: it plays the REAL captured clips + narration + cost. Fix + re-review on any warnings or a wrong/stuck
   screen. It returns a `review_token` bound to this exact composition.
8. **`publish(spec, clips, review_token=...)`** — only after the user approves. publish REFUSES without a
   matching `review_token` (`code: "review_required"`), so review is mandatory; if you changed the spec
   after reviewing, re-run `review` for a fresh token. Returns the video path + share link.
9. **Report** the video path, the share link, and the credits spent.

Each tool result also carries a `next_step` field — follow it.

## Rules
- Never put the API token or any password in a tool call, spec, narration, log, commit, or message.
- Auth: ask the USER to run `zyng-mcp login <url>` (form login, captures then run authenticated) or
  `zyng-mcp secret set NAME` (Basic Auth -> `http_auth="NAME"`). Never run them yourself; never type a password.
- One or two sentences of narration per beat; let the app's real UI carry the demo.
- Do not skip the preview/approve step to "save time" — spending the user's credits without a yes is the
  one thing not to do.
- If a tool response has `update_available: true`, tell the user once to `pipx upgrade zyng-mcp` and restart
  the MCP server. Do not block the task on it.