Wedding detail cutaway selects

---
name: wedding-detail-cutaway-selects
description: "Find the ring, bouquet, table, dress and venue cutaways in a wedding's detail camera cards with Vivu, check each in frames, and get a selects CSV. Use when cutting a wedding film's opening."
---

Wedding detail and venue cutaway selects with Vivu

This skill takes one wedding's footage from the detail camera or B camera (card folders with files named only by a counter, such as B001_C014.MP4) plus the day's timeline, and a short list of the cutaway kinds the editor wants: ring close-ups, the bouquet or table flowers, the reception tables, the dress or shoes, the venue from outside. Claude picks the getting ready and room setup stretches from the timeline, exports small 720p proxies of just those files, prices the job against the user's Vivu plan, indexes the proxies in a private Vivu project, runs one search per cutaway kind, checks every result in frames from the user's own file, and writes detail_selects.csv: kind, camera card, source file, start and end time trimmed to the shot, shot size and light read from frames, a frame, and an empty column where the editor marks what they use. The editor cuts the opening and transitions from the originals in their own editor.

The value is in what only the picture shows. Detail footage has no dialogue, the file names say only which card and which clip, and the timeline says "10:30 room ready" at best. Whether a clip holds the rings on their box or just a hand at a keyboard, a set reception table or an empty cafe table, the church front or the inside of the ballroom, is visible only in the footage. Vivu looks at the picture; Claude then looks at frames, because searches for small objects and broad scenes are the weakest kind of Vivu search, and nothing goes on the sheet as confirmed until a frame shows it.

When to use

Use when an editor says "pull the detail shots from Saturday's wedding", "find the ring and bouquet cutaways on the B cam cards", "where are the venue exteriors and the reception tables", or "build me a selects sheet of the getting ready details". It fits one wedding's detail camera files from the getting ready and setup stretches (tens of clips, 10 seconds to 2 minutes each).

Not for:

• Speeches, vows or toasts. Those are found by what is said, from the main camera's sound; search the Vivu project for what was said instead.
• The whole day from every camera. Index only the stretches the timeline points to (Step 2); the rest stays on the drive.
• Guests, children or the couple's faces. The skill looks for empty detail shots, never identifies anyone, and does not search for people.
• One quick question about one clip. Open it, or search the Vivu project directly.
• Editing. The skill finds and checks shots; the editor cuts.

Working principles

1. Report measured numbers, not estimates. When a number is an estimate, say so.
2. A search result is a candidate until Claude has looked at frames from the user's own file inside the result window. Only rows checked in frames are marked confirmed.
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: which files to export and the cost (before upload), and the cutaway kinds with their search wording (before searching).
5. Write each kind as something a frame shows: the object, what it rests on, how large it is in the frame, and what does not count. Searches for small objects and broad scenes can return look alikes (a hand with no ring, an empty cafe table, an indoor hall), so the frame decides.
6. The Vivu result page link expires after four hours, so it only appears in the live reply. detail_selects.csv refers to clips by the user's own file names and times.

What you need before starting

The skill runs in Claude Code on the computer that holds or mounts the wedding footage (a terminal or the Code tab of Claude Desktop), because it reads local files and runs ffmpeg. Nothing is downloaded from the internet, so no residential IP is needed. It runs once per wedding; nothing is scheduled and nothing is posted anywhere. Check each item at the start and tell the user plainly what is missing before doing anything else.

Inputs to collect

Ask for anything missing, most important first.

1. The wedding's card folders (required).
2. Whether the contract allows uploading this footage to a cloud service (required). If not, stop.
3. The cutaway kinds (default: rings, bouquet and flowers, reception tables, dress and shoes, venue exterior; the user may add one or two, such as invitations or the cake).
4. The timeline or run sheet. Default if missing: ask which cards and which hours hold getting ready and room setup.
5. Picks per kind. Default: up to 4, the best first.
6. The Vivu project name. Default: "Wedding details COUPLE_SHORTNAME DATE", private.

Files and state

Keep the working files in one folder outside the card folders:

wedding-details/
  config.json        card folders, stretches chosen, project_id, kinds and their search wording
  proxies/           720p proxies, named CARD_ORIGINALNAME.mp4
  proxies.csv        proxy, card, original_path, created_at, duration_s, uploaded_name, video_id
  results/           raw result of each kind's search without its result page link
  frames/            three frame strips, half second sheets and picked frames Claude checked
  candidates.csv     every returned window with its judgment and reason
  detail_selects.csv confirmed and uncertain picks (Step 7)
  state.json         proxies exported and uploaded with video_id, searches run with job_id, windows judged

