Sponsor read proof sheet

---
name: sponsor-read-proof-sheet
description: "Build a sponsor proof sheet from your own published videos with Vivu: where each sponsor read sits, how long it ran, and when the code and link were on screen. Use when a brand deal wraps."
---

Sponsor read proof sheet from your own videos

This skill takes the finished episodes a creator published under one brand deal and returns a proof sheet for the brand contact: one row for each sponsor read (the opening mention, the main read, a mention in the outro), with the episode, the start and end as MM:SS, how many seconds it ran, the key line copied from the creator's own captions, the promo code, link or ad label read from a full frame, when that text was on screen and for how long, the frame it was read from, the public video link with a timestamp, and an empty "brand confirmed" column. Claude measures the episodes, prices the job against the user's Vivu plan, uploads only the episodes the deal covered to a private Vivu project, runs two precise searches, checks every window against the captions or the frames, sweeps the captions and the first and last 32 seconds of each episode for reads and labels the searches missed, and writes the sheet for the creator to check and send.

The value is in what only the picture shows. Captions tell you the code was said; they do not tell you whether "CODE RIDGE20" was actually burned into the corner, for how many seconds, or whether a "#AD" label sat on screen in the opening. Brand contacts ask exactly that, and an editor forgetting the lower third is a common miss that only the frames reveal. The hard parts are telling a sponsor read apart from the creator's own merch plug, a membership pitch or a subscribe reminder, and finding small corner text that slides in and out. So every window Vivu returns stays a candidate until the captions show the read or a full frame shows the text, and the words in the sheet come from the captions and the frames, never from Vivu's reason text.

When to use

Use when a creator asks "the Corvid Maps deal covered my last four videos, make me the proof sheet they asked for", "where exactly are the sponsor reads in these episodes and how long did each run?", "did the promo code actually show on screen in every episode?", or "I need timestamps for every sponsor mention before I invoice".

Not for these:

1. One episode and one question ("when does the ad start in this video?"): open the video or search Vivu directly.
2. Judging whether a read performed, or whether the disclosure meets a platform's or regulator's rules. The sheet lists where reads and labels are and how long they ran; the creator and the brand decide what that means.
3. Videos that are not the user's own: another channel's uploads, or a brand's own ads (the promo-clip-reuse-check skill, https://vivu.ai/skills/promo-clip-reuse-check, checks a brand's own promo cuts for old offers).
4. Cutting the reads into short clips or editing the episodes. The skill does not edit or export anything.
5. A whole channel back catalog. Upload only the episodes this deal covered; a full catalog costs more index minutes than any plan holds.

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 episode. A spoken window is a candidate until the captions show the sponsor read; an on-screen window is a candidate until a full frame shows the code, link or label. Vivu's reason text paraphrases and has claimed sponsor text on screen where there was none, so it never fills a cell.
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 indexed minutes, before upload) and before anything that acts on their behalf (putting the sheet in a shared folder or drafting a message to the brand). The skill writes local files only; the creator sends the sheet.
5. Every episode gets the same sweeps. A read or label the searches did not return can still be found in the captions or in the opening and closing seconds, so those sweeps run on every episode before the sheet says "none". On-screen sponsor text that appears outside a read and outside the opening and closing sweeps (Step 6) is found only by the on-screen search. In our test run that search missed 1 of 5 items, so tell the creator about this gap before the sheet goes out.

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 reads local files and runs ffmpeg. It downloads nothing from YouTube or other sites, so no residential IP is needed. Nothing recurs, so no scheduler is involved; run it once when a deal wraps. The only connector it needs is Vivu.

Inputs to collect

Ask for anything missing, most important first.

1. EPISODE_DIR: the folder with the finished episodes. Required.
2. Which episodes the deal covered. Required; only these are uploaded.
3. SPONSOR: the sponsor's name as the creator says it, plus the agreed code and link. Required for the caption sweep and to check the frames against the deal.
4. The public URL of each episode. Default: blank links, filled in by the creator before sending.
5. WORK_NAME: a short name for the working folder and the Vivu project. Default: the sponsor and month, for example corvid-oct.
6. Where the sheet goes. Default: a local CSV only; the creator sends it to the brand themselves.

Files and state

Keep everything in one working folder:

