Onboarding flow teardown

---
name: onboarding-flow-teardown-table
description: "Find competitors' onboarding screens (invite, empty state, checklist, import, upgrade) in their public tutorials with Vivu and get a frame checked teardown table. Use for onboarding redesigns."
---

Onboarding flow teardown from competitor videos

This skill takes the competitors a product design team wants to study and the onboarding screens it cares about (the sign up form, the invite teammates dialog, the first empty project, a getting started checklist or guided tour, the data import flow, the upgrade or plan screen) and returns a teardown table: for each competitor and screen type it found and checked, the video, the minute and second, the screen title and button labels read from a full frame, the frame itself, a link to the competitor's own public video at that second, and an empty design notes column. Claude picks a few official getting started and tutorial videos per competitor by title, downloads them on the user's computer, prices them against the user's Vivu plan, uploads them to a private Vivu project, runs one precise search per screen type, checks every returned window on a half second contact sheet, reads the title and buttons from a full frame, and writes the table. The designer pastes it into their Figma or Notion teardown board.

The value is in what only the picture shows. Help centers list features but rarely show first run screens, video titles stop at "how to get started", and narration says "click here to invite your team" without saying what the dialog looks like or what its button says. Vivu's picture search only suggests where to look. In our test run the final wordings returned no window that failed its frame check, but the first wordings for the empty state and the import flow did return look-alike screens (a board that already had items, a new project chooser with an import tile), and several brief or repeated screens were never returned. So every window stays a candidate until a contact sheet and a full frame show the screen, the text in the table comes from the frame and never from Vivu's reason, and a screen with no row may still be in the videos.

When to use

Use when a designer or researcher asks "how do our competitors handle invites and empty states?", "pull the onboarding screens from these competitors' tutorial videos", "build an onboarding teardown for our redesign", or "what does each competitor's upgrade screen look like?".

Not for these:

1. A one off question about one video ("when does the import dialog open here?"): search Vivu directly and look at the frames.
2. Pricing pages, roadmap remarks or feature lists for a sales battlecard: that is a competitive intelligence job with different queries and a different reader.
3. Your own product's recordings or user test sessions: the screens are already yours; use your design files or a usability skill.
4. Judging which competitor's onboarding is better, or guessing conversion rates. The skill reports what is on screen; the design notes column is for the team.
5. Anything a competitor has not published. Only public, official videos go in.

Working principles

1. Report measured numbers, not estimates. When a number is an estimate, say so.
2. Nothing is verified until it has been checked against the source video. Vivu's windows are candidates; a row enters the table only after a contact sheet and a full frame show the screen.
3. Stop and tell the user when a required capability or tool is missing. Do not guess around it.
4. Ask the user before anything that is expensive to redo (the video list and its index minutes, before upload) and before anything that acts on their behalf (a write to Notion or a shared drive). Show one sample row first.
5. Titles and button labels come from the frame, never from the reason text, which can describe things that are not on screen.
6. A missing row is not proof. Official tutorials often start from a signed in workspace, and brief screens can be skipped by search, so the table never says a competitor lacks a screen.

What you need before starting

Check each item at the start of the run and tell the user plainly what is missing before doing anything else.

This skill needs Claude Code on the user's computer (the terminal or the Code tab of Claude Desktop), because it downloads videos and runs ffmpeg on local files. Claude on the web and cloud sessions cannot reach the files or a residential IP. Nothing recurs, so no scheduler is involved; run it once per teardown.

Inputs to collect

Ask for anything missing, most important first.

1. COMPETITORS: the products to tear down, three or four is typical, with their official YouTube channel if the user knows it. Required.
2. SCREENS: the screen types to find. Default: signup_form, invite_teammates, empty_state, onboarding_checklist, import_data, upgrade_paywall.
3. WORK_NAME: a short name for the working folder and the Vivu project. Default: "onboarding-teardown" plus today's date.
4. Videos per competitor. Default: two or three official videos whose titles say getting started, tutorial, how to, onboarding, invite, import or billing, each under ten minutes.
5. Where the table goes. Default: a local CSV the designer pastes into Figma or Notion.

Files and state

Keep everything in one working folder:

WORK_NAME/
  config.json        competitors, screens with query and maximum_results, Vivu project id
  videos.csv         competitor, video_id, title, public_url, file, listed_name, duration_s, indexed_id (the video id Vivu lists)
  archive.txt        yt-dlp download archive
  upload/            the downloaded mp4 files only
  results/           one JSON per screen: search results without the result page link
  sheets/            contact sheets per window
  read/              full frames the titles were read from
  candidates.csv     every window Vivu returned, with its check outcome
  teardown.csv       one row per checked window
  coverage.md        competitor by screen grid: rows found, no row
  state.json         steps done, files downloaded and uploaded, screens searched with job ids, windows checked

