Capstone: Designing a New Rule Category From Scratch
Claude Rules Workflow
Chapter 10 · Capstone: Designing a New Rule Category From Scratch
Every earlier chapter examined an existing piece of this system. This capstone builds a brand-new one, start to finish — using a scenario Chapter 1's own third exercise already planted: a hypothetical video_lesson_rules.md that's never actually been written. Time to write it for real, and wire it in correctly.
Ch 1
Memory vs. rules test
Ch 2
Global vs. project scope
Ch 5
Why a dedicated file, not a shared template
Ch 7
Tracking-file bookkeeping
Ch 9
The one wiring step that's easy to skip
The Scenario
Suppose short video-lesson scripts start getting requested regularly — a scene-by-scene breakdown with on-screen text cues, voiceover lines, and timing notes, meant to feed into the existing Video Generation for Code Tutorials course's own production workflow. The same formatting instructions keep having to be repeated by hand on every request. That repetition is the actual signal worth noticing.
1
Apply Chapter 1's own memory-vs-rules test. Is this a fact specific to one conversation, or a convention meant to apply identically to every future video-script request? Every future request needs the identical scene/cue/voiceover structure — that's a rules-file case, not a feedback-memory case.
Chapter 1 · Chapter 8
2
Apply Chapter 2's own scope test. Would this instruction make sense pasted into an unrelated project? No — it only means anything alongside this site's own existing video-related course and folder structure. It belongs in this repository's own rules files, not the global CLAUDE.md.
Chapter 2
3
Decide it needs its own new file, not a squeeze into an existing one. Following Chapter 5's own precedent (kanji and programming lessons each got dedicated files instead of being forced into the language-lesson template), a video script's scene/cue/voiceover shape doesn't fit cleanly into L1–L7's dialog-and-vocabulary format, P1–P13's chapter format, or PL1–PL3's exercise format. A new file is the honest choice, not a shortcut.
Chapter 5
4
Pick the next available letter prefix. P, L, K, PL, LN, MT, SB, and R are all already taken. V — for Video — is free and reads unambiguously.
5
Write the rule itself, numbered from V1. See the draft below.
6
Wire the new file into CLAUDE.md's own @rules/ list. The one step Chapter 9 warned is easy to forget — a correctly-written rules file that's never added here is invisible to every future session, exactly as if it didn't exist.
Chapter 9
Drafting V1 and V2
video_lesson_rules.md (new file)
**V1 — Video Script Storage & Naming**A video script is a standalone file, one per video, stored atcontent/audio-video-production/video-scripts/<topic>.md — nonumbered chapter, matching the Sidebar Lesson precedent (SB3–SB5) ofone independent file per topic rather than a fixed course sequence.**V2 — Script Structure**Every script uses four fixed sections, in order: SCENE (a one-linesetting description), ON-SCREEN TEXT (any text cue overlaid onscreen), VOICEOVER (the actual narration line), and TIMING (anapproximate duration in seconds). Repeat this four-part block onceper scene.
Two rules is genuinely enough here — the scenario doesn't need P1–P13's full depth, the same way Chapter 6's own Cheat Sheets got a deliberately smaller rule set than a full Sidebar Lesson because the content itself is smaller in scope.
The Wiring Step
Per Chapter 1's own real code block, this repository's CLAUDE.md lists every active rules file as an @rules/ line. The new file only takes effect once a line for it is added there:
@rules/permanent_rules.md@rules/language_rules.md@rules/kanji_rules.md@rules/programming_lesson_rules.md@rules/links_rules.md@rules/my_tools_rules.md@rules/sidebar_rules.md@rules/video_lesson_rules.md← the new line
This exact gap was named as a risk twice already, in Chapters 1 and 9
Chapter 1's own third exercise asked what happens if this precise step gets forgotten, and Chapter 9 named it directly as the one thing automatic loading can't protect against on its own — a file that exists on disk but was never added to this list is exactly as absent from every future session as if it had never been written at all. Actually adding the line here is what closes that gap for real, rather than just describing it a third time.
Verifying This Chapter Followed Its Own Rules
A last, deliberately self-referential check: this file's own banner follows P1 (Chapter 3) exactly — Course, Chapter, File, Topic, and both dates. Its filename follows P5's own snake_case convention. And because this is genuinely the course's final chapter, P4 and P7 both apply the moment this chapter is finished: a combined book-format PDF gets generated (Chapters 3 and 6), and completed_courses.md/course_folder_mapping.md/course_bucket_list.md all get updated in this same turn (Chapter 7) — not as something described one more time, but as something that actually happens right after this chapter is saved.
The general checklist this capstone actually followed
Is it durable and universal, or conversational and specific? (Ch. 1/8) → Does it only make sense inside this one project? (Ch. 2) → Does an existing rules file's own format genuinely fit, or does forcing it in lose something real? (Ch. 5) → What letter prefix is free? → Write the rule → Add the @rules/ line (Ch. 9) → Update the tracking files in the same turn (Ch. 7). Six real questions, not a vague sense that "this should probably be a rule somewhere."
Final Coding Challenge
Final Challenge
A different recurring instruction shows up: "whenever generating a comparison table between two frameworks, always order columns so the framework the user already knows comes first." Walk this through the same six-question checklist this capstone used, and decide: new rules file, addition to an existing one, or memory instead? Justify each step.