Stop telling Claude the same thing twice

What Claude already remembers

Claude saves some of what you tell it by itself, in two places. The memory and Cowork facts here are from Anthropic’s help pages and docs, read on 30 September 2026.

In the Claude app

What it keeps: it saves what it learns as topics while you chat, and you can tell it “remember this”, per Anthropic’s memory page.
Where to see it: Settings, then Memory, where you can read, edit or delete what it saved.
Who has it: on by default on Free, Pro and Max, and off on Team and Enterprise until an owner turns it on. Each Project keeps its own memory.
The gap: Anthropic’s page does not say corrections are among the things it saves, so open Settings, then Memory, and look for yours.

In Claude Code

What it keeps: Claude Code, the version that works on files on your computer, writes itself notes from your corrections and preferences. Claude Code’s memory docs say this is on by default.
Where to see it: type /memory. The notes are plain text files you can edit or delete.
The limit: only the first 200 lines, or 25KB, of its list of notes load when a session starts, and nothing forces Claude to follow a note, so it can still slip.

What you need

Somewhere Claude can save a file, for the full version: Claude Code, or Cowork in the Claude desktop app (the part that works inside your files, on paid plans) with a folder connected.
Or an ordinary chat, where no file lasts to the next chat, so it hands you the log to keep in a Project’s knowledge or paste into the next chat.

The skill

Check Claude’s own notes first, because if your correction is saved there and Claude follows it, you are done. The skill is for the ones that keep coming back: it keeps them in one file beside your work, adds an entry only after your yes, holds the list to 12, and tells you each session which entries it used.

SkillMake Claude keep a mistakes log

---
name: mistakes-log
description: Keep a short log of my corrections and your own mistakes, read it before each task and update it as we work. Use at the start of a session and whenever I correct you.
---

# Keep a log of your mistakes

You keep a short, living log of what went wrong when we worked together and what to do instead, so I never have to make the same correction twice. You read it before you start, you propose an entry when something goes wrong, and you keep it short enough that every entry still gets followed. Nothing goes into the log without my yes. The stakes: a log you do not read is useless, a log you pad with guesses teaches you the wrong thing, and a log that grows forever gets ignored. Better five true entries than thirty vague ones.

Work in four stages: find the log, read it before the task, propose entries as things happen, tidy it before we finish. A session is one chat, or one run of Claude Code.

## Stage 1: Find the log, or ask before you start one

1. Work out where you are:
- IF you can read and write files here (Claude Code in a project folder, or a folder I connected in Cowork): the log is a file named `mistakes-log.md` at the top of that folder.
- IF you cannot write files here (an ordinary chat, or a Project): you cannot keep a file from one chat to the next. Say so in one line. The log is whatever I paste in or have added to this Project, and you will hand me the updated log to save at the end.
2. Look for the log. IF it exists, go to Stage 2.
3. IF there is no log, ask me one question and wait: "There is no mistakes log here yet. Start one in [the exact place]?" Never create the file without my yes.
4. IF I say yes, create it with the four headings from "The log format" and nothing else. Never fill a new log with mistakes that have not happened.

## Stage 2: Read it before you do anything else

1. Read the whole log before you plan or answer.
2. Tell me in one or two lines, starting with the words "Log read": how many live entries it holds (Retired does not count), and which ones apply to what I just asked. Do not apply Retired entries. Example: "Log read, 6 entries. Two apply here: answer first, and no invented prices."
3. Apply those entries from your first reply. IF an entry conflicts with what I am asking now, follow what I am asking now and say which entry it overrides. IF an entry conflicts with my standing instructions, or with something you already remember about me, do not pick one quietly: show me both, ask which stands, and offer to fix the entry.
4. IF the log is longer than the cap in Stage 4, say so and offer to tidy it before we start.

## Stage 3: Propose an entry when something goes wrong

Propose a new entry, or an update to an existing one, when any of these happens:
- I correct you: I say no, tell you something is wrong, repeat an instruction, or redo your work myself.
- You catch your own mistake: you had to redo a step because of a wrong assumption.
- A second attempt works after a first one failed. Propose what worked.

Do not log:
- A preference that only matters for this one task.
- Facts about me that are not a correction (they belong in my profile or instructions).
- Passwords, keys, account numbers, or anything private about another person. Never.
- Something you are guessing I might want. If I did not correct it and it did not fail, it is not an entry.

How to log it:
1. IF the correction is unclear to you, ask me one question first, e.g. "Is that for every email, or only emails to clients?"
2. Finish the fix first. The steps below cover all three cases above: my corrections, your own mistakes and what worked.
3. Check the log for an entry about the same thing. IF there is one, what you propose is an update to it, never a second entry: sharper wording if my new correction shows it was too vague, one added to its count, today's date. IF the match is under "Retired", propose moving it back.
4. Show me the entry, or the reworded entry, in one line and ask, e.g. "Log this? Answer first, reasoning after." Write it only after my yes. IF I change the wording, log my wording. IF I say no, do not log it, keep following the correction for this task, and do not ask about the same thing again this session. IF I corrected two things at once, list both and ask once.
5. Write the entry in the format below and confirm in one line, e.g. "Logged." IF you do not know today's date, ask me. IF you cannot write files, keep the entry in this chat and include it when you hand me the log.

## The log format

```
# Mistakes log

## Do this every time
- [the rule, as one instruction I could follow cold]. Because: [what went wrong, with the real example]. Seen: [count], last [date].

## Never do this
- Never [the thing]. Do [the replacement] instead. Because: [what went wrong]. Seen: [count], last [date].

## What worked
- When [situation], [the approach that worked]. Seen: [count], last [date].

## Retired
- [entry], retired [date]: [why].
```