A rerun reads state.json first and skips what is done: proxies already exported, already in the project, searches already run, windows already judged. Adding cards later exports and uploads only the new proxies; searches run again because a search covers the whole Vivu project, and judged windows keep their judgment.

Step 1: Check the Vivu connector and the setup

Goal: every row of What you need is present, or the user knows exactly what is missing.

1. Call vivu_get_account. If the Vivu tools are missing, tell the user to add the Vivu connector in Claude (https://mcp.vivu.ai/mcp) and stop. The account must show can_create_projects: true. If a later write call fails with "has not granted vivu.write", ask the user to reconnect Vivu and allow write access, then retry.
2. Run ffmpeg -version and ffprobe -version. Without them nothing can be exported or checked; stop and say so.
3. List one card folder and read the timeline. Ask the Compliance questions now, before anything is exported.

Done when vivu_get_account shows can_create_projects: true, ffmpeg and ffprobe answer, and the user has said the footage may be uploaded.

Step 2: Pick the detail stretches from the timeline

Goal: the detail camera files from getting ready and room setup, and nothing else.

1. From the timeline, note the times of getting ready (bride and groom), the ceremony site before guests arrive, and the reception room before doors open.
2. Read each file's creation time on the detail camera and B camera cards (CARD_FOLDER is one card folder):

for f in CARD_FOLDER/*.MP4; do printf '%s,' "$f"; ffprobe -v error -show_entries format_tags=creation_time -of csv=p=0 "$f"; done

Camera clocks drift; ask the user whether the camera was set to local time, and shift by the offset they give. 3. List the files that fall inside the stretches, per card, with the count and the reason, and ask the user to add or drop files. The main camera and drone cards stay out unless the user asks.

This step was not exercised in our test run (the test footage had no timeline or camera clock; Step 6 describes what was tested).

Done when the user has approved the list of files per card.

Step 3: Export proxies and size the job

Goal: 720p proxies of the approved files, measured and priced, with the user's approval.

1. Export each approved file to a 720p H.264 proxy without sound (FILE is the original, CARD the card folder name, NAME the original file name without extension). The picture is what these searches need; dropping sound makes files smaller and keeps background talk out of the project:

ffmpeg -v error -i "FILE" -vf "scale=-2:720" -c:v libx264 -crf 23 -preset veryfast -pix_fmt yuv420p -an "wedding-details/proxies/CARD_NAME.mp4"

Keep the original path in proxies.csv; detail_selects.csv points back to it. 2. Measure each proxy (PROXY is its path):

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

3. Sum to minutes. Searches: one precise search per kind, plus one rewording for a kind whose first results include a look alike. A precise search uses 5 credits in total, so as an estimate five kinds are 25 credits before rewordings; label the credit figure as an estimate.
4. Call vivu_get_usage for the plan and what remains. The plans: Free is $0 a month with 20 indexing minutes a month and 50 search credits a month; Premium is $30 a month with 180 indexing minutes a month and 500 search credits a month.
5. Show one table:

6. If it does not fit, offer these levers in order: drop files the timeline only loosely points to; drop clips the user knows are unusable (lens tests, black frames); move the second shooter's B camera to a later session; move to a larger plan. Name every file left out.

If vivu_get_usage returns no remaining figures (some admin or team accounts return null), show the needed minutes and credits anyway and ask the user to confirm the allowance.

Exporting proxies from camera originals was not exercised in our test run (the test files were already 720p web copies); measuring and pricing were.

Done when the user approves the proxy list and the cost table.

Step 4: Upload and index

Goal: every approved proxy is ready in one private Vivu project and matched to its row in proxies.csv.

1. Call vivu_list_projects. Reuse this wedding's project if one exists. Otherwise call vivu_create_project with the project name from the inputs and visibility "private"; the default is "organization", which every member of the Vivu workspace can see, and a couple's wedding should not be.
2. Call vivu_open_upload_page with the project_id right before the upload. The link expires in 180 seconds, so request it only when the user or the browser tool is ready, and never paste it into a file.
3. Give the link to the user to open in their own browser and select the proxies (the page takes many files at once), or open it with a browser tool that can attach local files. Claude in Chrome accepts at most 10 MB per upload call; larger proxies go through the user's browser or the Vivu web app. Never split, trim or recompress a file further to fit.
4. Poll vivu_list_videos about every 30 seconds until every proxy shows status ready. Files can sit as queued for minutes while the service indexes other work; that is not a failure. Vivu replaces spaces and brackets in file names with underscores; match each video back to proxies.csv by the normalized name and by duration_ms against duration_s, and write video_id into proxies.csv and state.json.

The upload through the user's own browser was not exercised in our test run; the test files reached Vivu through a different upload path.

Done when vivu_list_videos shows every proxy as ready and every row of proxies.csv has a video_id.

Step 5: Turn the cutaway kinds into search wording

Goal: one search per kind, in words that describe what a frame shows.

1. For each kind, write a query that names the object, what it rests on, how large it is in the frame, and what does not count. The rows below are the wordings we tested.
2. Show the user the kinds with their wording and wait for approval.

Rings and venue exteriors are the kinds the opening usually depends on and the hardest to search for: a ring is a small object, and "the venue" is a broad scene that an indoor hall also fits. Treat their results with the most care in Step 6.

All searches are precise: only precise returns a time range and a reason Claude can check; fast returns the whole file with an empty reason, so it is no use for picking a moment. maximum_results 20 leaves room for many takes of one detail across a wedding's cards; it is also the ceiling on how many candidates a kind can get, so raise it when a search returns exactly 20. There is no speech search in this chain: detail footage has no dialogue (the proxies carry no sound), and the timeline already supplies the only words about the day.

The chain: the timeline narrows the day to the getting ready and setup files; the kind search finds windows across those files; frames from the user's own file decide what goes on the sheet and where each shot starts and ends.

Done when the user has approved the kinds and their wording.

Step 6: Search each kind and check frames

Goal: for every kind, windows that Claude has judged from frames, with the real start and end of each shot.

1. Run each kind with vivu_search_videos (project_id, query, mode "precise", maximum_results 20). 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 the completed result as results/FIELD.json with its result_page_url field removed. Show the result page link in the live reply only; it expires after four hours.
2. For every result, extract a strip of three frames at the start, middle and end of the window (FILE is the proxy, START, MID and END are seconds inside the window, with END a few tenths of a second before the window's end so a frame exists there; FIELD and N name the output):

ffmpeg -v error -ss START -i "FILE" -ss MID -i "FILE" -ss END -i "FILE" -filter_complex "[0:v][1:v][2:v]hstack=inputs=3,scale=1500:-1" -frames:v 1 wedding-details/frames/FIELD_hN_strip.png

3. Judge the strip against the kind: rings large in the frame (not a bare hand); a building seen from outside (not a hall seen from inside); a table laid with plates, cutlery and napkins (not an empty cafe table or rows of glasses alone); the dress or the bride's shoes (not the groom's suit). Do not trust the reason text for what is in the shot. Write every window into candidates.csv as confirmed, rejected or UNCERTAIN with a few words on what the frames show.
4. Windows run past the shot into the neighboring shot of the same file, and one window can cover two shots of the same kind. For every confirmed window, make a half second sheet to find each cut and to pick the best frame:

ffmpeg -v error -ss START -t LENGTH -i "FILE" -vf "fps=2,scale=192:-2,tile=10x5" -frames:v 1 wedding-details/frames/FIELD_hN_sheet.png

LENGTH is the window length in seconds (at most 25, so 50 frames fit one sheet; make a second sheet for longer windows). Cell K (counting from 0, left to right, top to bottom) is at START plus K times 0.5 seconds. Where the picture changes to a different shot, that is a cut; a window that holds two shots of the kind becomes two rows. Save the picked frame of each shot at full size (PICK is the time in seconds Claude picked on the sheet):

ffmpeg -v error -ss PICK -i "FILE" -frames:v 1 -q:v 3 wedding-details/frames/FIELD_CARD_PICK.png

5. Write the shot size and light from the picked frame (for example "macro of rings on a box, warm candle light"). These are Claude's reading of one frame, not a measurement.
6. If a kind's results include a look alike, reword it once (Step 5) and run it again. An empty search, or a shot the user remembers that is not on the list, does not prove the footage has no such shot: tell the user and offer to check the files around the missing moment with a half second sheet.
7. Report to the user per kind: results returned, confirmed, rejected, uncertain.

Worked example from our test run

The test corpus was 5 camera card style files (2.68 minutes, no sound, named like A001_C001) joined from public Creative Commons stock clips by different shooters, so each file held several different shots with hard cuts, as a real card does. Truth was written from half second contact sheets before any Vivu call, with look alikes placed next to the targets: hands typing with no ring, empty sidewalk cafe tables, rows of empty wine glasses, an empty indoor ballroom, and a groom's suit on a hanger. A sixth search for a wedding cake was a control: there is no cake in the footage.

In our test run, with 0 rewordings:

• rings returned 3 results, 3 real, 0 false, 0 missed. Hands with no ring were not returned.
• venue_exterior returned 2 results, 2 real, 0 false, 1 missed: a low angle cathedral front at the end of a file never came back. One window held two exterior shots of the same file (a church, then a castle aerial) and became two rows on the sheet.
• bouquet_flowers returned 4 results, 4 real, 0 false, 0 missed.
• table_setting returned 2 results, 2 real, 0 false, 0 missed; the cafe tables and the rows of glasses were not returned.
• dress_shoes returned 4 results, 4 real, 0 false, 0 missed; the groom's suit was not returned.
• The cake control returned 0 results; nothing else was offered in its place.
• The run used 6 precise searches, an estimate of 30 credits. The five files were ready about 6 minutes after the upload began, most of it spent queued behind other indexing.

Every one of the 15 windows ran past its shot into the neighboring shot of the same file, and several started or ended on a look alike: twice on the one their own query excluded (hands with no ring at the end of a rings window, rows of glasses at the end of a table window), and elsewhere on the cafe tables or the empty ballroom. The half second sheets showed the real cut every time, so start and end in detail_selects.csv come from frames, not from the window.

This is one small, clean corpus of tripod and slider stock shots where each detail sits in its own shot. Handheld, shallow focus detail footage (a ring that drifts in and out of focus, a table half in frame) was not tested, and searches for small objects and broad scenes are rated weak in general and have missed shots on other footage. Keep the frame check, and treat a missing kind or a missing shot as "not found", not "not there".

Done when every kind has a results file, every window has a judgment in candidates.csv, and the user has seen the counts.

Step 7: Build the selects sheet

Goal: detail_selects.csv the editor can work through in their editor.

1. Write one row per confirmed or UNCERTAIN shot, kinds in the user's order, best first, at most the picks per kind the user asked for:

category,camera_card,source_file,original_path,start,end,shot_size,light,frame_path,status,use
rings,B001,B001_C014.mp4,ORIGINAL_PATH,00:21.5,00:32.0,macro of rings on a wooden box among roses,warm candle light,frames/rings_B001_27.png,confirmed,

ORIGINAL_PATH is the camera original from proxies.csv. start and end come from the half second sheet, not the raw window. status is confirmed when frames show the shot, UNCERTAIN when Claude could not tell (say why in candidates.csv). use is always left empty: only the editor decides what goes in the film. 2. Show the user the first rows and the field mapping, and wait for a yes before writing the rest:

3. When a kind has fewer confirmed shots than the user asked for, write the real number and say so; do not fill the list with rejected or unchecked windows.
4. Tell the user how to open a pick: the original path and time are enough in any editor; the Vivu result page link from Step 6 works for four hours and is not stored.

In our test run detail_selects.csv and candidates.csv were written from the checked windows; nothing was sent anywhere.

Done when detail_selects.csv and candidates.csv exist and the user has seen the counts of confirmed, rejected and uncertain windows per kind.

Compliance

1. The couple's footage. Before Step 3, ask whether the wedding contract allows uploading the footage to a cloud service. If it does not, stop; the skill has no offline path.
2. People on camera. The skill searches for empty detail shots, does no face recognition and names nobody. It does not look for guests or children. When a detail window shows a guest or a child, Claude notes it in candidates.csv and the editor decides; the skill cannot tell ages.
3. Where the videos go. Proxies are stored in the user's Vivu project until the user deletes them. Create the project as private; the default "organization" visibility shows it to every member of the workspace. The skill never calls vivu_delete_project or vivu_delete_video unless the user asks, and confirms first.
4. Nothing leaves the computer except the upload. The skill posts nothing and never writes into the card folders; proxies and sheets go into wedding-details/.

Known failure modes