Client review call revision list

---
name: client-review-revision-list
description: "Turn a producer's notes from a recorded client review call into a revision list with Vivu: the client's words, the call time and the cut's timecode for each note. Use after a review call."
---

Client review call revision list

This skill takes the short notes a producer jotted down during a client review call ("intro too long", "swap music sec 2", "end logo bigger") and the call recordings, and returns revision_list.csv for the editor: one row per note with the call file, the start and end of the client's comment, the client's words from the transcript, the timecode of the cut that the shared player was paused on, the frame it was read from, and an empty column for the editor to mark done. Claude prices the indexing against the user's Vivu plan, has the user upload the calls to a private Vivu project, runs one search per note, checks every hit against the transcript, reads the timecode from a full frame of the screen share, and shows sample rows before writing the list.

The value is in what neither the notes nor the transcript hold. On a review call the client says "pause it there" or "this shot has to come out", and which second of the cut "there" and "this shot" mean only exists on the shared player. The producer's note says "warehouse too orange" but not where; the transcript has the client's words but no cut timecode. Vivu finds the moment from the meaning of the note, and the frame at that moment shows the timecode. Comments on a review call sit close together and often return to the same shot, so every hit is read against the transcript before it becomes a row, and hits that belong to a neighboring comment, to praise or to scheduling are rejected and counted.

When to use

Use when a producer, project manager or editor at an agency says "match my notes from the client call to the timecodes", "turn yesterday's review call into a change list for the editor", "where in the cut did the client ask for the logo change?", or "build a revision list from these two review recordings". For one question about one call ("when did they mention the music?"), search Vivu directly. This skill does not judge the creative, rank versions, decide which comments to accept, or edit the cut; it finds where each comment was made and what the player showed.

Working principles

1. Report measured numbers, not estimates. When a number is an estimate, say so.
2. A note becomes a verified row only after the transcript shows the client saying it and a full frame shows the timecode. Vivu's results are candidates until then; rejected candidates are counted and listed in unmatched.csv.
3. Stop and tell the user when a required capability or file is missing (no transcript, no ffmpeg, no write access in Vivu). Do not guess around it.
4. Ask the user before anything that is expensive to redo or that acts on their behalf: the indexing cost before upload, and the sample rows before the full list.
5. Record what the client asked for. Never judge whether a comment is right, and never infer who is speaking from the voice.
6. Report the real count. When fewer comments are found than there are notes, the missing notes stay in unmatched.csv with a reason, never padded with a nearby comment.

What you need before starting

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

The skill needs a shell and local files, so it runs in Claude Code on the user's computer (terminal or the Code tab of Claude Desktop). It downloads nothing from YouTube, so no residential IP is needed. Nothing is scheduled and nothing is posted to another tool.

Inputs to collect

Ask for anything missing, most important first.

1. The producer's notes, one per line, in the order they were written. Required.
2. The folder with the review call recordings and their transcripts (CALLS_FOLDER). Required.
3. Which calls the notes came from. Default: every recording in CALLS_FOLDER for this project.
4. How the cut's timecode appears on the shared player: burned in timecode on the picture, the player's own time display, or both. Default: Claude reads both from the first frame it extracts and asks the user if neither is visible.
5. The Vivu project name. Default: "Review calls PROJECT", private, where PROJECT is the user's short name for the job (one client per project).

Files and state

Keep everything in one working folder next to the calls:

review-revisions/
  notes.json          notes: id, the note as written, the query
  calls.csv           call file, minutes, transcript file, Vivu video id
  results/            raw search results, one JSON file per note
  frames/             full frames of the screen share used for timecodes
  revision_list.csv   verified rows, one per client comment
  unmatched.csv       notes with no verified comment, and rejected candidates with the reason
  state.json          uploaded files and video ids, searches run with job ids, every hit with its verdict, rows written

state.json is updated after every step. A rerun reads it first: files already uploaded are not uploaded again, searches already run are not rerun, checked hits keep their verdicts, and a row already written is not written twice, so an interrupted run resumes where it stopped.

Step 1: Check the Vivu connector and the setup

Goal: every row of What you need is confirmed before anything is uploaded.

