Never correct it twice: one-line rules for ChatGPT and Claude projects

The film on this page opens on a board summary that starts by thanking everyone for their hard work, and it is the third time this month someone has told the assistant to stop. Each correction did its job in the chat where it was typed. The next chat started from the same defaults, so the same paragraph of thanks came back.

The usual answer is that the assistant has a memory, and it may help. Claude saves memory as topics while you chat, and you can see and edit each one under Settings > Memory [1]. ChatGPT with Memory on can remember relevant preferences and details from your chats, and OpenAI says it does not keep every detail of every conversation [2]. On Claude Team and Enterprise an owner decides whether memory is available at all, and it stays off for each member until they turn it on [1]. A correction that lands in memory is something the assistant may recall. A rule written into a project’s instructions is something every chat in that project is given.

Both vendors already give this advice for their coding tools, where the instructions live in a file in the repository. Anthropic says to add an instruction when Claude makes the same mistake a second time, or when you catch yourself retyping a correction from the last session [3]. OpenAI says to add a rule after you see the same mistake repeated, and when the agent gets something wrong, to correct it and tell it to update its instruction file, AGENTS.md, so the fix carries into future sessions [4]. The play in the film takes that habit out of engineering and into everyday chat work: never correct it twice, make it write the rule.

Use it straight after a correction, while the mistake and the fix are both in the chat. At that moment the assistant can see what it produced, what you changed and what you said about it, which is everything the rule needs.

In the film the answer comes back as “Board summaries open with the decision, never with thanks.” That is a usable rule. It names the document, says what to do and says what to stop doing.

Read the rule before you keep it. An assistant summarising its own mistake can produce something as vague as “be more concise”, which nobody could check a draft against. Anthropic’s advice for instruction files is to write rules concrete enough to verify [3], so edit until a colleague could look at a draft and say whether the rule was followed. Then paste it into the project’s instructions yourself and put the date beside it, so the monthly clean-up can tell old rules from new ones.

The prompt is two sentences, and each one does a separate job. The question changes what the assistant looks for, and the format keeps the answer small enough to live in instructions for months.

A long working session produces corrections you never typed as corrections: a preference mentioned in passing, a decision made halfway through, a format you settled on after three attempts. Before you close the chat, ask for all of them at once, and give the assistant your current rules so it can flag the clashes.

Copy the merged list back into the project’s instructions, keeping only the rules you would defend to a colleague. It suits people who would rather tidy up once at the end of a session than stop after every correction.

Rules go stale. A report template changes, or a preference turns out to be one person’s taste, or two rules written months apart start to pull against each other. Anthropic’s reading of a rule Claude keeps breaking is that the file is probably too long and the rule is getting lost [5], so the list needs cutting as often as it needs adding to.

The assistant suggests and a person decides. On a shared project that person should be named: Anthropic’s advice for shared instruction files is to give each one an owner and review changes to it like code [7].

Both products keep three kinds of standing context apart: instructions for one project, instructions for every chat, and memory. The play uses the first, because a project is where one recurring job lives, and a rule about board summaries has no business in every other chat you run.

Every row was checked on the vendor’s own page on 11 October 2026. Menu names and plan limits move between releases, so check them against your own workspace before you write them into a team guide.

Claude Cowork has one more home for rules. When you select a local folder in Cowork on desktop, Folder instructions hold that folder’s context, and Claude can update them itself during a session [15]. There the assistant keeps the rules for you, so read what it writes the way you would read a colleague’s edit.

A rule that saves one person a correction saves a team the same correction, and the film reaches that point on its own: share the project and every colleague’s chats in it start from the same list. The price is that one person’s taste becomes everyone’s default, so decide who edits the instructions before you share them.

The owner matters more once the list is shared. Anthropic’s guidance on Organization instructions is that they should be short, specific and tested, because they are included in every message and contradictory ones may not be followed reliably [13]. The same holds for a shared project: one owner, a short list, and a date on every rule.

Then keep the rules clean. Claude shows a shared project’s instructions to anyone with Can view [11], and ChatGPT lets every member of a shared project see its chats and files [9]. The rules reach all of them, so client names, confidential figures and anything about a named person stay out. Run this in a work account your company administers, such as ChatGPT Business or Enterprise or Claude Team or Enterprise, and keep confidential material out of personal accounts. Which of those plans to buy is its own decision, and our guide to the four ChatGPT and Claude business plans sets them side by side.

The play cuts repeat corrections. It does not end them, and it brings a few problems of its own, each with a simple counter.

Setting up and rolling out ChatGPT and Claude for companies is core 1AYM work, and so are the instructions, skills and permissions around them. On a rollout we would set up the shared projects each team works in, give every project’s instructions an owner and a review date, and keep client names and confidential figures out of them. Where a rule has to hold every time rather than most of the time, we would build it as a control the system enforces, which is our AI governance implementation work.

It can start small. 1AYM takes fixed-scope statements of work as well as larger builds, and fixed-scope work can start within a day of the scope being signed. If a second opinion on how your teams keep their rules would help, book a call or email enquiries@1aym.com.