Recovering From a Cold Start

Claude Rules Workflow

Chapter 9 · Recovering From a Cold Start

Chapter 1 introduced the idea that @rules/ replaced a manual recovery prompt with automatic inclusion, and left it there. This chapter goes one level deeper — what a "cold start" in this repository actually looks like, step by step, and what parts of reliability that automation genuinely buys versus what still depends on a human noticing something's gone stale.

What Actually Happens, In Order

The global CLAUDE.md loads — cross-project preferences (Chapter 2), regardless of which repository the session opens in.

This repository's own CLAUDE.md loads — its project description, its Key Paths table, and critically, its full @rules/ include list.

Every referenced rules file arrives — permanent_rules.md, language_rules.md, kanji_rules.md, and every other file on that list, delivered as real content, not just a promise to go read them later.

MEMORY.md's own index arrives too — the short, one-line-per-entry pointer list from Chapter 8, so relevant memory files can be recognized and read on demand as the conversation actually needs them.

Only then does the first real user message get processed — every rule and every memory pointer above is already present before a single word of the actual conversation begins.

Why This Is Structurally Different From R1

R1, from Chapter 1, was a prompt — a request that Claude go perform a read action, worded carefully enough to be self-sufficient even if the human pasting it had forgotten exactly what it did. The modern mechanism isn't a prompt at all; the rules content simply arrives, already-read, before the conversation has properly started. There's no step where something could be skipped, because there's no separate step to skip in the first place — it's part of how the session begins, not an instruction issued during it.

Aspect	R1 (manual, Chapter 1)	Cold start today
What's needed from a human	Remember to paste the recovery prompt	Nothing — happens automatically every session
When rules become available	Only after the prompt is sent and processed	Before the first real message is even handled
Failure mode	Forgotten prompt → zero rules in effect all session	A rules file simply not yet added to @rules/ (Chapter 1)

What This Automation Does NOT Guarantee

Everything arriving reliably isn't the same as everything arriving accurate. The mechanism faithfully delivers whatever the rules and memory files currently say — it has no way of independently checking whether what they say is still true.

Two real examples, already found in this exact course

Chapter 8's own finding — a feedback memory duplicating P1's banner rule, never retired once P1 became a formal rule — is exactly this kind of staleness: the memory arrives at cold start precisely as written, correctly, and is still slightly wrong to treat as an independent source once P1 already exists. Chapter 5's own finding — a kanji page's back-link rule pointing at a URL that no longer existed, broken sitewide until the 2026-08 rules review caught it — is the same shape one level down: the rule arrived faithfully every single session, describing behaviour that was, in fact, broken the whole time. Automatic delivery solved "did the rule arrive." It never claimed to solve "is the rule still correct."

A renamed path is invisible to this whole system

If a folder referenced by a rules file gets renamed on disk but the rule itself is never updated, cold start will keep delivering the old path every single session, with complete reliability — and complete inaccuracy. Nothing in the loading mechanism itself checks that a referenced path still resolves; that verification is still a human (or an agent doing the verifying) job, the same discipline behind every "check this actually still exists" moment across this whole course.

A Genuine Nuance: Not Everything Loads Upfront

Cold start delivers every @rules/-included file in full, but only MEMORY.md's own short index for memory — not the full content of every individual memory file. A memory file gets actually read only once something in the conversation makes it look relevant, exactly the "access when relevant" behaviour Chapter 8 described. This is a deliberate difference in scale between the two systems, not an oversight: the rules set is small and universal enough to load in full every time; the memory set can grow much larger over a long relationship with a project, and loading every memory file's full content on every single cold start would be wasteful for information that's mostly not relevant to any one given conversation.

Coding Challenges

Challenge 1

Explain why "the rules arrived automatically" and "the rules are correct" are two different claims, using one concrete example from earlier in this course to illustrate the gap between them.

📄 View solution

Challenge 2

A brand-new session opens in a completely unrelated repository that has never had a CLAUDE.md file of its own. Based on this chapter's own five-step flow, which of those five steps would still happen, and which would not?

📄 View solution

Challenge 3

Explain why MEMORY.md loads its full index at cold start while individual memory files don't — what specific tradeoff does this design avoid?

📄 View solution

Chapter 9 Quick Reference

Cold-start order: global CLAUDE.md → project CLAUDE.md → every @rules/ file in full → MEMORY.md's own index → then the first real message
Unlike R1, this isn't a prompt to remember — it happens automatically, before the conversation properly starts
Automatic delivery guarantees the rules ARRIVE reliably — it does NOT guarantee they're still ACCURATE
Two real, already-found examples of that gap: the duplicated header-comment memory (Chapter 8) and the broken kanji back-link (Chapter 5)
A renamed path or stale fact is delivered faithfully, every session, until a human actually checks it
Rules files load in full; memory loads as a short index, with individual files read only when actually relevant — a deliberate scale tradeoff
Next chapter: the capstone — designing and wiring in a brand-new rule category from scratch