A rerun reads state.json first and skips finished steps: a downloaded file is not downloaded again (archive.txt), an uploaded file is not uploaded again, a screen with a saved result is not searched again, and a window with a recorded outcome is not checked again.

Step 1: Check the Vivu connector and the setup

Goal: confirm every requirement before spending anything.

1. Call vivu_get_account. If the tool does not exist, tell the user to add the Vivu connector in Claude (https://mcp.vivu.ai/mcp) and stop. If the account does not show can_create_projects: true, or a later write call fails with "has not granted vivu.write", ask the user to reconnect Vivu and allow write access, then stop until they have.
2. Run yt-dlp --version, ffmpeg -version, ffprobe -version and node --version.

Done when vivu_get_account shows can_create_projects: true and the four tools print their versions.

Step 2: Pick the competitors, screens and videos

Goal: a short list of official videos most likely to show the screens, approved by the user.

1. Confirm the Compliance items below with the user before any download.
2. For each competitor, list its official channel's videos by title. A channel search needs the exact handle; when a guessed handle fails, find the channel from the company's website or with a YouTube search first:

yt-dlp --flat-playlist --playlist-end 15 --print "%(id)s|%(duration)s|%(title)s" "https://www.youtube.com/@HANDLE/search?query=getting%20started"
yt-dlp --flat-playlist --print "%(id)s|%(duration)s|%(channel)s|%(title)s" "ytsearch10:BRAND getting started tutorial"

HANDLE is the channel handle, BRAND the product name. Keep only videos from the competitor's own channel. Titles are text, so this step costs nothing; indexing every tutorial would not. 3. Pick two or three videos per competitor whose titles touch the screens: getting started, invite, import, billing or plans. Official tutorials usually start inside a signed in workspace, so the sign up form is the screen least likely to appear; say so to the user rather than padding the list. 4. Write videos.csv with competitor, video_id, title and public_url (https://www.youtube.com/watch?v=VIDEO_ID).

In our test run the videos were picked by title from the official channels of several software vendors, and the screen list came from the request, not from a designer; confirming both with a user was not exercised in our test run.

Done when the user approves the competitors, the screen list and videos.csv.

Step 3: Download, measure and price

Goal: the approved videos on disk and an indexed set the user's plan can pay for.

1. Download each video at 720p into upload/. 720p keeps dialog titles and button labels readable at a fraction of the 1080p size. Test one video first:

yt-dlp --js-runtimes node --restrict-filenames \
  -f "bv*[height<=720]+ba/b[height<=720]" --merge-output-format mp4 \
  --match-filter "duration<=600" \
  --download-archive WORK_NAME/archive.txt \
  -P "temp:WORK_NAME/.tmp" -P "home:WORK_NAME/upload" \
  -o "%(id)s_%(title).60B.%(ext)s" --retries 5 \
  "https://www.youtube.com/watch?v=VIDEO_ID"

--restrict-filenames keeps file names to plain ASCII without spaces or brackets, and the 11 character video ID at the front is how results are matched back. If the default client returns "HTTP Error 403: Forbidden", add --extractor-args "youtube:player_client=web_embedded". The youtube-competitor-watch skill (https://vivu.ai/skills/youtube-competitor-watch) covers channel verification and download troubleshooting in more depth. 2. Measure each file, one file per command (ffprobe rejects a second input file):

ffprobe -v error -show_entries format=duration -of csv=p=0 "WORK_NAME/upload/FILE"

Write duration_s into videos.csv. 3. Call vivu_get_usage and show one table:

Plan facts: Free is $0 a month with 20 index minutes a month and 50 search credits a month; Premium is $30 a month with 180 index minutes and 500 search credits. A precise search uses 5 credits in total. A teardown of three or four competitors with two or three short tutorials each usually fits Premium; on Free, start with the one or two videos per competitor whose titles match the most screens (estimate).

4. If it does not fit, offer levers in this order: drop the videos whose titles match the fewest screens, drop screen types the team does not need this round, split competitors across two months, and only then move to a larger plan. Never drop a video or competitor the user asked for without saying which one, and never trim or recompress a file to save minutes.

The account used in our test run returns no allowance figures, so the comparison with a real plan and the user's approval were not exercised in our test run.

Done when every approved video is in upload/ with a duration_s, and the user approves the index minutes and credits.

Step 4: Upload and index

Goal: every approved video indexed in a private Vivu project.

1. Call vivu_list_projects and reuse a project named "Onboarding teardown WORK_NAME" if one exists. Otherwise call vivu_create_project with that name and visibility "private". The default visibility is organization, which shows the project to everyone in the user's Vivu organization; competitor research usually should not be.
2. Call vivu_open_upload_page with the project ID immediately before uploading. The link expires in 180 seconds and works once, so never post or store it. Give it to the user to open in their own browser and select the files in upload/, or open it in a browser tool that can attach local files. Claude in Chrome accepts at most 10 MB per upload call; larger files go through the user's own browser or the Vivu web app. Never split or recompress a file to fit.
3. Poll vivu_list_videos until every file shows ready. Vivu replaces spaces and punctuation in file names with underscores, so match each listed name to videos.csv by the video ID at the start of the name; if that fails, match duration_ms against duration_s. Record each Vivu video id in videos.csv and state.json.

In our test run the 9 videos (29.52 minutes) were indexed one or a few at a time and all showed ready by the poll 10.6 minutes after the upload started; the names came back unchanged. They went through the upload page with an automated browser, so opening the link in the user's own browser was not exercised in our test run.

Done when every file in videos.csv shows ready and has a Vivu video id.

Step 5: Search each screen type

Goal: a saved list of candidate windows for every screen type.

One precise search per screen type, because each type is its own group of rows. The chain behind each row: the precise search suggests windows, the contact sheet finds the tile where the screen is open, the full frame gives the title and buttons, and the table takes that second. Every search is precise because only precise returns a time window; fast returns whole files with an empty reason, and the videos are already a chosen set. There is no switch to speech: narration says "invite your team" before or after the dialog opens, and a teardown row needs the screen itself.

The wordings describe what is visible (layout, fields, buttons), not the competitor's own words or brand, so one query works across competitors:

The empty_state and import_data wordings were tuned on our test corpus, each after 1 rewording on the same corpus; the others are first wordings. No video in our test corpus showed a sign up form, so the signup_form wording was only checked for not returning look-alikes; whether it finds a real sign up form is untested. A wording for a new kind of product (a design tool, a developer platform) is untested until its first windows have been through Step 6.

How far to trust the searches: describing a screen type by its look (an empty table, a plan picker) is picture search, which is weak in Vivu today. With the final wordings, every window on our test corpus showed the screen asked for, but each type had only one to eight examples there, the first wordings let look-alike screens through, and brief or differently shaped screens were missed. So every window goes through Step 6, and a missing row proves nothing.

maximum_results is 10 because two or three short tutorials per competitor rarely show one screen type more than a few times each, and it is also the ceiling on how many windows come back. If a search returns exactly 10, tell the user and, once they agree, run it again with 30 (5 more credits, estimate).

That rerun with a larger maximum_results was not exercised in our test run.

Run each query with vivu_search_videos (project_id, query, mode, maximum_results). It returns a job ID. Call vivu_get_search_results until complete is true; each status call can wait up to 45 seconds, so a pending search is not a stalled one. Save each completed result as results/FIELD.json without its result_page_url field and record the job_id in state.json. Show the Vivu result page link in the live reply only; it expires after four hours, so it never goes into a saved file or the table.

Done when every screen type has a completed result saved in results/.

Step 6: Check every window on a contact sheet and a full frame

Goal: for every returned window, a yes or no on whether it shows the screen, and for every yes, a full frame to read from.

Sort each screen's windows by video and start_ms. Cut contact sheets from the local file at two frames a second:

mkdir -p "WORK_NAME/sheets" "WORK_NAME/read"
ffmpeg -v error -y -ss START -to END -i "WORK_NAME/upload/FILE" -vf "fps=2,scale=480:-2,tile=5x4" "WORK_NAME/sheets/FIELD_VIDEOID_STARTMS_%02d.png"

FIELD is the screen type, FILE the local file name, VIDEOID the YouTube ID at the start of the file name, STARTMS the window's start_ms, START and END the window's start_ms and end_ms divided by 1000. Each sheet holds 20 tiles covering ten seconds; tile k on sheet n (both counted from 0) is at roughly START + 10 * n + k / 2 seconds, and the file ending _01 is sheet 0.

1. Look at every sheet of the window and find the first tile where the screen is open: the dialog, the empty table, the checklist, the import step, the plan picker. Windows are wider than the screen, so the first and last tiles are often the page before or after it.
2. Extract a full frame half a second after that tile's time, T:

ffmpeg -v error -y -ss T -i "WORK_NAME/upload/FILE" -frames:v 1 "WORK_NAME/read/FIELD_VIDEOID_TMS.png"

TMS is T in milliseconds. A tile can show a frame slightly later than its computed time, so the frame at the tile's own time can still show the previous page. If the full frame does not show the screen, add half a second to T and extract again, up to the end of the window. 3. Read the screen title, the field labels and the button text from the full frame. Compare with the screen type asked for. A board that already has items, a menu that only lists an Import or Invite entry, a new project chooser, a billing overview or settings page, or a title card is a rejection, whatever the reason says. 4. Record every window in candidates.csv (screen, video, start, end, outcome, note) and in state.json. Rejected windows stay in candidates.csv with what they show instead and never enter the table.

Worked example from our test run

The test corpus was public: 9 official getting started, how to and billing tutorials (29.52 minutes) from the YouTube channels of several work management, database and notes products, downloaded at 720p. Before any search, every screen of the six types and the look-alike screens near them were marked by hand on coarse contact sheets of every video. After the search, one empty page seen inside a returned window was added to those marks, and one mark was moved a few seconds earlier because its window showed the empty table sooner than the coarse sheet had.

1. Sign up form: 0 returned. No official video in the corpus showed one, and nothing else was returned in its place.
2. Invite teammates: 5 returned, 5 real, 0 false, 3 missed. The missed ones were a create a team panel with a members field, a project share dialog, and a share popover that was open only briefly. An invite button in a sidebar and menu entries that only say invite were not returned.
3. Empty state: the first wording returned 6, 4 real and 2 false. Both false ones came from one vendor's tutorials: a new board that already held items, and a new empty group added inside a filled table; the reason called them blank. After 1 rewording on the same corpus (the wording in the table) it returned 3, 3 real, 0 false, 1 missed: a new page with only its title, which the first wording had found.
4. Onboarding checklist: 2 returned, 2 real, 0 false, none missed. One was a popup on screen for only a brief part of its window; its start, middle and end frames all missed it, and only the contact sheet showed it.
5. Import data: the first wording returned 3, 2 real and 1 false, a new project chooser with an import spreadsheet tile. After 1 rewording on the same corpus it returned 2, 2 real, 0 false, none missed. Both real ones came from a single vendor's import tutorial, so this is a small sample.
6. Upgrade or plan screen: 1 returned, 1 real, 0 false, none missed. It was the only one in the corpus; the billing overview, invoice and payment method pages around it were not returned.
7. Across the final wordings that is 13 windows, 13 real by their frames, 4 missed. For an empty page that flashed by, the full frame at the tile's computed time still showed the previous page, and the frame half a second later showed the empty page, which is why the frame step adds half a second.

Done when every window in results/ has a line in candidates.csv, and every window judged real has a full frame in read/.

Step 7: Write the teardown table

Goal: a table the design team can paste into its board and check against the competitor's own video.

Show the user one sample row and the field mapping, and wait for an OK before writing the rest:

competitor,flow_screen,video_file,video_title,mm_ss,seconds,screen_title_read_from_frame,buttons_read_from_frame,frame_path,public_url_with_t,status,design_notes
BRAND,upgrade_paywall,VIDEOID_Billing_FAQ.mp4,Billing FAQ,01:08,68,"Make changes to your plan: Basic, Standard (Current plan), Pro, Enterprise; Choose team size",Continue to checkout,read/upgrade_paywall_VIDEOID_69500.png,https://www.youtube.com/watch?v=VIDEOID&t=68,VERIFIED,

Write teardown.csv with one row per real window, sorted by screen type, then competitor, then time. A screen type with no real window anywhere gets one NOT FOUND row with the note "no checked window; this does not prove the videos never show it". Write coverage.md as a competitor by screen grid that says "no row", never "not in product". Every link uses the competitor's own public video, never a Vivu result page link, so it keeps working after that link expires.

Then tell the user, per screen type, how many windows Vivu returned, how many were real and how many were rejected, which competitors have no row, and that a missing row does not mean the competitor lacks the screen.

The table is the designer's to paste. If the user asks Claude to write it into Notion or another shared place, name the destination, show the fully rendered page with one row and its frame, and wait for a yes before the write. Frames are competitor screenshots: keep them in internal boards only.

In our test run teardown.csv, candidates.csv, coverage.md and a Notion page were rendered from the dry run's windows and frames; showing a sample row to a designer and writing to Notion were not exercised in our test run.

Done when teardown.csv and coverage.md exist, every VERIFIED row has a frame in read/, the user approved the sample row and the mapping, and state.json marks the run done.

Compliance

1. Use only videos the competitor itself published publicly. Downloading YouTube videos may conflict with YouTube's Terms of Service; keep downloads for internal design research, do not redistribute them, and have the user confirm this is acceptable for their organization before Step 3.
2. Frames are screenshots of another company's product. Keep them in internal boards and documents; do not put them in marketing, sales decks or public posts without a separate review.
3. Presenters in official tutorials appear in published videos; the skill does not identify anyone. If a video shows a child, leave it out.
4. The videos stay in the user's Vivu project until the user deletes them. Create the project as private; the default is visible to the whole Vivu organization. Delete videos or the project only when the user asks, and confirm first.
5. The skill does not judge which onboarding is better or guess conversion effects, and it does no face, logo or identity recognition. Any write outside the working folder goes through the approval in Step 7.

Known failure modes