reelkit

I wanted short reels about records from my collection, built from iPhone clips of the record playing, photos of the sleeve and the record's own audio. I started by asking an AI to edit one reel by conversation.

It was slow in two ways. Every change meant a full render before I could see it, and the render ran in the cloud on two CPU cores: about 20 minutes for a 60-second reel at first. Deciding was slow too, because I could only judge a change once that render had finished. Facts on screen, such as recording dates and who played, were also easy to get wrong and hard to check afterwards.

1. Intake. Code probes the clips and photos and makes contact sheets. It also measures tempo, loudness and the sleeve's palette.
2. Audio bed on the beat. The record's audio is mixed into one bed, and the cuts are placed on its beat.
3. Shot list. Code proposes a first edit with a card for each track coloured from the sleeve, crops and a colour grade. Claude Code then reads the footage, researches the record and writes the on-screen text. Every factual line carries a quote and a source.
4. Storyboard and automatic checks. Each shot is rendered as its real frame and checked. I give feedback by shot number.
5. Lock. The board is fingerprinted. The master render refuses to start if the project, audio, series style or any source file has changed since.
6. Render. One render, in parallel segments.
7. Verify. The master has to match its specifications and the locked board, or it isn't delivered.

Automatic checks

Nine checks run on every board:

• text inside Instagram's safe area;
• text fit;
• contrast of at least 3:1, measured against the actual pixels behind the letters;
• reading time;
• matching type sizes;
• every fact sourced;
• blown highlights;
• near-duplicate shots;
• how much each crop enlarges its source.

Every text overlay is either tagged with a fact ID, which needs a quote and a link, or marked as plain copy. The checks fail anything in between.

These four frames are from the episode 003 board. They are what I approve, and the master is checked against them.

Design choices

• The storyboard is the real render. What I approve is what gets delivered, and the final check confirms it.
• No render without a lock. One code path builds every frame, so the board, the preview and the master cannot drift apart.
• Quality kept where it shows. The source frame rate is kept, because converting 24 fps to 30 makes a spinning record judder.
• Personal media stays out of git. iPhone photos carry GPS and the audio comes from commercial records, so clips, photos, audio and renders are not in the repository.

The render got faster because the master is cut into about two segments per CPU core. Each worker composes its own frames and sends them to its own encoder on the Mac's hardware media engine, and the segments are joined without re-encoding. On a cloud machine with 2 cores the same render took 7 to 8 minutes, so it needs the Mac.

Verification checks the master against its specifications (1080×1920, 24 fps, BT.709) and for loudness, and compares one frame per shot with the locked board. The target is −14 LUFS and the check accepts −15 to −12. Episode 001 measured −13.2 LUFS and episode 003 measured −14.2 LUFS. Every check in both saved reports passed.

The code was also reviewed independently. OpenAI's Codex read the pipeline and reported 11 findings ranked by severity, each with a failure scenario. For example, a HEIC conversion could overwrite a photo and a render could start without approval. The lead agent checked them against the code and split the fixes into tasks, each owning its own files with acceptance criteria. Codex then re-checked every fix. It marked some as only partly resolved and raised four new findings, which went into a follow-up task.

What the agents worked with while building and running the pipeline.