The problem it solves

Every session, you found yourself re-explaining the same things.

• What the project is
• Where things live
• That you shoot 2.39:1
• That you never want it to touch the camera originals
• How you name files

You said it all in Module 0, then again the next day, then again.

The fix is a file called CLAUDE.md

It sits at the top of your project folder. It is read at the start of every session, automatically, without you attaching it or mentioning it.

my-film/
  CLAUDE.md        ← this
  story/
  images/
  video/

That is the entire mechanism. A plain text file, in your project, that becomes the standing brief.

A good one, in full

# The Apartment (short film)

A 90 second generative short. 2.39:1, anamorphic look, single practical
light sources, desaturated with crushed blacks.

## How I work
- Shot ids are permanent. Never renumber a shot.
- Never overwrite a take. New version, always.
- Camera originals in `_originals/` are read-only. Never touch them.
- If you do not have a value, write MISSING. Never estimate.

## Where things are
- `story/shots.json` is the source of truth for the film
- `bible/` holds characters, locations and the look
- Prompts are assembled from the bible, never typed by hand

That is about the right size. It fits on a screen.

Why short is not a style preference

Attention is finite, for you and for it.

Five rules each carry full weight. Two hundred rules each carry a fortieth. Adding a rule to a long file can make every rule in it less likely to be followed, including the one you just added.

Ask these in order, every time

1. Can a mechanism prevent it instead? A guard that refuses the command costs nothing per session and works better than an instruction asking nicely. Build the guard, write nothing. Bonus 6 is about this.

2. Is it just a fact? Then it belongs in a memory or a project file, not in the thing read on every task. Bonus 4.

3. Is it a procedure? Then it belongs in a skill, loaded only when relevant. Bonus 7.

4. Does it change behaviour on every single task? Only now does it go in CLAUDE.md, and something else comes out.

The rule that replaces, never joins

Give your file a size you will not exceed. When you want to add something and you are at the ceiling, you have to decide what was less important. That forced decision is the feature.

What a rule should look like

Specific, testable, and phrased as a thing to do rather than a virtue to have. A rule you could not check compliance with is not a rule, it is a mood.

Do not write it from scratch

You have evidence. Use it.

"Read this whole project and draft me a CLAUDE.md. Include only things that would be true on every task, phrased as specific instructions. Anything that is a one-off fact, list separately and do not put it in the file. Keep it under one screen."

Then cut it in half yourself. The first draft is always too long, and cutting it is where you find out what you actually believe.

Test it the only way that works

Start a fresh session and ask it to describe your project back to you.

"Without reading anything else, tell me what this project is, how I work, and what you must never do here."

If it cannot answer, your file is not doing its job. If it answers with things you did not write, you have found something you assumed rather than stated.

The one about folders inside folders

A CLAUDE.md can also sit in a subfolder, and it applies when work happens there.

Studio/
  CLAUDE.md            how I work, everywhere
  projects/
    the-apartment/
      CLAUDE.md        this film's look, cast, delivery spec

The general one holds your practice. The specific one holds this project. The specific one wins where they disagree, which is what you want: this film is 2.39:1 even though most of your work is 16:9.

What never goes in it

Also keep out: anything under NDA, client identifying details you would not put in an email, and anything you would be uncomfortable having read aloud.

Assume every word of it will be read by someone eventually, because that is how files work.

The maintenance nobody does

Once a month, or after any project:

"Read CLAUDE.md against what actually happened in this project. Which rules did we follow, which did we quietly ignore, and which caused a problem? Suggest deletions first, then additions."

Deletions first is not a stylistic choice. A rule that gets ignored teaches the whole file is optional, so removing it makes the remaining rules stronger.

The exercise

Twenty minutes, on a real project.

1. *"Draft a CLAUDE.md for this project. Only things true on every task. Under one screen. List

one-off facts separately."*

1. Read it. Cut half. Apply the four questions to every surviving line.
2. Decide your ceiling. One screen is a good one.
3. Fresh session: *"Without reading anything else, tell me what this project is and what you must

never do here."*

1. Fix whatever it got wrong or missed.
2. Add one line you know you need: "If you do not have a value, write MISSING. Never estimate."
3. If you work across several projects, make a general one above them too.

What you should have now

• A CLAUDE.md you could read aloud in fifteen seconds
• Every line in it specific enough to check compliance with
• A ceiling, and the rule that a new line replaces an old one
• Proof it works, from a fresh session that knew your project cold
• Nothing secret in it, and a monthly audit that starts with deletions

You stopped re-explaining your project, permanently.