proof-WORK_NAME/
  config.json        sponsor, code, link, episodes and public URLs, Vivu project id, query wording
  episodes.csv       file, title, duration_s, video_id, captions file, public_url
  upload/            the covered episodes (copies or links to the finished files)
  captions/          one .srt or .vtt per episode
  results/           one JSON per search, without the result page link
  sheets/            half second contact sheets and opening / closing sweeps
  frames/            full frames the on-screen text was read from
  candidates.csv     every window Vivu returned, with the verdict and the reason
  proof_sheet.csv    the sheet: one row per read or on-screen item, plus a row per episode with none
  state.json         steps done, files uploaded, searches run with job ids, windows checked

Run every command from the folder that contains proof-WORK_NAME/. A rerun reads state.json first: an uploaded episode is not uploaded again, a search with a saved result is not run again, and a window with a verdict in candidates.csv 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 ffmpeg -version and ffprobe -version, and check that captions exist for each covered episode (or that the speech to text tool runs).
3. Confirm the Compliance items with the user: these are their own published videos, and anyone else on camera agreed to the original publication, and ask whether any covered episode features children; if one does, upload it only when the creator confirms the guardian consent they hold covers storing it in a private Vivu project, otherwise leave it out of upload/ and mark its on-screen fields NOT VERIFIED (Compliance 3).

Done when vivu_get_account shows can_create_projects: true, both ffmpeg commands print a version, every covered episode has captions or a working speech to text tool, and the user has confirmed the videos are their own and has answered the question about children.

Step 2: Pick the covered episodes and price the job

Goal: only the deal's episodes, measured and priced, with the user's approval before anything is uploaded.

1. List EPISODE_DIR, match the covered episodes by title or date, show the list, and let the user correct it.
2. Copy them into proof-WORK_NAME/upload/ with names that keep only letters, digits, hyphens and underscores (EPNAME below), so Vivu keeps each name as it is. Vivu rewrites spaces and punctuation in file names.
3. Measure each file and write duration_s into episodes.csv:

ffprobe -v error -show_entries format=duration -of csv=p=0 proof-WORK_NAME/upload/EPNAME.mp4

4. 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. For example, five episodes of 12 minutes are 60 index minutes (estimate): more than Free holds, inside Premium.

5. If the job does not fit, offer levers in this order: upload only the covered episodes (never the whole channel), check the episodes across two months, and only then move to a larger plan. Never drop a covered episode without naming it; the brand will ask about every one.

In our test run the 4 episodes measured 8.45 minutes. The account used in our test run returns no allowance figures, so the plan table and the user's approval were not exercised in our test run.

Done when every covered episode is in upload/ with a duration_s in episodes.csv and the user has approved the minutes and credits.

Step 3: Upload and index

Goal: every covered episode indexed in a private Vivu project.

1. Call vivu_list_projects and reuse a project named "Sponsor proof 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.
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 every file 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, and a finished episode is usually larger, so most creators will open the link in their own browser or add the files in the Vivu web app. Never split or recompress an episode to fit.
3. Poll vivu_list_videos about every 30 seconds until every episode shows ready. Match each listed file_name to episodes.csv and record the video_id; when a name does not match, match by duration_ms against duration_s.

In our test run all 4 episodes were ready 4.3 minutes after the upload started. The files 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 row of episodes.csv has a video_id and every episode shows ready.

Step 4: Search

Goal: saved candidate windows for sponsor reads and for sponsor text on screen.

Two precise searches cover the whole batch. fast is not used: it returns whole files with an empty reason, and the file list is already known. The chain: the spoken search finds each sponsor read, Step 5 sets its start and end from the captions, the on-screen search flips from what was said to what was shown (codes, links, ad labels), and Step 6 reads that text from frames and times how long it stayed.

The on-screen query names the kind of text and never the actual code: on other footage, a query that quoted exact caption text made Vivu claim that text where it was only spoken. maximum_results 30 covers up to six episodes with three reads each plus room for extra windows; it is also the recall ceiling, so raise it for a longer deal (the limit is 100).

Run vivu_search_videos (project_id, query, mode "precise", maximum_results) for each. 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 result to results/FIELD.json without the result page link. Show the result page link only in the live reply: it expires after four hours, so it never goes into the sheet. Both searches used the wording above unchanged (0 rewordings).

