L6Lesson 1

The Codify-Loop

After this, you'll run the plan-delegate-assess-codify loop as a reflex, ending every significant session with at least one new rule written from a real observation.

Before you start

Before diving in, complete Label Your Sources, Block Injection so your observations are grounded in labeled, trustworthy source content before you codify them as standing rules.

The idea

You finished a session. The model remembers none of it. Next session, it starts from zero unless you leave a trace. The codify-loop is the mechanism that leaves the trace: you plan the task, hand it to the agent, assess the output, then write one rule in your CLAUDE.md from what you just learned. That last step is the one almost everyone skips.

Here is the before and after: A developer removed a deprecated AWS SDK dependency in session 12. No rule written. Session 19, a different task, same codebase: the agent confidently re-introduced the deprecated package because nothing in the rules file said it was gone. Two sessions of cleanup work, avoidable with one line in CLAUDE.md after session 12.

The codify step is not a post-mortem. It takes 90 seconds. The standard is simple: one observation, one rule, written before you close the editor. Failures are the obvious trigger. Successes count too. If the agent nailed a response format you liked, that format goes in the rules file.

The difference between a rules file written in one speculative sitting and one built over 30 real sessions is provenance. Every rule in the mature file traces back to a specific moment. That traceability is what makes the rules defensible and prunable later.

Try it (10 min)

Watch out for

Codifying observations as explanations instead of instructions. 'The model tends to re-introduce deprecated packages' is a journal entry. 'Never use aws-sdk v2. Use @aws-sdk/client-* v3 modules only.' is a rule.
Writing the rule the next day, or next week. The 90-second window is before you close the editor. After that, the specifics fade and rules become vague.
Only codifying failures. If the agent produced output you would accept without edits, the format that produced it belongs in the rules file too.
Making the rule too general to be useful. 'Write clean code' does nothing. 'Use async/await, never .then() chains in this codebase' is actionable.
Treating the codify step as optional when the session went well. Smooth sessions produce the most durable rules because you are encoding what already works.

Paste this into Claude:

I just finished a session where [describe what you worked on and what happened: what worked, what failed, what surprised you]. Based on that session, help me write exactly one rule for my CLAUDE.md. The rule should: (1) be written as a direct instruction, not an explanation, (2) be specific enough that you could apply it without asking me a follow-up question, and (3) trace back to something that actually happened in this session, not a general best practice. Show me the rule as a single line I can paste directly into my CLAUDE.md.

What good looks like:

The rule is written as a direct instruction, not a description or wish
The rule is specific: it names a package, pattern, format, or behavior, not a vague category
You can point to the exact moment in the session that generated the rule
You pasted it into your CLAUDE.md before closing the editor
You can explain in one sentence what failure or success it encodes

What a good response looks like:

Based on your session: you asked the agent to add error handling to the API route, it wrapped the whole function in a try/catch and swallowed the error silently with an empty catch block. You had to rewrite it to log and rethrow.

Here is the rule:

`Never use empty catch blocks. Always log the error with console.error(err) and rethrow, or handle it explicitly with a typed error response.`

Why this rule works: it names the exact pattern to avoid (empty catch), specifies the two acceptable alternatives, and is narrow enough that the model cannot misapply it. It does not say 'handle errors properly' (too vague) or 'use try/catch correctly' (meaningless). It says exactly what to do.

Paste this into your CLAUDE.md now, before you close the editor. Next session, when the agent reaches for an empty catch block, it will find this rule first.

Go deeper (15 min)

Paste this into Claude:

I want to practice writing rules from past sessions, not just future ones. Here are three things that went wrong or surprisingly well in my recent AI-assisted work: [describe 3 specific incidents: a mistake the model made, a format it got right, a pattern it kept repeating]. For each one, write a single CLAUDE.md rule that would encode the lesson. Rules should be direct instructions. Flag any that are too vague to be actionable and suggest how to tighten them.

What good looks like:

You wrote one rule per incident, not one combined rule for all three
Each rule is a direct instruction the model can follow without clarification
At least one rule from a success is included, not only failures
You identified any rule that is too vague and revised it to be specific

What a good response looks like:

Three incidents, three rules.

Incident 1 (failure): The model kept using `var` instead of `const`/`let` in your JavaScript files.
Draft rule: 'Always use modern JS.'
Problem: too vague. 'Modern JS' means nothing to the model without specifics.
Revised rule: `Never use var. Use const by default, let only when reassignment is required.`

