Why stills come first, everywhere

Every program in the field teaches image before motion. Not one reverses it.

The reason is money and time. A still is cheap and fast. A video generation is neither.

If you animate before the frame is right, you pay video prices to discover you had an image problem. Get the frame right, then move it.

Everything in this module produces frames you approve before a single second of video exists.

Say plainly what this does, and which half you automate

Claude Code does not generate images. It writes the prompts, drives the generator, files what comes back, and keeps the books. You keep whichever generator you already pay for.

Either way the prompt file and the bookkeeping are automated, the half that eats your evening, and the half nobody else in this market teaches at all.

The empty field from last module

Open story/shots.json. Every shot has a prompt field and it is empty. Fill it from the file you already have:

"For every shot in story/shots.json, write the prompt field from that shot's own description, character, location, time_of_day and camera. Append the style block from story/look.md to each one. Do not invent detail the shot list does not contain, where something is missing, leave a TODO in the prompt and list those shots for me."

That last sentence is the slide. A model told to write prompts will happily invent a coat colour. A model told to flag gaps hands you a list of the decisions you still owe.

Decide it once, in a file

story/look.md holds the look: film stock or lens language, palette, lighting, grain, the reference names you keep reaching for, and the things you never want to see.

"Here are six frames I like the look of. Write story/look.md as a reusable style block: what these have in common, in the language an image model responds to. Keep it under 80 words."

Because it is a file:

• Every prompt inherits it: no drift because you paraphrased it differently at shot 20
• Changing the look is one edit, then regenerate the affected shots
• A client can approve it before you have generated anything expensive

Twenty variants, off the file

The point of prompts living in a file is that they can be looped over.

"Take shots 1 through 12. Fire four variants of each: vary only the seed. Write everything to images/<shot_id>/v<n>.png, and log the exact prompt, model, seed and timestamp beside each one in images/log.jsonl."

48 images, filed and traceable, while you do something else.

Every frame traces back to the shot it serves and the prompt that made it. When shot 7 comes back wrong, you are one row away from knowing why.

Names that survive the project

v3_final_ACTUAL.png was the folder you cleaned up in Module 0. Do not build a new one.

Shot id in the path, version in the name, everything else in the log. The name only has to answer which shot, which attempt; the log answers everything else.

This is not tidiness. The video module reads these paths, and so does the edit. A name you have to interpret is a pipeline that stops needing a human at exactly the wrong moment.

It cannot see them. You can.

The limit from Module 1 arrives here, and it is the important one.

It cannot look at a frame and tell you the hands are wrong, or that the face went slightly plastic, or that this one is beautiful.

So it does everything around the looking:

"Build me a contact sheet of every variant, grouped by shot, with the shot description as the caption and the file path under each frame."

One page. You scroll it once. Judgment stays yours, but you are spending it on the frames instead of on file management.

Marking the keeper

You pick. Then tell it, and let the file carry the decision:

"Shot 7 take 2, shot 8 take 4, shot 9 take 1. Copy those to images/approved/, set status to approved on those rows in shots.json, and show me which shots still have nothing."

Now the file knows what is done. The video module reads approved. So does the progress count. So does the version of you who picks this up in three weeks.

What must not drift: characters and locations

story/bible.json was written in the last module. This is what it was for.

"For each character in story/bible.json, generate a reference set, front, three-quarter, profile, full length, from that entry's description only, and file it to references/<name>/. Then add the approved reference path back into the bible entry."

Locations get the same treatment. Establishing angle, the corner the scene actually plays in, the light at the time of day the script says.

Now every shot prompt can point at a reference instead of re-describing a person from memory, which is the actual mechanism behind the thing this market calls character consistency.

The exercise

Your own shot list from the last module. Twenty minutes.

1. "Write story/look.md from these references, under 80 words, reusable."
2. *"Fill every empty prompt in shots.json from the shot's own fields plus the look block.

Flag anything the shot list never specifies."*

1. Answer the flags. These are the decisions, and they take four minutes.
2. "Generate references for every character and location in bible.json."
3. "Fire four variants of shots 1–12. File to images/<shot_id>/, log prompt, model and seed."
4. "Contact sheet, grouped by shot, captions from the descriptions."
5. Pick your keepers. "Approve these, update status, tell me what is still outstanding."

Step 7 is the one to notice. You made every creative call and touched zero filenames.

What you should have now

• story/look.md: your look, decided once, inherited by every prompt
• shots.json with prompts filled and status moving: the file is now a progress board
• references/: characters and locations that will hold across every shot
• images/approved/: frames you have actually looked at and chosen
• images/log.jsonl: every generation traceable to the prompt, model and seed that made it

Not one second of video yet, and the expensive part is already de-risked.