Turn a repeated correction into a CLAUDE.md rule

When Claude Code keeps making the same mistake, have it write one short, checkable rule into CLAUDE.md, so later sessions start with the correction.

Task: Turn a repeated correction into a CLAUDE.md rule · Other tasks

Fill in the details

What Claude keeps doing (required)

Describe the behavior so it reads after "you keep".

What it should do instead

Optional, but a rule that says what to do is easier to follow than one that only forbids.

Where the rule belongs

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

Your prompt (you can edit it)

You keep [fill in: What Claude keeps doing]. Add a rule to CLAUDE.md so later sessions start with this correction.

Put the rule in the project CLAUDE.md (./CLAUDE.md or ./.claude/CLAUDE.md, whichever exists), which the team shares once it is committed.

How to write it:
- Read the file first. If a rule on this already exists, rewrite it to be clearer instead of adding a second one. If another rule contradicts it, show me both and ask which wins.
- Keep it to one or two lines, concrete enough that anyone could check whether code follows it. Put it under the heading where it fits.
- If what I described is unclear or could be read two ways, ask me before writing.
- If it applies to a single folder or file type, or is really a multi-step procedure, say so and suggest a path-scoped rule in .claude/rules/ or a skill instead.
- If it must happen at a fixed point every time, such as before each commit, say that a hook may suit it better.

Change only this rule. Do not reformat the rest of the file, and do not commit.

Then show me the diff, and list any places in your current changes where the mistake still appears. Do not fix those yet.

1 required field is empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

You have corrected Claude Code on the same thing more than once, in this session or across sessions.
A reviewer flagged a project convention that Claude missed in its changes, such as a naming rule or a required test command.
You want the correction to reach your teammates' sessions too, through the project CLAUDE.md in version control.

When not to use it

The mistake happened once and is unlikely to come back. CLAUDE.md is loaded every session, so each line costs context; correct it in chat instead.
The rule must hold without exception, such as running a formatter after every edit. CLAUDE.md is context that Claude tries to follow, not enforced configuration; a hook runs every time.
The guidance is a procedure with several steps, or applies only to one folder. A skill or a path-scoped rule in .claude/rules/ fits better.

Why this structure

The opening request comes straight from the correction: what Claude keeps doing, and a request to write it down where every new session will read it.
The optional instead line turns a ban into an instruction. A rule that says what to do gives Claude something concrete to follow.
The location choice decides who gets the rule: the team through the committed project file, only you in this project, or you in every project.
Reading the file first and checking for existing or conflicting rules avoids duplicates and contradictions, which make Claude pick between instructions arbitrarily.
The one-or-two-line, checkable format follows the docs' advice to keep CLAUDE.md short and specific, because long files reduce how well Claude follows them.
The redirect lines send procedures to skills, folder-specific guidance to .claude/rules/, and must-run steps to hooks, so CLAUDE.md keeps only facts that apply broadly.
Showing the diff and listing remaining instances, without fixing them, keeps the edit small and lets you decide on the cleanup separately.

Example input (fictional)

What Claude keeps doing

adding new dependencies with npm when this repo uses pnpm

What it should do instead

use pnpm add, and never commit a package-lock.json

Where the rule belongs

the project CLAUDE.md (./CLAUDE.md or ./.claude/CLAUDE.md, whichever exists), which the team shares once it is committed

Follow-ups to send Claude

Now fix the places you listed where the mistake still appears, and run the tests.
Read the whole CLAUDE.md and suggest lines to cut that Claude would follow anyway, or that no longer apply.
Look back over this session and list any other corrections I made that belong in CLAUDE.md.

Common mistakes

Writing a vague rule, such as "follow our export style". Name the pattern exactly, for example "use named exports; no default exports".
Adding rules for one-off slips. A long CLAUDE.md makes each rule easier to miss; keep it to things that would cause mistakes if removed.
Never checking the result. Run /memory to open the file and read the rule, and /context to confirm the file loads in your session.

Course-correct a wrong approach: When Claude Code heads the wrong way, name the constraint it missed and ask for a different approach, with a check that shows the retry meets it.
Turn a repeated task into a skill: Describe a workflow you repeat and have Claude Code save it as a skill, so you or your team can run it later as a slash command.
Build something new from an existing pattern: Point Claude Code at code that already works the way you want, so the new feature matches its structure, naming, tests and error handling.

See all templates

Sources

Claude Code docs: Prompt library (Anthropic documentation)
Claude Code docs: When to add to CLAUDE.md (Anthropic documentation)
Claude Code docs: Write effective instructions (Anthropic documentation)
Claude Code best practices: Write an effective CLAUDE.md (Anthropic documentation)