1. Call vivu_get_account. If the tool is missing, tell the user to add the Vivu connector in Claude (https://mcp.vivu.ai/mcp) and stop. If can_create_projects is not true, or a write call later fails with "has not granted vivu.write", ask the user to reconnect Vivu with write access and stop until they have.
2. Run ffmpeg -version and ffprobe -version. List CALLS_FOLDER and note which calls have a transcript file next to them.
3. Create the working folders; ffmpeg does not create an output folder:

mkdir -p review-revisions/results review-revisions/frames

Run every later command from inside review-revisions/ (cd review-revisions), with CALL_FILE as the path to the recording from there.

Done when vivu_get_account shows can_create_projects: true, ffmpeg and ffprobe print versions, and the working folders exist.

Step 2: Confirm consent and turn the notes into queries

Goal: notes.json with one query per note, and the user's confirmation that these calls may be used.

1. Ask the compliance questions in Compliance items 1 and 2 before anything else in this step. Leave out any call that fails them.
2. Expand each note into one plain sentence that names the thing to change and the change, and put it in this template:

NOTE_IN_PLAIN_WORDS is the note written out ("intro too long" becomes "the opening is too slow or too long and should be shortened"). Use the objects in the note (the shot, the music section, the end card, the captions); do not guess the client's exact words, since Vivu matches meaning and the reason text is not a transcript. Name the client as the one asking: the producer repeats and confirms comments on the same call. All searches are precise because the list needs time ranges; a fast search returns only whole files. maximum_results 5 is above the number of times a client usually raises one comment on one call, and it is also the ceiling on what comes back: a list that stops at exactly 5 may have been cut short, so raise it and rerun that note. 3. Show the notes and their queries, and wait for a yes.

In our test run the calls were made for the test, so the consent question was not exercised in our test run; the queries were written from the notes as above before any search ran.

Done when the user has confirmed consent and approved notes.json.

Step 3: Price the indexing and get approval

Goal: the user sees the cost before anything is uploaded.

1. Measure each call and sum the minutes:

ffprobe -v error -show_entries format=duration -of csv=p=0 CALL_FILE

2. Call vivu_get_usage for the plan and what remains this month.
3. Estimate search credits: one precise search per note, plus one rewording per note in case the first page is not clean. A precise search uses 5 credits in total. Label the total as an estimate.
4. Show one table and wait for approval:

For reference, the Free plan has 20 index minutes a month and 50 search credits a month; Premium is $30 a month with 180 index minutes and 500 search credits. Two 40 minute review calls fit Premium, not Free. If the calls do not fit, offer these levers in order: index only the stretch of each call where the cut was on screen (the meeting tool's chapters or the transcript show when the player was shared; cut that stretch out with ffmpeg -ss START -to END -i CALL_FILE -c copy PART_FILE, where START and END are the transcript times in seconds), split the work across months, and only then a larger plan. Never drop a call the user asked for without saying so.

Record START for each part in calls.csv. With -c copy the part begins at the keyframe at or before START, so measure the real offset with ffprobe -v error -show_entries format=start_time -of csv=p=0 PART_FILE and keep that too. Vivu's times for a part count from the start of the part, not the start of the call, and Step 5 needs both numbers to map them back.

In our test run the account was an admin account whose vivu_get_usage shows no remaining allowance, so the comparison against a real plan and the approval were not exercised in our test run.

Done when the user has approved the minutes and the credit estimate.

Step 4: Upload and index

Goal: every call is ready in a private Vivu project.

1. Call vivu_list_projects and reuse the project named in the inputs if it exists. Otherwise call vivu_create_project with that name and visibility "private". Client work in progress is confidential; the default visibility is the whole organization.
2. Call vivu_open_upload_page with the project ID right before the upload. The link expires in 180 seconds and is a sign in link, so never paste it into a message or file. Give it to the user to open in their own browser and choose the call recordings, or attach them with a browser tool that can upload local files. Claude in Chrome accepts at most 10 MB per upload call, and a 40 minute call recording is usually larger; the user adds those in the Vivu web app. Never split or recompress a recording to fit.
3. Poll vivu_list_videos about every 30 seconds until every file shows ready. Match each video back to calls.csv by file name; Vivu turns spaces and punctuation in names into "_", so compare names with those characters replaced. Record the video IDs in state.json.

In our test run the files went up through a script, not through a user's browser or Claude in Chrome; that upload path was not exercised in our test run.

Done when vivu_list_videos shows every call in calls.csv as ready.

Step 5: Search each note and check every hit

Goal: for each note, the client's comment with its call time and the cut's timecode, or a reason it was not found.

Run each note's query with vivu_search_videos (project_id, query, mode "precise", maximum_results 5). 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/NOTE_ID.json. Show the result page link in the live reply only; it expires after four hours, so it never goes into revision_list.csv or any other file.

Vivu returns a time range that contains the comment, not the exact sentence, and the reason text is a paraphrase, not a transcript. Check every hit:

1. Read the transcript lines inside the window (START is start_ms / 1000, END is end_ms / 1000). For a call indexed as a part, add the part's START (from calls.csv) to start_ms / 1000 and end_ms / 1000 before reading the transcript or extracting frames from CALL_FILE, and widen the transcript read by 5 seconds on each side, since the keyframe offset makes the mapped times approximate. The hit is real only if a line labeled as the client asks for the change in the note. Reject it when the only matching words are the producer's (a recap or "noted"), when the client is praising the shot rather than asking for a change, when the client is talking about scheduling, or when the client's line in the window is a different note. Review comments sit next to each other and clients come back to the same shot, so a window often holds the end of one comment and the start of the next; keep the line that matches the note. Write the verdict and reason in state.json.
2. When a call has no transcript, keep the hit as a candidate: read vivu_get_video_summary with include_segments, start_ms and end_ms around the window as a second signal, write the row with client_words NOT VERIFIED, and tell the user to listen to that stretch. Segments are chapter level and can join two comments into one.
3. For every real hit, read the timecode at the client's sentence, never at the start of the window. Windows start a few seconds before the client speaks, often while the player is still running or still paused on the previous comment's shot. SECONDS is the middle of the client's sentence in the transcript:

ffmpeg -v error -ss SECONDS -i CALL_FILE -frames:v 1 -q:v 3 frames/NOTE_ID_HIT_read.png

HIT is h plus the hit's number within the note (h1, h2, ...). Open the full frame and read the burned in timecode on the picture and the player's time display. Do not scale the frame down: when the client's view puts the screen share in a small tile, the timecode is only a few pixels tall. 4. Check that the player stayed paused while the client talked. Crop the timecode area and take one frame every 0.5 seconds across the sentence (S is the sentence start in seconds, D its length; X, Y, W, H are the pixel box around the timecode on the full frame from item 3, with some margin):

ffmpeg -v error -ss S -t D -i CALL_FILE -vf "fps=2,crop=W:H:X:Y,scale=iw*2:-2,tile=4x5" -frames:v 1 frames/NOTE_ID_HIT_hold.png

The sheet holds 20 cells, 10 seconds of speech. When D is over 10, run the command again with S increased by 10 and a new file name (frames/NOTE_ID_HIT_hold2.png), until the whole sentence is covered.

Keep the quotes around the filter. If every cell shows the same timecode, use it. If it changes, the client spoke while the cut was playing: write the timecode at the start of the client's sentence, mark the row timecode UNCERTAIN, and say so to the user. If no timecode is readable at all, leave cut_timecode empty, keep the call time and the frame path, and let the editor read the frame. 5. Rejected hits stay in results/ and go into unmatched.csv with the reason; they are counted, not dropped. A note with no real hit also goes into unmatched.csv. An empty result does not prove the client never said it: grep the transcript for the note's key word (for example grep -n -i "logo" TRANSCRIPT_FILE, where TRANSCRIPT_FILE is the call's .vtt or .srt), reword the query once in plainer terms, and tell the user.

These wordings ran in our test, written from the producer's notes before any search:

Why this chain: the note query finds where the client talked about that change, the transcript turns each window into the client's own words and rejects neighbors, and the frame flips from what was said to what the player showed at that moment, which is the one thing the editor needs and nobody wrote down. There is no separate screen search, because a timecode only matters once the comment is found and nothing on screen says what the comment is.

Worked example from our test run

In our test run we used 2 synthetic review call recordings, 3.9 minutes in total, made for the test: a meeting window with a shared review player showing a cut with burned in timecode, a synthetic voice for the producer and another for the client, and a transcript with Producer and Client labels. The first call reviewed a launch film with the share at full size; in the second the client's view was a gallery, so the share was a small tile and its timecode only a few pixels tall. The picture inside the player was abstract placeholder shots, so nothing on screen gave away what the client asked for. Before searching we wrote down every comment and the timecode the player held during it. Around the comments were traps: the client praising the shot just before the music comment, the client going back to the same warehouse shot right after asking for its color fix to praise the camera move, praise of the fast cuts, two scheduling exchanges, and the producer's acknowledgements. The client also came back to the intro comment near the end of the first call. From the upload to both calls ready took about 4 minutes, partly waiting behind other videos.

The 8 note queries, with the wordings in the table and no rewording, returned 9 moments: 9 real, 0 false and 0 missed. In our test run the 8 note searches come to 40 credits at 5 credits each, an estimate, on 3.9 minutes of calls; it is an estimate because the test account's vivu_get_usage shows no remaining allowance to measure against. The intro comment was found both times. The warehouse color comment and the cafe comment right after it each came back only for their own note, and none of the praise or scheduling stretches came back. Windows were 13 to 21 seconds, wider than the client's sentences, and several started while the player was still running or still showed the previous comment's shot. Read on the full frame at the client's sentence, the timecode was right on all 9 verified rows, 3 of them from the small share tile, and the hold sheets showed the player held still through every sentence.

The calls were short, clean and made for the test: turns never overlapped, the voices were clearly different synthetic voices, the timecode was high contrast, and the transcript was the script rather than a meeting tool export or speech to text output. Full length real calls, a client who talks while the cut plays, a producer who reads the notes back as a recap, crosstalk, and compressed screen shares were not part of the test, and those cases were not exercised in our test run.

Done when every hit of every note has a verdict in state.json and every real hit has a read frame and a hold sheet.

Step 6: Assemble the revision list and confirm the sample

Goal: one list the editor can work through in order.

1. Build one row per verified comment, in cut timecode order within each call. Narrow start and end to the client's sentences in the transcript, not the whole Vivu window:

note_id,note,meeting_file,start_mmss,end_mmss,client_words,quote_source,cut_timecode,player_time,timecode_source,frame_path,status,done
warehouse_color,Warehouse shot too orange,review_a.mp4,01:04,01:12,"Pause. This warehouse shot looks very orange next to everything else. Can your colorist cool it down so it matches the shots around it?",meeting transcript,01:00:44:09,0:44,burned in timecode on full frame; held for the whole sentence,frames/warehouse_color_h1_read.png,verified,

2. Field mapping:

3. Show two or three sample rows and the mapping and wait for a yes before writing the full list. Say which fields are inferred: none of the fields above is Claude's opinion, but which note a comment belongs to is Claude's reading of the transcript; if it is wrong, the editor changes the wrong shot, so tell the user to glance at client_words before handing the list over.
4. Write revision_list.csv and unmatched.csv, and give the user the counts: notes matched, comments per note, candidates rejected and why, notes with no match.

In our test run both files were built from the checked hits (9 rows for 8 notes, unmatched.csv empty); the user's approval of the sample rows was not exercised in our test run.

Done when revision_list.csv has one row per verified comment, unmatched.csv lists every note without one, and the user has approved the sample rows.

Compliance

1. Use only review calls that everyone on the call knew were recorded (the meeting tool's recording notice, or a contract that allows recording for production). Ask before Step 2 and leave out any call that does not meet this.
2. Client calls and unreleased cuts are confidential. Ask before Step 4 whether the agency's agreement with the client allows uploading them to a third party service. Use one private Vivu project per client; the default visibility is the whole organization. The recordings stay in the user's Vivu project until the user deletes them; the skill never calls vivu_delete_video or vivu_delete_project unless the user asks, and confirms first.
3. No face, voice or identity recognition. Vivu is not asked who is speaking; the speaker comes only from the meeting tool's transcript labels.
4. The list records what the client asked for. It never judges whether a comment is right, which version is better, or how the editor or the client performed.
5. Vivu finds moments; it does not edit the cut. The editor makes the changes.

Known failure modes