Why build one when you have one

The installer gave you a working studio in a minute, and it was the right way to start.

But you cannot fix what you have never assembled. Something will break in eight months, and the difference between an afternoon and a week is whether you know what the pieces are.

The shape

Studio/
  CLAUDE.md              how you work, everywhere
  _bible/                looks and characters that recur
  _presets/              prompt fragments that reliably work
  NAMING.md
  memory/                MEMORY.md plus one file per fact
  .claude/
    settings.json        posture and permissions
    hooks/               the reflexes
    skills/              the procedures
    agents/              the crew
  projects/
    the-apartment/
      CLAUDE.md          this film's look and spec
      story/ bible/ images/ video/ audio/ edit/ deliverables/

Read it top to bottom. Every line is a deck from this session.

1. The folder, and version history

mkdir ~/Studio && cd ~/Studio
git init

Version history first, before anything exists. It is the safety net every other decision assumes, and it is worthless applied retroactively to the file you just lost.

2. The brief

CLAUDE.md, at the top. From Bonus 2, and remember the discipline:

• Only what is true on every task
• Specific enough to check compliance with
• One screen, with a ceiling you will not exceed
• Includes "if you do not have a value, write MISSING"

3. The rules

.claude/settings.json. From Bonus 3:

• Balanced. Reading and writing free, inside the folder
• Outbound, destructive and spending in ask
• Your irreplaceable folder in deny

"Set me up on balanced, deny anything touching _originals, and show me in plain English what that means you will and will not do."

4. The reflexes

.claude/hooks/. From Bonus 6. Three, not fifteen:

• The delete guard
• The secret guard
• The originals guard

Then break each one on purpose and watch it refuse. A guard you have not seen fire is not installed, whatever the config says.

5. The memory

memory/. From Bonus 4:

• An index of hard rules and topic pointers only
• One file per fact, each with a why and a how to apply
• The monthly decay audit in your calendar

Seed it with the three most expensive things you learned this year.

6. The procedures and the crew

.claude/skills/ and .claude/agents/. From Bonus 7 and 5:

• The procedure you do constantly
• The procedure you do twice a year and always half-remember
• One agent that reads and reports and cannot write

7. The schedule

From Bonus 9:

• A weekly review that always writes a file, even when there is nothing
• Backup, and a verified restore
• The decay audit
• A line stating what you actually made this week

Do not trust a studio you have not tested

Build it, then attack it, in this order:

1. Fresh session: "what is this studio, how do I work, what must you never do here?"
2. Try to delete something. Watch the guard refuse.
3. Try to write a fake credential to a file. Watch it refuse.
4. Try to touch your originals folder. Watch it refuse.
5. Ask it something you saved as a memory. Confirm it finds it.
6. Run the weekly review by hand. Read the output.
7. Restore your backup to a scratch folder and verify against the manifest.

Write down what it is

One page, in the studio, for the version of you in eight months:

"Write README.md for this studio: what each folder is for, what each guard blocks, what runs on a schedule and where its output goes, and how to turn each thing off."

"How to turn each thing off" is the half people leave out, and it is the half you need on the day something misbehaves.

The one rule that keeps it healthy

Building this is more fun than making films. Watch for the week where you improved the studio and shipped nothing, and let the weekly report tell you, because it will not feel like a wasted week from inside it.

Change it only from evidence

"This would probably be better" is how a system fills with instructions nobody follows. When a rule and a real outcome disagree, the outcome wins, every time, without discussion.

It should need less attention over time

A system that is working gets quieter.

If yours needs more fiddling each month, something is wrong with the design, not with your discipline. Fewer rules, better guards, and a shorter brief is almost always the direction of the fix.

What you can now do

• Rebuild this on a new machine in an afternoon
• Repair it when it breaks, because you know what the pieces are
• Explain it to someone else
• Change it deliberately, from evidence, instead of hopefully

You did not learn a tool. You built a studio, and it is yours.

The exercise

One sitting. Two hours. Do it beside your existing studio, not on top of it.

1. mkdir ~/Studio-v2 && cd ~/Studio-v2 && git init, and a .gitignore that excludes media.
2. Write CLAUDE.md. One screen. Include the MISSING rule.
3. Set the posture. Deny your irreplaceable folder.
4. Install three guards. Break all three on purpose.
5. Seed the memory with your three most expensive lessons, plus an index of rules and pointers.
6. Write your two procedures and one read-only agent.
7. Schedule the weekly review. Confirm the first output file exists.
8. Run the seven proof steps. Fix whatever fails.
9. Write the README, including how to turn everything off.
10. Move one real project in and work in it for a week before you retire the old one.

What you should have now

• A studio you assembled, piece by piece, understanding each one
• Three guards you have personally watched refuse
• A memory, a schedule, procedures, and a crew that reads and reports
• A README that says how to turn every part of it off
• The ability to rebuild the whole thing on a borrowed laptop

Nothing in your system is now a black box, including the parts somebody else installed.