The terminal-first post workflow, where the timeline exists before you open the app

Opening an editing application to a folder of unsorted clips means doing several hours of clerical work inside an interface designed for creative decisions. Importing, renaming, binning, checking, syncing, laying a rough assembly — all of it clicked, one item at a time.

Every step is deterministic. Given the files and a set of rules, the outcome is fixed, which makes it exactly the wrong kind of work to do by hand.

The alternative is to do all of it from a terminal before the application opens, so the first thing you see is a project already organised and a timeline already roughed in. What remains is the part that needed you.

Copy from the card into a fixed structure, renaming as you go so filenames carry information rather than camera counters.

project/
  01_footage/  A001_20260904_0001.mov
  02_audio/
  03_proxies/
  04_exports/

Verify the copy against the source before deleting anything from the card. A checksum comparison takes a minute and is the only thing standing between you and a very bad afternoon.

Do the rename at ingest, not later. Once clips are referenced by a project, renaming them is a relink problem rather than a file operation.

Every clip carries metadata that answers most organisational questions. Read it into a table and you have a shot log before anyone has watched anything.

ffprobe -v quiet -print_format json -show_format \
        -show_streams clip.mov

From that you can group by camera, by day, by resolution; find the clips that are the wrong frame rate; spot the take that is three seconds long and was clearly an accident.

Add scene detection on top and you have shot boundaries as well. That is enough structure to build bins automatically, before any human judgement is applied.

Extract a frame at each detected shot change and pass it to a local vision model with a structured prompt asking for framing, subject, location and whether the shot is usable.

The result is a searchable log: every exterior wide, every close-up, every marginal take, findable without scrubbing.

Keep the field list short and the vocabulary constrained, so the answers are consistent enough to filter on. A log where the same shot type is described three different ways cannot be searched, which defeats the purpose.

Most editing applications expose a scripting interface that can create a project, import media, build a bin structure and lay clips on a timeline. It is usually poorly documented and entirely capable of this.

Driven from the log, it can create bins by scene or by camera, place markers at detected shot changes, and assemble the usable takes in order as a starting timeline.

That timeline is not an edit. It is the state you would have reached after several hours of clicking, and reaching it in a script run is the entire point.

Choosing a take, finding the rhythm, deciding what the sequence is about — none of this benefits from automation, and attempts to push further produce assemblies you spend longer undoing than building.

The right stopping point is a fully organised project with a rough assembly of usable material. From there the editor works normally, with the difference that the afternoon of preparation already happened.

Build the pipeline to that line and no further. The value is entirely in removing the clerical work, not in replacing the judgement.