Your Permanent Setup

Every new chat, the same preamble. Who you are, what the project is, who the audience is, what tone, which words you never use, what was decided last month. You've typed it so many times you have a version saved in your head, and you still type it slightly differently every time.

This is the direct consequence of the model having no memory — and it is entirely solvable, because memory was never the thing you needed. What you needed was the desk laid the same way every time, without you doing it.

Don't explain again — lay the desk once.

Think of it as onboarding. You don't tell a new colleague every morning what the company does and how you like documents formatted. You write it down once, and everything after that starts from there.

Three levels of permanence

They differ in scope and lifespan, and most people use only the first.

Personal preferences. Settings that apply to everything you do: how you want answers structured, your language, your profession, your standing dislikes ("no bullet-point summaries unless I ask", "assume I'm technical", "be direct"). Written once, applied everywhere. The cheapest quality improvement available and the most often skipped.

A project workspace. Instructions plus materials scoped to one piece of work — in Claude these are Projects. This is where the real leverage is: the audience, the vocabulary, the constraints, examples of good output, key documents, decisions already made. Every conversation inside it starts with all of that on the desk.

A file inside the work itself. For anything living in a folder or a repository, an instruction file that the tool reads automatically — Claude Code, for instance, reads a CLAUDE.md from the project root. This is the longest-lived level: it travels with the project, survives the tool, and is versioned along with everything else. It's also the only level a teammate inherits automatically.

Match the level to lifespan. A preference that's true of you forever goes in the first. Everything about this project goes in the second or third. Anything that will be false next week goes in neither — it belongs in the message.

What to write in it

The structure that works, roughly in order:

• Who and what. You, the project, the audience, the goal. Two or three sentences.
• Defaults. What to do unless told otherwise: language, format, length, level of detail.
• Vocabulary. Project terms, product names, preferred spellings, words to avoid.
• Standards. What "good" means here — the bar from article 5, made permanent.
• Boundaries. What not to do, what to never assume, what always requires asking.
• Examples. One or two short samples of output you consider right. Worth more than the rest combined.

And what not to write: secrets of any kind (it's a file, and files get shared); anything that will go stale quickly; and flattery-as-instruction. "You are a brilliant expert assistant" costs you attention and buys nothing — that was article 5's finding, and it applies double to text that gets loaded into every single conversation.

Memory features are not learning

Some products offer a memory that carries facts between conversations. Worth being precise about what that is: text stored somewhere and reloaded onto the desk. Not training, not weights, not the model changing. It's an automatic paste.

Which means it behaves like a paste. It can hold something wrong or stale for months. It can include a passing remark you never meant as a standing fact. So: look at what's actually stored occasionally, delete what's outdated, and don't rely on it for anything that matters — the deliberate levels above are auditable in a way a memory feature isn't.

Hygiene

Standing instructions rot faster than you'd expect, and rotten ones are worse than none.

Contradictions are worse than gaps. Two instructions that disagree produce unpredictable behaviour, and you'll blame the model.

Length costs attention. These sit at the top of every context, competing with your actual material. A tight page beats five sprawling ones, and article 2's point about long contexts applies here first.

Prune on a schedule. When the project's direction changes, the instruction file usually doesn't — until the day you notice answers reflecting a decision you reversed months ago.

Test it directly. Open a fresh chat and ask: "What do you know about this project and how I want you to work?" Anything missing or wrong shows up in one turn. Do this after every edit.

Build the library

Article 7 ended with a small idea worth expanding here: a prompt that worked twice is an asset. Keep a file of them — the brief that produces good meeting notes, the code-review checklist, the editing pass you always run, the tutor prompt for quizzing yourself.

The escalation is natural, and it's the backbone of the final article: one-off → saved prompt → standing instruction → automated. Most people stop at the first rung and re-type their way through the same task for years.

For a team, the file in the repository does something extra and slightly unexpected: it forces the tacit knowledge into writing. The document that explains your conventions to the model turns out to be the onboarding document you never wrote for people. That's not a side benefit — for many teams it's the main one.

In practice

Fill in your personal preferences today. Ten minutes, applies to everything afterwards.

One project workspace per real project, with materials and examples in it, not just instructions.

Put project rules in a file inside the project when the work lives in a repo or folder.

Include one example of good output — it outperforms paragraphs of description.

No secrets, no flattery, nothing that goes stale.

Verify with a fresh chat after every change: "what do you know about this project?"

Check yourself

Close the article and answer in your own words:

1. Why is "the model has no memory" not actually the problem to solve?
2. What are the three levels of permanence, and how do you choose between them?
3. What belongs in a standing instruction, and what three things must stay out?
4. In what sense is a memory feature not learning, and what follows practically?
5. Why are contradictory instructions worse than missing ones, and why does length cost you?
6. What's the escalation from a one-off task to an automated one?

In short

• The model has no memory, but the desk can be laid automatically — that's all you actually needed.
• Three levels: personal preferences (everywhere, forever), a project workspace with materials and instructions, and an instruction file inside the project itself, which is the longest-lived and the only one teammates inherit.
• Contents: who and what, defaults, vocabulary, standards, boundaries, and one or two examples of good output. No secrets, nothing that goes stale, no flattery.
• Memory features store text and reload it — an automatic paste, not learning. Audit it and prune it.
• Contradictions beat gaps for damage; length competes with your real material; instructions rot when the project changes.
• Test after every edit with a fresh chat: "what do you know about this project?"
• Escalate: one-off → saved prompt → standing instruction → automated.
• Don't explain again — lay the desk once.