A selects list that an editor can work from has one row per moment: the source file, a rough start and end, and a plain reason it was picked. Claude is good at building that table. It can only list what it can see, though, and on its own it sees file names and text. So the work splits: a tool that can look inside the footage returns time ranges, Claude turns them into rows, and the editor opens each range in the source to set the real in and out points.
What the editor needs in the list
Write the list for someone who wasn't in the conversation. Each row names the client project and the source file, gives the range as a place to start looking, and states the reason in words an editor can check by watching ("presenter names the second benefit", "price table fills the screen"). Keep rows in source order, since editors scrub forward. Add a status column so a row someone has checked against the footage looks different from one nobody has opened. Put the finished list in a shared doc or spreadsheet, since the editor shouldn't have to scroll past your prompts to find row eleven.
Four ways to put the footage in front of Claude
The simplest is to export stills or a transcript and attach them to the chat. There's no setup, and the list only covers what you exported, so the real picking happened before Claude saw anything.
A filesystem MCP server lets Claude list and read a folder directly. It will turn an existing shot log or a folder of transcripts into a clean selects table, but the video files are names and sizes to it, and what Claude can and can't see in a folder draws that line in more detail.
A self-built pipeline transcribes every file, stores the text with timestamps in a vector database, and gives Claude a search tool over it. Dialogue becomes searchable. Shots where nobody speaks stay invisible unless you index the picture too, which is a bigger system to run, and indexing picture and sound as separate streams is what that fuller version involves.
A hosted video search connector does the indexing as a service and lets Claude search over MCP. You pay with an upload step and a usage allowance, and a vendor holds copies of client footage, which some client contracts don't allow. These connectors find moments. The cut stays with the editor, and how far AI assistants get into the edit itself is a separate question.
Pull selects from one client's footage in a Claude chat
Vivu can be added to Claude as a custom connector, and since every search runs inside one project, give each client its own private project there. Ask by description and name the project: "in this client's launch project, find the first time the product appears on screen", or "find the moment a price or plan breakdown fills the screen". A precise search is a job you wait on, and it comes back as a short set of time ranges with a one-line reason each; when the moment is on-screen text, the reason paraphrases what the screen shows, so a wrong screen is easy to spot. You can preview each range on the results page and export the ones you keep as original clips, and because the results link expires after four hours, send the editor those clips along with Claude's table.
From there Claude writes the rows, and any price or spec taken from a reason stays marked unchecked until someone compares it with the footage, because a paraphrase can't go straight into a caption.
When this route is wrong for a client job
Skip it when a list has to span several clients in one pass, since a search never leaves its project, or when a client's contract keeps footage off outside services, since everything has to be uploaded to a Vivu project and indexed in the cloud first. Searches also draw on a plan allowance, with a free tier and a paid tier whose limits are on Vivu's MCP page, and the ranges they return are places to start, so exact in and out points stay the editor's call.
When you don't need any of this
If the editor shot the footage or logged it on the day, a list from Claude adds a step instead of removing one. Paste the log in and ask for the table, or skip the table entirely. The same goes for a job with one short source file, which the editor will have watched before any list arrives.
Deciding whether to build the handoff this way
The test is who picks and who cuts. When a strategist or producer chooses the moments and someone else edits, the list is the agreement between them, and building it from the footage itself is worth the setup. When one person does both, or the footage fits in a single viewing, a list is paperwork. Between those two, start from transcripts and add picture search only when the rows you keep needing are moments nobody says out loud.
FAQ
Can Claude cut the selects once it has the list?
Not in this workflow. Claude writes the list, the video search finds the moments and prepares the original segments, and the cutting happens in the editor's own software. Chat-driven editing tools are a separate category with their own setup.
How precise are the timecodes on a selects list built from search results?
Treat them as places to start. Video search tools return a span around the moment, and the editor sets the actual in and out points, usually with some handle on each side. A list that presents search results as exact timecodes will send the editor to the wrong frame sooner or later.
Should one selects list cover more than one client?
Keep one list per client. In a setup with one project per client, searches run a client at a time anyway, and a mixed list makes it easy to send one client's footage to a team working for another.
What belongs in the reason column of a selects list?
What happens in the moment, written so an editor can confirm it by watching. Write "second speaker holds the product up to camera" and skip labels like "good energy".
If the reason repeats on-screen text or a number, mark the row unchecked until someone compares it with the frame, because a search result's description of a screen is a paraphrase.