Point at the pattern, not just the outcome

The code came back working. It is also the only file in the repository that fetches with axios, handles errors with a try/catch where everything else uses a Result type, and lives one directory away from where its siblings live.

Nothing you asked for was violated. You asked for the outcome, and you got the outcome. What you did not ask for was consistency with anything, and there is no way to infer a house style from an empty prompt.

The cheapest sentence in prompting

Point at the file that already does it right.

add a calendar widget

look at how the existing widgets on the home page are implemented to understand
the patterns — HotDogWidget.php is a good example. follow that pattern to build
a calendar widget that lets the user pick a month and page forward and back
through years.

The second version is the documented rewrite for this exact failure, and the mechanism is worth naming: you have replaced a description of a style with a reference to an instance of it (Best practices). Descriptions of style are lossy and arguable. A file is neither.

This is the same move as Lesson 2.2's @ reference, applied to a different question. There, the reference answered "what is the code?". Here it answers "what should the code look like?".

The clause people leave off

The documented rewrite ends with a constraint that is easy to skip and expensive to omit:

...build it from scratch without libraries other than the ones already used in
the codebase.

Left unsaid, "add a calendar widget" is a reasonable invitation to add a date-picker dependency. You will discover this at review time, which is the most expensive possible moment to discover a dependency.

Negative constraints are cheap and specific. no new dependencies, don't touch the migration files, keep it in one file — each one is a sentence that prevents a class of diff you would have rejected.

Where a convention should live

The prompt is the right home for a convention exactly once. If you are typing it a second time, it belongs somewhere durable, and there are four homes with different guarantees.

The line between the middle two is the one people get wrong. CLAUDE.md is loaded every session, so it should only hold what applies broadly. Knowledge that is relevant sometimes belongs in a skill, whose body Claude loads only when it is needed. That is not quite free — every skill's name and description sit in the listing on every turn, used or not (Skills) — but a one-line description is a different order of expense from the document it stands for.

The line between advisory and guaranteed matters just as much, and Lesson 6.2 states it in full. CLAUDE.md instructions are advisory — read, weighed, and occasionally lost. A hook runs as a script at a defined point in the workflow, so it happens whether or not the model was paying attention. "Run the linter after every edit" is a hook, not a bullet point.

Keeping CLAUDE.md obeyed

/init generates a starter file from your project structure, and /context confirms it actually loaded. Then the maintenance problem starts, and it has one rule worth memorising. For each line, ask whether removing it would cause mistakes. If not, cut it.

This is not tidiness. A bloated CLAUDE.md causes Claude to ignore your actual instructions, because the rule you care about is buried among forty you wrote once and never checked. Emphasis fails the same way: IMPORTANT on one line makes that line stand out; on nine lines, none of them do. And the first entries to cut are the ones that describe the codebase — a file-by-file tour, an API reference, an architecture essay — because Claude can read the code for itself, while the test command and the directory that is off limits it cannot guess.

Lesson 6.6 builds the pruning argument in full: which symptom means the file is too long rather than ambiguously worded, why length costs adherence and not just tokens, and where each cut line goes instead.