Directing several sessions

When to use

When a video is too big for one session: one session per section, and one director over them. The director makes nothing itself. Its job is to catch what the sessions miss, keep them working, and pass on the creator's notes exactly.

The director's role

• Builds nothing in the other sessions' files. Each section's own doc stays that section's source of truth.
• Briefs and reviews every session against the creator's notes, and sends each one specific, verified advice.
• Owns the GPU queue's order (rendering) and the schedule: each session's own promised times, chased when they slip.
• Writes for the creator at the top of its log: what to watch, what to decide, what's done.
• The creator's notes always outrank the director's.

Day zero

1. The director's log, in this order:
   • a header: who directs, from when, and the role;
   • a FOR THE CREATOR block at the very top (to watch / to decide / done), rewritten every morning and at every handoff;
   • a STATE block ("read this first on resume"), rewritten at every phase change;
   • the creator's words, verbatim, with when they said them;
   • the bar: the approved part of the film written as a checklist;
   • the GPU protocol and the plan table (milestones, plus each session's own promised times);
   • the advice log, newest last.
2. One brief per session: its scope, the creator's words that concern it (verbatim, oldest first), and routing facts (files, frame ranges, the queue command with the session's name filled in). Nothing else: no paraphrase, and no step list of your own.
3. A recurring tick: Claude Code's /loop or a scheduled task. Every 30 minutes by day worked; every 15 minutes on an overnight run. The prompt is in tick-prompt.md. Change it at every phase change.
4. A checked save for shared code. Every change to code more than one session renders lands as one save: typecheck, import every module the film bundles, build the real bundle, and revert everything if any step fails. Never a multi-file change file by file: half-saved changes broke every session's renders five times in two days. A tool that does work when it's imported (bakes assets, writes data, launches a browser) goes in by a plain copy after the save, never through the import check.

Relaying the creator's notes (the rule that matters most)

• A relay is their exact words plus routing facts (owner, frames, files). No summary, no interpretation, no numbers or checks they didn't give, no "this means".
• When a note is unclear, or two notes conflict, ask them in one line rather than choosing.
• Review against their sentences, not against your own derived spec. On Everybody's Got A Home, the director's paraphrased step lists were what the sessions built and what the reviews passed, and the same shots kept coming back wrong. Sending their words on top of the list didn't help: the list won.
• Read a note as one thought: in "my only issue is X" followed by another sentence, the second sentence is the fix for X.
• "At least X" is their floor, not the target. Never offer an option weaker than what they asked for.
• "Have one be X" adds or swaps; it never deletes what they didn't name.
• Never write your own summary where it can be read as their note.

The note checklist

• Each section keeps a table: their note (verbatim) → the frame that shows it met → the render it was checked on.
• A shot isn't approved until each of their notes is shown met on a named frame.
• A check is only good for the version it was made on. Any change to the shot (camera, staging, set, timing) unchecks every row, and every row is checked again on the new render before it goes to them.

Before they see it

• Every new render: watch it at speed with the song, then step 8+ consecutive frames across every fast move, and run the render checks (blank, flicker, cuts, jitter, clipping). Compare it with the previous draft they saw, and re-read their earlier notes on that section first.
• Review never holds a draft back. Every draft goes on the review page the moment it renders, known issues on top (review-page). The review adds notes; it doesn't gate.
• Only their notes are to-dos. A flaw a session finds on approved work goes to the director as a list, never as a fix. Near the end, write a scope lock: exactly what may still change.
• Before a master, sweep the whole film on today's code against the cut. A code change can silently break an approved shot nobody re-rendered.

Running the team

• Workers are full sessions, one per section, each with its own context. Keep at most three working at once besides the director, as a queue: more sessions burned usage and crowded the GPU.
• A new task gets a fresh session briefed with the creator's exact words. Stand finished sessions down with their state written.
• One consolidated message per session per tick: the creator's notes verbatim, with routing facts (frames, song times, files). Below them, clearly marked as the director's, only verified technical findings: a flicker at a frame, a word that lands late, a blank frame. Never a creative reading of the notes. Don't repeat advice already given, and don't message a session when there's nothing new.
• How sessions talk: each worker is its own Claude Code session in its own terminal tab. The channel's director listed and messaged the other local sessions through Claude Code itself. Where your setup can't do that, give each session an inbox file it reads at the start of every turn, and a STATE file it keeps current.
• Ask for times, not effort. "Stills to me first, then save" must be written out in full. Hold promised times; on a slip of 30 minutes or more, ask for a new true time and the scope order, never a quality cut.
• Stills before saves to shared code, and one render on the GPU at a time.

Overnight runs

• A 15-minute tick. Never wait on the creator: anything waiting on their answer gets a noted default, and the session moves on to improving what's already agreed.
• Review and splice every render as it lands, so the morning cut is current.
• Write a handoff before they wake: what changed in each section, what's waiting for them.
• Keep the machine awake (caffeinate on macOS). A sleeping laptop pauses everything.

Failure modes

• Paraphrasing the creator into briefs and checklists, then reviewing against them.
• Approving from contact sheets. Quick 3–8-frame sheets passed a stopped object and a snap.
• Letting a check outlive the change that made it stale.
• Pausing the team on an estimate of usage that turned out stale. Read the real meter.

Safety

• Never kill a process you didn't start. Report stale browsers and ask.
• Never delete without the creator's OK on the exact list.
• Run date before writing any time down.