Incident 2 (success): The model wrote your weekly status update in a format you liked: three bullets, each starting with a past-tense verb, under 20 words each.
Draft rule: 'Write status updates in the format I like.'
Problem: the model has no idea what format you like.
Revised rule: `For weekly status updates: exactly 3 bullets, each starts with a past-tense verb, max 20 words per bullet.`

Incident 3 (failure): The model introduced a Lodash import to do something the native Array methods already covered.
Draft rule: 'Avoid unnecessary dependencies.'
Problem: 'unnecessary' is a judgment call. Be explicit.
Revised rule: `Do not import Lodash. Use native Array methods (map, filter, reduce, find) instead.`

All three rules pass the actionability test: the model can follow each one without asking a follow-up question.

When this breaks

Breaks when codification happens outside the 90-second window after a session, because the specific failure detail fades fast and the rule degrades into a vague best-practice that fires on every task instead of the one it was meant to encode.
Breaks when you only codify dramatic failures, because the most reliable patterns (formats and behaviors that already work for you) never get pinned down, so the model has to rediscover them every session and your acceptance rate stalls.

Claude can do it for you

At the end of any session, tell Claude: 'Based on what happened in this conversation, write one rule for my CLAUDE.md. Make it a direct instruction, specific enough to apply without asking me anything. Show it as a single line.' It will draft the rule. You copy it in.

You can now

Write a single-line CLAUDE.md rule from your most recent session that is a direct instruction, names a specific package, pattern, or format, and is traceable to one moment in that session.

Key takeaways

The model forgets everything. You are the only memory that persists. Codify or repeat.

The codify step takes 90 seconds: one observation, one rule, written before you close the editor
Provenance separates compounding rules from speculative ones. Every durable rule traces back to a real session moment
Codify successes too, not just failures. The format that worked is the rule worth pinning
A direct instruction beats a description every time. 'Never use var' compounds. 'The model sometimes uses var' does not

Go deeper

I just finished a session where [describe what you worked on and what happened: what worked, what failed, what surprised you]. Based on that session, help me write exactly one rule for my CLAUDE.md. The rule should: (1) be written as a direct instruction, not an explanation, (2) be specific enough that you could apply it without asking me a follow-up question, and (3) trace back to something that actually happened in this session, not a general best practice. Show me the rule as a single line I can paste directly into my CLAUDE.md.

Based on your session: you asked the agent to add error handling to the API route, it wrapped the whole function in a try/catch and swallowed the error silently with an empty catch block. You had to rewrite it to log and rethrow. Here is the rule: `Never use empty catch blocks. Always log the error with console.error(err) and rethrow, or handle it explicitly with a typed error response.` Why this rule works: it names the exact pattern to avoid (empty catch), specifies the two acceptable alternatives, and is narrow enough that the model cannot misapply it. It does not say 'handle errors properly' (too vague) or 'use try/catch correctly' (meaningless). It says exactly what to do. Paste this into your CLAUDE.md now, before you close the editor. Next session, when the agent reaches for an empty catch block, it will find this rule first.

I want to practice writing rules from past sessions, not just future ones. Here are three things that went wrong or surprisingly well in my recent AI-assisted work: [describe 3 specific incidents: a mistake the model made, a format it got right, a pattern it kept repeating]. For each one, write a single CLAUDE.md rule that would encode the lesson. Rules should be direct instructions. Flag any that are too vague to be actionable and suggest how to tighten them.

Three incidents, three rules. Incident 1 (failure): The model kept using `var` instead of `const`/`let` in your JavaScript files. Draft rule: 'Always use modern JS.' Problem: too vague. 'Modern JS' means nothing to the model without specifics. Revised rule: `Never use var. Use const by default, let only when reassignment is required.` Incident 2 (success): The model wrote your weekly status update in a format you liked: three bullets, each starting with a past-tense verb, under 20 words each. Draft rule: 'Write status updates in the format I like.' Problem: the model has no idea what format you like. Revised rule: `For weekly status updates: exactly 3 bullets, each starts with a past-tense verb, max 20 words per bullet.` Incident 3 (failure): The model introduced a Lodash import to do something the native Array methods already covered. Draft rule: 'Avoid unnecessary dependencies.' Problem: 'unnecessary' is a judgment call. Be explicit. Revised rule: `Do not import Lodash. Use native Array methods (map, filter, reduce, find) instead.` All three rules pass the actionability test: the model can follow each one without asking a follow-up question.

At the end of any session, tell Claude: 'Based on what happened in this conversation, write one rule for my CLAUDE.md. Make it a direct instruction, specific enough to apply without asking me anything. Show it as a single line.' It will draft the rule. You copy it in.