Done when both result files are saved and their job ids are in state.json.

Step 5: Check the spoken segments

Goal: each spoken window kept or rejected, with exact start, end and key line from the captions, and every short mention the search missed added.

1. Read the caption lines between start_ms and end_ms. Kept: the creator names the sponsor, talks about its product, or gives its code or link. Rejected: the creator's own merch or store, a membership pitch, a subscribe reminder, or a product they say they bought themselves. Count rejected windows as false positives.
2. Set read_start and read_end from the first and last caption line of the read, not from the window. Windows run past the read: in our test run one window ran into the creator's merch plug that followed the read.
3. Copy the key line (the sponsor's name, and the line with the code if one is said) into read_points_quote, word for word from the captions.
4. Sweep every caption file for the sponsor's name, so a one sentence mention the search did not return still gets a row:

grep -n -i -E "SPONSOR|sponsored|brought to you|use code|promo code" proof-WORK_NAME/captions/EPNAME.srt

SPONSOR is the sponsor's name as the creator says it. Mark rows found here as found_by "caption sweep". 5. For a second signal, vivu_get_video_summary with include_segments, start_ms and end_ms around the window gives section summaries. Their boundaries are rough, so never take read_start or read_end from them.

Worked example from our test run

The test corpus was a synthetic creator channel we built: 4 episodes (8.45 minutes in total, much shorter than real episodes) of a talking head hiking show, with one fictional sponsor read across all four, a computer voice, and captions written from the script. Each episode mixes sponsor reads (opening mentions, main reads, outro mentions) with the things a sponsor search should skip: the creator's own merch plug, a channel membership pitch, subscribe reminders, and a line saying a product was bought with their own money. Before searching we wrote down every read and every piece of on-screen sponsor text with its start and end.

The spoken search returned 6 windows: 6 real, 0 false, and 2 missed out of 8 reads. The two it missed were the single sentence opening and outro mentions in the same episode; the caption sweep found both. Some reads in the corpus had the code on screen while they were spoken; the search also found reads with nothing sponsor related on screen (an opening mention, a read where the code is only said, an outro mention), so it was not relying on the picture alone, but both misses were reads with nothing on screen. No merch, membership, subscribe or "bought it myself" line was returned on its own. The on-screen search returned 4 windows: 4 real, 0 false, and 1 missed out of 5. It found both small corner code pills that slide in, the lower third and a silent end card, and it skipped the creator's merch pill in the same style, the subscribe buttons and the chapter titles. It missed a small "#AD paid partnership" label in one episode's opening, which the opening sweep in Step 6 found. Neither scene where the code is said with nothing on screen was returned by the on-screen search. The footage is clean computer graphics, so busy real backgrounds, phone footage and handwritten text are untested.

Done when every spoken window has a verdict in candidates.csv, every kept read has start, end and a quote from the captions, and every caption file has been swept for the sponsor's name.

Step 6: Read the on-screen text from frames

Goal: each on-screen window kept or rejected, with the text copied from a full frame and the seconds it stayed on screen; plus a check of every read window and of each episode's opening and closing.

1. For each on-screen window, and for each kept read window from Step 5, make a contact sheet with one tile every half second:

ffmpeg -v error -y -ss START -t 32 -i proof-WORK_NAME/upload/EPNAME.mp4 -vf "fps=2,scale=256:-1,tile=8x8" -frames:v 1 proof-WORK_NAME/sheets/EPNAME_START_sheet.png

START is the window start in seconds (start_ms / 1000). Tile k is at START plus k/2 seconds, counting from 0 at the top left; one sheet covers 32 seconds, so a longer window needs a second sheet from START plus 32. 2. Find the first and last tile where the text is fully shown; those give on_screen_start and on_screen_end. Windows start before the text slides in and end after it leaves, so the window itself is not the on-screen time. 3. Extract a full frame from the middle of that stretch and copy the text exactly as written:

ffmpeg -v error -y -ss SECONDS -i proof-WORK_NAME/upload/EPNAME.mp4 -frames:v 1 -q:v 3 proof-WORK_NAME/frames/EPNAME_SECONDS.png

4. Label the window. Kept: the sponsor's code, link, or an ad or paid partnership label, readable in the frame. Rejected: the creator's own store or merch link, a subscribe button, chapter titles, product specs, or no text. Check the code against the agreed one from config.json and say so when it differs. Text too small to read is marked UNCERTAIN; never complete it from the reason text.
5. When a kept read has no sponsor text on any tile, write "NOT ON SCREEN (spoken only)" in on_screen_text. This is the row the creator most needs to see before the brand does.
6. Sweep the first and last 32 seconds of every episode at one tile per second for ad labels and end cards outside the reads:

ffmpeg -v error -y -ss 0 -t 32 -i proof-WORK_NAME/upload/EPNAME.mp4 -vf "fps=1,scale=320:-1,tile=8x4" -frames:v 1 proof-WORK_NAME/sheets/EPNAME_open_sweep.png
ffmpeg -v error -y -sseof -32 -i proof-WORK_NAME/upload/EPNAME.mp4 -vf "fps=1,scale=320:-1,tile=8x4" -frames:v 1 proof-WORK_NAME/sheets/EPNAME_close_sweep.png

Mark rows found here as found_by "opening sweep" or "closing sweep".

In our test run every on-screen window began a few seconds before the text appeared, the half second sheets placed each appearance and disappearance to the half second, and one read where the code was only said came out as "NOT ON SCREEN". The opening sweep found the ad label the search missed. The closing sweep was not exercised in our test run, because the only end card was already returned by the search.

Done when every on-screen window and every kept read has a verdict in candidates.csv, each kept item has a frame and its text, and every episode has an opening sweep sheet and a closing sweep sheet.

Step 7: Write the proof sheet and hand it over

Goal: a proof sheet the creator has checked and can send.

1. Show the user one sample row and the field mapping, and wait for a yes before writing the rest:

episode,source_file,segment,read_start,read_end,read_seconds,read_points_quote,on_screen_text,on_screen_start,on_screen_end,on_screen_seconds,frame_path,public_link,found_by,brand_confirmed
"Day pack loop",ep01_daypack.mp4,main read,00:47,01:18,31,"Corvid Maps is the app I use to save trail maps on my phone before I lose signal.","CODE RIDGE20 corvidmaps.com/ridge",00:47,01:12,25,frames/ep01_daypack_59.png,https://www.youtube.com/watch?v=VIDEO_ID&t=46,search,

2. Write proof_sheet.csv with one row per read or on-screen item, and one row saying "no sponsor read found" for any covered episode with none. Also write a one line summary per episode: reads found, total spoken seconds, seconds the code was on screen, and any read where the code was said but not shown. Add one line per search with how many windows Vivu returned, how many were kept, and how many were rejected as false positives (from candidates.csv), and show that line to the user with the sample row.
3. The public link uses the creator's own video URL with a time, never the Vivu result page link, which expires.
4. The creator checks the sheet against their own memory of the deal and sends it. If they ask Claude to put it in a shared folder or draft an email to the brand contact, name the destination, show the full sheet or message, and wait for explicit approval; email goes to drafts unless the user asks to send.

In our test run the sheet has a row for every read and on-screen item across the 4 episodes, plus a short summary per episode. The user's approval of the sample row and any destination were not exercised in our test run, and nothing was sent.

Done when proof_sheet.csv has at least one row for every covered episode, the user has approved the sample row, and any destination outside the working folder has the user's explicit approval.

Compliance

1. Use only the creator's own published videos. Confirm this in Step 1; stop if they are someone else's uploads.
2. Guests and other people on camera agreed to the original publication; this skill only reads the videos for an internal sheet. The skill reads speech and on-screen text only and does not identify anyone by face or voice.
3. If an episode features children, upload it only when the creator confirms the guardian consent they already hold covers storing it in a private Vivu project; otherwise leave it out and fill its rows from the captions alone, marked NOT VERIFIED for on-screen text.
4. The sheet lists where reads and labels are and how long they ran. It does not judge whether a read worked or whether a disclosure meets platform or advertising rules.
5. The episodes stay in the user's Vivu project until the user deletes them. Create the project as private. Delete a project or video only when the user asks, and confirm first.
6. Sending the sheet to a brand acts as the creator; the skill leaves sending to them or asks first (Step 7).

Known failure modes