Rules for every entry:
- One instruction, written so it makes sense with no memory of this chat.
- The real example, in a few words. Never a made-up one.
- Say what to do, as well as what to avoid.

## Stage 4: Tidy it before we finish

Do this when I say we are done, when I ask you to tidy the log, or when it passes 12 live entries. Work out steps 1 to 3 without changing the file:
1. Merge entries that say the same thing.
2. Rewrite any entry that was broken again after it was logged: it was too vague, so make it specific.
3. IF there are still more than 12 live entries, move entries seen only once to "Retired", oldest first, until 12 are left. IF that is not enough, show me the oldest of the rest and ask which to retire. Never delete an entry without telling me.
4. IF an entry has been seen three times or more, tell me: "This keeps coming back. It may belong in your standing instructions, where it applies to every chat." Give me the one line to paste. Never change my instructions or settings yourself. IF I say I have pasted it, move the entry to "Retired" with the reason "moved to standing instructions". IF I say no, add "keep in log" to the entry and do not offer it again.
5. Show me the merges, rewrites and retirements as one short list and wait for my yes before you save them. IF there are none, say so and carry on. IF I say no to one, leave that entry as it was.
6. Tell me which entries you used this session, and any you broke.
7. Save the file. IF you cannot write files, give me the full updated log as a file to download if you can make one here, otherwise print it in one block, and tell me exactly where to keep it (this Project's knowledge, or a note I paste at the start of the next chat).

## Before you tell me you are done, check

1. Every new entry came from a real correction or a real failed attempt in this session, and I said yes to it.
2. No entry repeats another.
3. Nothing private or secret is in the log.
4. I know what changed: entries added, updated and retired, and which entries you used, in one short list.
5. If you could not save the file, you said so and handed me the log.

How to use this skill

Put the skill in Claude. Download the file, which is already named SKILL.md. In the Claude app, put it in a folder named mistakes-log, zip the folder and upload the zip at Customize, then Skills. In Claude Code, tell it “Move the SKILL.md in my Downloads to ~/.claude/skills/mistakes-log/”, then start a new session.
Start a session with it. A session is one chat, or one run of Claude Code. Open it with “Use my mistakes-log skill” and the job in the same message. The first time in each folder, it asks before it creates the log, a file named mistakes-log.md in that folder.
Correct it as you normally would. It fixes the work first, then shows you the lesson in one line and asks before logging it. Say yes, reword it, or say no.
Open the next session the same way. It reads the log before anything else and tells you which entries apply to the job. If a session does not open with a “Log read” line, the skill has not run, so ask for it by name.
Say “we are done” at the end. It merges repeats and keeps the list to 12 by moving older one-offs under a “Retired” heading at the bottom of the file, where they no longer count. It asks before saving those changes, then lists what changed and which entries it used.
Move a lesson that keeps coming back. Once an entry has been seen three times, it offers you one line for your Instructions for Claude, the box in Settings that applies to every chat (in Claude Code, the CLAUDE.md file). The rules file guide shows where that is in each app.

What a run looks like

Four test runs in Claude Code, replaying corrections I really made on 29 and 30 September, with Claude standing in for me at the keyboard. The ask-before-logging step was added before the third. Trimmed:

It asked first. The folder had no log, so it asked before creating one, then made a file with four empty headings.
A real entry: “Never give neighbouring guide titles the same opening word. Do read the titles beside it and open differently instead. Because: one batch all began ‘How to’, and the next all began ‘Can’. Seen: 2, last 30 Sep 2026.”
It updated the old entry. That entry began as a rule about “How to”. When the same mistake came back as “Can”, it reworded the entry and raised the count.
A fresh run read it. A new Claude with no memory of the first run opened with “Log read, 5 entries. Two apply here”, and named them. Its title options had no repeated opener.
It asked before logging. Given my correction that a news guide should open with context, it fixed the draft, then asked “Log this?” with the entry in one line, and wrote nothing until the yes.
It took a no. Given two corrections at once, it asked once about both. After a yes to one and a no to the other, it logged only the first and said it would not raise the other again.
It offered to move one up. The opening-word entry had now been seen three times, so it gave one line to paste into my Instructions for Claude, and changed no settings itself.

The honest bit

A written lesson lowers the odds, and the mistake can still come back. One developer who logged 43 of their AI’s mistakes (3 September 2026) found that the ones turned into an automatic check stopped, and the ones only written down as rules kept happening.
What a log cannot do. Anything that must never happen needs a check you run yourself, such as reading the email before it is sent.
Why the log is capped. Claude Code’s docs say longer instruction files get followed less. Another developer’s lessons file (27 August 2026) reached 121 entries in 18 days by his own count, and his verdict was that memory alone does not stop a repeat.
What the test can show. Claude typed my real corrections in my place, and one verdict, that three titles were flat, was its own. Claude Code’s own memory for this project already held three of the same corrections, so the runs prove each step happens. Whether the log alone stops a repeat is unproven.
Untested. An ordinary chat or Project, Cowork, the upload route, an unclear correction, an entry that clashes with your Instructions for Claude, the tidy on a log longer than 12, and this final wording called by name (the first run followed the file by hand, the last two read it directly).

Start the log on your next job

Add the skill, open your next task with it, and say yes to the first lesson it offers.

A few quick questions

What should never go in the log?

Passwords, keys, account numbers, and anything private about another person. The skill is written to refuse those, and the log is a plain file that anyone with the folder can read.