For the past six months I ran a git repository as a one-person film studio. The crew was Claude, working inside Claude Code. The output is a 10-episode series, all released. This article is about the setup: what worked, what had to be invented, and where the human refuses to leave the loop.
CLAUDE.md is a job description, not a prompt
Claude Code reads a file called CLAUDE.md at every session start. Most projects use it for build commands and style notes. Mine opens with a paragraph that says who Claude is:
You are the Senior Creative Technologist & Pipeline Architect. You operate as a Hybrid Director — switching between these roles as needed: Narrative Architect, Music Director, Visual Consistency Guardian, Technical Director, Pipeline Automator.
That sounds like theater until you watch what it does in practice: it gives every session a stable frame of judgment. The same file carries the non-negotiables. Read the universe canon before any creative decision. Every visual prompt ends with a mandatory style suffix. The character never retaliates; he turns inward. The model starts every session already knowing the aesthetic constitution it operates under.
The last line of the file is a question: "Would Fibula approve this?" Ask before every delivery. That is the cheapest quality gate I have ever deployed.
Ten skills are the production crew
The pipeline's stages live in ten SKILL.md files. Declarative runbooks, one per stage: musical metadata, dramaturgy, visual prompts, motion script, episode scaffolding, naming enforcement, YouTube packaging, social atomizing, launch orchestration, editing prep.
A skill is not code. It is a contract in Markdown, and each one answers four questions before a single line of output is written:
- Trigger. The exact phrase that starts the stage: "Create dramaturgy for EP05".
- Mandatory inputs. The files that must be read, in order, before generating anything. No improvising from memory.
- STOP conditions. When the crew must halt and ask the human. The dramaturgy skill ends its input list with: "If any of inputs 1-4 are missing: STOP. Inform the human. Do not proceed with partial inputs."
- A post-generation checklist. The self-review before the stage is declared done.
Because every stage is pinned to a written runbook, the pipeline is deterministic in shape: the same trigger produces the same structure of output, anchored to the same sources, halted by the same gates. A reviewer never wonders how a deliverable was made. The SKILL.md is the method, version-controlled next to the result.
The chain rule that holds it together: Output of Step N = Input of Step N+1. Music analysis feeds dramaturgy; dramaturgy feeds visual prompts; approved images feed the motion script; the motion script feeds video generation. Every artifact is traceable to its upstream.
The part I write by hand
One document in that chain has no skill behind it, and it is where the directing actually happens. Before the dramaturgy stage runs, I write the concept notes: the mood, the through-lines to protect, and the must-have shots.
A must-have is not a bullet in a shot list. Mine carry five things: the exact moment in the timeline the shot lands on, the staging, the symbolic logic, a camera or blocking constraint, and a production note where the medium needs one. From episode 7's concept notes, verbatim:
Robotiko on a bench at twilight, looking out over the water as stars emerge. "I calculated the orbits of a billion stars" lands beneath those very stars — he who mapped the infinite, now diminished. At exactly "But now…" he stands, hands sinking into empty pockets, head down, and walks — shown from the front / three-quarter (NOT from behind), so the bowed head, the empty pockets, and the slumped defeat read on him. Split into two clips (seated hold → the rise-and-walk) to avoid multi-action morph failure; the camera dollies out ahead of him so the retreat is felt while we still see his face.
Everything in this pipeline is downstream of paragraphs like that. The dramaturgy skill treats them as a contract: it flags every must-have, builds the surrounding scenes to support them, and marks each one User Override: YES in the scene table; its checklist refuses to pass until every override is included. Write two words into that file and the machine will faithfully amplify two words into a generic film. The quality of the whole episode is decided here, by hand, before any generation starts.
The lessons file is the self-correction loop
The most underrated file in the repo is _memory/lessons.md: currently 144 dated rules, each earned from a real failure, re-read by Claude at every session start.
The canonical example: early on, prompts described the android's eyes as "glowing amber." Image generators rendered literal glowing eyeballs. Flashlight eyes, horror-movie stuff. The correction that survived testing describes the material instead: "dark amber glass lenses set into chrome sockets, like polished gemstones." That rule has a date and the case that produced it, and no prompt has said "glowing" about eyes since.
Rules can also die honestly. When a better formulation replaces an old rule, the old one is stamped [SUPERSEDED date — see successor] rather than deleted. The file preserves how the thinking moved, and a deleted rule teaches nothing. One anti-spawn phrasing ("only ONE chrome android, no second robot") turned out to make some generators latch onto the word "robot" and spawn exactly what it forbade; its replacement is tool-aware, and both versions sit in the file, in order, as the audit trail.
Rules that keep mattering climb further: into validators, then frozen test fixtures, then CI gates that block a merge. The repo documents that ladder. It is a separate article in this series.
Three gates stay human, cryptographically
For all the automation, the pipeline has three mandatory human checkpoints: after dramaturgy, after reference authoring, and after the motion script. Claude cannot proceed past them. Ever.
Each approval is recorded as data: episode, gate, artifact path, a sha256 of the approved file, date. If an approved artifact is edited afterward, the hash no longer matches and the drift is visible. The ledger turns "a human said yes" into something the test suite can verify: an artifact that moved beyond a gate with no approval record is a build failure.
Why so strict? Because taste does not automate. No function decides whether a scene serves the story, whether a camera move is earned, whether an episode's tone honors the arc. The entire point of automating everything else is to concentrate the human's finite attention on exactly those calls.
What I'd tell you to steal
Not the film pipeline. Your domain is probably different. Steal the shape:
- Give the model a standing role, not per-session instructions. Identity plus constitution beats a longer prompt.
- Write each recurring stage as a runbook with trigger, mandatory inputs, STOP conditions, and a self-review checklist.
- Keep the creative kernel yours and write it by hand. The machine amplifies whatever you put in it, including emptiness.
- Turn every correction into a dated rule the model re-reads at session start, and retire rules honestly when they're superseded.
- Decide which decisions are yours forever, gate them explicitly, and record approvals as verifiable data, not as a feeling that you probably looked at it.
The result is not a machine that replaces you. It is amplification with your vision intact, which was the deal all along.
The whole setup (CLAUDE.md, the ten skills, the lessons file, the approval ledger, and the series they produced) is open source, method MIT: github.com/fibuladev/robotiko-v2. Start with docs/skills-guide.md. The setup was also recorded in action, stage by stage, as a build-along video series on the channel. The films: youtube.com/@fibuladev.
Claude drafted this article. I directed it, checked every claim against the repo, and edited it.
