The single file that solved the cold-start problem — and what goes in that file
A prompt addresses one task in one session. CLAUDE.md defines the project — the central claim, the vocabulary standard, the behavioral rules, and the file paths that carry forward automatically into every session that follows. This module examines the anatomy of an operating manual, how to build one from scratch, and what the Stellaris CLAUDE.md actually looks like as a working template.
What CLAUDE.md does — and what CLAUDE.md does not do
A prompt addresses one task in one session. CLAUDE.md defines the project across all sessions — the analytical architecture, the vocabulary standards, the behavioral expectations, and the file locations that carry forward automatically every time a new session opens. The file does not replace prompts. The file defines the ceiling that every prompt inherits.
Claude reads CLAUDE.md at the start of every Cowork session automatically. No instruction required. No reminder prompt. No copy-paste from a reference document. The operating manual loads, and the session begins inside a defined project rather than outside one. The project context the analyst spent weeks building does not disappear when the browser closes. The context lives in the file.
A research project running across weeks accumulates context — vocabulary decisions, analytical conclusions, file naming conventions, behavioral rules — that should carry forward from session to session. Without CLAUDE.md, that context disappears when the browser closes. Every new session re-explains the project from scratch. Two to three paragraphs of context load precede every prompt. CLAUDE.md moves the entire context load from the first prompt to a file Claude reads before the first prompt arrives.
The six sections
The Stellaris CLAUDE.md organizes into six sections. Each section addresses a different dimension of the working relationship between the analyst and Claude. Together the six sections answer one question: what does Claude need to know before the first prompt in order to produce work the analyst can use?
What happens without each section
Remove the central claim section, and Claude drifts. A session producing good output on a specific passage may advance an argument the next session contradicts — because no single file states what the project argues. The drift stays invisible until the report reaches thirty thousand words and the analyst reads the first chapter alongside the last.
Remove the vocabulary standard, and term definitions drift across sessions. "Compressed Spring" appears in one session meaning institutional pressure held against technical parity. The same term appears two months later meaning momentum from cost-curve descent. The Dictionary of Terms solves this only if CLAUDE.md points Claude to the Dictionary at the start of every session.
Remove the behavioral standards, and Claude produces accurate but incomplete output. A claim that needs a confidence level gets none. A gap in the argument goes unreported because nothing in the session instructions asked for gap-checking. Remove the file paths, and session time goes to explaining which document Claude should open rather than advancing analytical work.
The operating manual matters more than any individual prompt — because the operating manual defines the parameters that every prompt inherits. A strong prompt inside a weak project definition produces one strong output. A strong prompt inside a precise project definition produces strong output consistently, session after session. The file carries the ceiling. The prompts work within that ceiling.
What the Stellaris CLAUDE.md carried
The Stellaris operating manual grew from roughly four hundred words in January 2026 to approximately twelve hundred words by the April publication date. The growth reflected real session failures: a term used inconsistently across two sections, a behavioral standard too vague to apply, a file path that changed mid-project and broke three sessions before the fix. Each revision closed a gap the prior version left open.
Every revision addressed a specific failure. Nothing entered the operating manual as a precaution against problems the project hadn't encountered. The manual grew in response to real sessions — and that discipline kept the manual lean enough to load efficiently at the start of every session that followed.
Four questions that write the operating manual
A CLAUDE.md requires no technical expertise to build. The file requires one capability: knowing the project well enough to answer four questions precisely. The answers to those four questions supply everything the operating manual needs. Claude can draft the language from those answers. The answers themselves require the analyst's judgment.
What does the project claim? What terms carry specific meanings? How should Claude approach uncertain claims? Where are the files? Answer these four questions precisely, and the operating manual writes itself. Leave any one of them vague, and the sessions that follow will reveal the gap — at the cost of time and output quality.
Question 1 — What does the project claim?
Write the central claim in one or two sentences. The claim requires falsifiability — not "this project examines the relationship between X and Y" but "X causes Y under conditions Z." Test the claim by asking: what evidence would falsify the argument? If no evidence could falsify the claim, the statement describes a topic rather than an argument. Rewrite until the claim holds up as falsifiable.
The Stellaris central claim took three drafts before reaching its final form: five factor crossings inside the 2025 to 2032 window converge with the Fourth Turning Crisis climax, and the convergence — not either force alone — causes the transformation. That sentence excluded a range of alternative claims the project could have made and focused every subsequent session on the argument the report had to defend.
Question 2 — What terms carry specific meanings?
List every term the project uses technically — meanings distinct from everyday usage. Point Claude to the vocabulary document. State the rule: defined terms always appear in their defined form. No paraphrase. No casual usage in session output. The vocabulary section prevents the slow drift in term usage that degrades analytical consistency across long projects.
The Stellaris Dictionary of Terms reached one hundred and three entries by the publication phase. Not every project requires that scale. Any project with more than ten technically defined terms benefits from a vocabulary document — and from a CLAUDE.md section that points Claude to the document and states the governing rule at the start of every session.
Question 3 — How should Claude approach uncertain claims?
Specify the behavioral standards in imperative form — not "Claude should state confidence levels" but "State the confidence level on every empirical claim: high, moderate, or low. Follow the confidence statement with one sentence explaining the basis." Imperative form eliminates ambiguity about whether the standard applies to this session or all sessions. Every standard in the behavioral section applies permanently unless the operating manual marks an exception.
The Stellaris behavioral standards cover three categories: confidence levels on empirical claims, gap-flagging before section closure, and counterargument discipline on contested claims. A new project can adopt all three directly. The specific language of each standard requires calibration to the domain — a genealogical research project handles uncertainty differently than an infrastructure economics framework.
Question 4 — Where are the files?
List every document Claude may need: the primary report, the vocabulary document, the style sheet, the reader's guide, the archive folder. Use absolute file paths. A path that changes mid-project costs a session to fix — build the file structure before writing the paths into CLAUDE.md, and update the paths immediately when the structure changes.
Building the operating manual to document what the project has already done rather than to define what every session must do. A project history differs from an operating manual. CLAUDE.md defines behavioral standards and file paths. Documentation of past analytical decisions belongs in the report or in a separate reference file. An operating manual that records history instead of defining operating parameters adds overhead without adding value.
Five steps to build a CLAUDE.md from scratch
-
1Draft the central claim first — before anything elseTwo sentences maximum. Test the claim: what evidence would falsify this? If no evidence could falsify the claim, the project has a topic description, not a claim. The vocabulary document, behavioral standards, and file architecture all serve the central claim. Build the claim before building anything else.
-
2Reference the vocabulary document — or build the vocabulary document firstWrite the governing rule: defined terms appear in their defined form throughout the project. No paraphrase. No casual usage. Point Claude to the vocabulary file path. If no vocabulary document exists yet, building one before writing CLAUDE.md pays dividends in every session that follows. The vocabulary document eliminates the ambiguity that degrades analytical consistency across long projects.
-
3Write the behavioral standards in imperative formNot "Claude should state confidence levels" but "State the confidence level on every empirical claim." Imperative form removes ambiguity. The Stellaris behavioral standards cover confidence levels, gap-flagging, and counterargument discipline. Start with these three. Revise after the first ten sessions to reflect what the project actually requires — not what the analyst speculates the project might require.
-
4List every file path — for every document the project usesPrimary report. Vocabulary document. Style sheet. Archive folder. Name each file clearly. Build the file structure before writing the paths into CLAUDE.md. A path to a folder rather than a specific file works only if the folder contains one active document at all times — the one-live-file discipline from the version-control rules applies here directly.
-
5Write the session rules lastThe session rules address the specific habits that slow sessions down in this project — and those habits only become visible after the project runs for a few sessions. Start with the defaults from the template in Tab 3. Revise after the first five sessions to reflect what the project actually needs. Session rules that address real failures prevent recurrence. Session rules that address hypothetical failures add overhead without prevention.
When to update the operating manual
CLAUDE.md reflects the live state of the project. When the central claim sharpens, update the claim section. When a new document enters the project, add the file path. When a behavioral standard proves insufficient — a gap-checking rule that doesn't catch the kind of gap this project produces — revise the rule. The Stellaris operating manual changed twelve times between January and April 2026. Each change reflected a specific session failure the prior version hadn't prevented.
One discipline prevents operating-manual bloat: update the behavioral standards when a session failure reveals a gap. Add standards in response to experience, not in anticipation of problems the project hasn't encountered. The manual that grows through real failures stays lean. The manual that grows through precaution fills with rules no session ever triggers — and every inert rule adds overhead to every session that loads the file.
The length problem
A CLAUDE.md running twenty pages defeats its own purpose. The operating manual carries the context that prompts cannot carry efficiently. An operating manual so long that Claude spends the first prompt digesting the file rather than advancing the work has inverted the value. Keep the central claim to two sentences. Keep the behavioral standards to the ten rules governing the most common session tasks. Keep the file paths current — a path to a document that no longer exists adds load without value.
The Stellaris CLAUDE.md — structure
The Stellaris CLAUDE.md grew from an initial four-hundred-word draft to a twelve-hundred-word working document over four months of active development. The version below reflects the structure active during the April 2026 publication phase — the version that supported the final drafting and revision sessions that produced the two SSRN reports.
The full operating manual contains project-specific content — file paths, term references, source hierarchies — that applies to the Stellaris framework and not to other domains. The structure applies to any long-form analytical project. The sections and their logic carry over. The content within each section requires replacement with project-specific material.
The template below strips Stellaris-specific content and replaces each section with its structural label and a one-line description of what the section requires. The yellow-highlighted fields mark analyst-supplied content. Use the structure as a starting framework. Fill each section from the four questions in the Build Yours tab. Hand the completed draft to Claude and ask for language polish against the project's prose standard.
What the template does not carry
The template carries the structure. The structure defines the project's operating environment. The content within each section carries the project's analytical substance — and that substance requires the analyst's judgment, not Claude's drafting. The central claim section requires a claim the analyst has thought through and can defend. The vocabulary standard section requires a vocabulary document the analyst has built. The behavioral standards require decisions about what analytical discipline this project demands.
Claude can draft the operating manual's language from the analyst's answers to the four questions. Claude cannot supply the answers. The claim, the vocabulary, the behavioral standards, and the file architecture all require decisions only the analyst can make. The operating manual converts those decisions into a form Claude reads at the start of every session — permanently and automatically.
Once the four questions have answers, hand them to Claude with this prompt: "I have answered the four questions that structure a CLAUDE.md operating manual. Draft the full operating manual using the template structure from Module 2 of Practice. Build. Publish. Apply the Master Writing Style Sheet. Keep the central claim section to two sentences. Write every behavioral standard in imperative form. Deliver the full draft as a single document."
What Module 3 covers
The operating manual references the Master Writing Style Sheet throughout — but the CLAUDE.md does not contain the style sheet. The style sheet functions as a separate document that defines the prose standard: the specific rules that eliminate weak verb forms, passive constructions, vague pronouns, and structural habits that obscure analytical precision.
Module 3 examines the style sheet in full — what the Stellaris Master Writing Style Sheet contains, why each rule exists, and how to build a prose standard calibrated to a new research domain and a new target audience. The operating manual carries the project's analytical architecture. The style sheet carries the prose discipline that makes the analytical architecture readable. Module 3 documents how the style sheet builds and what the style sheet prevents.