One morning I opened Cowork to tidy the store assets for a wallpaper app, and my hands stopped over the request box. "Don't touch the original images." "Put exports only in the _out folder." "Start file names with the date." I had typed nearly the same three lines last week, and the week before.
On the day I forgot, it went exactly as you'd expect. Exported images ended up sitting right beside the originals.
So I tried placing one short text file named CLAUDE.md at the top of the folder. In short, about ten lines were enough. Here is how I made it and how I check that it works.
CLAUDE.md stands in for the preamble you retype
When a working folder contains a CLAUDE.md, Cowork and Claude Code read it as standing instructions. In my setup, what I wrote in the file became the starting context of the conversation as soon as I selected the folder.
That means the preamble you used to type with each request can live with the folder instead. It is not a hard setting. It is a plain text file.
Placing it doesn't make everything work, though. That part comes next.
Write only three things
At first I got greedy. I listed some twenty items — the folder's history, my preferred tone, prohibitions — and the results were poor. The longer the file, the more the one line that mattered got buried.
Now I keep to three.
| Item | What to write | Example in my folder |
|---|---|---|
| Do not touch | Places that are read-only | Contents of originals are read-only |
| Where output goes | Where new files may be created | Exports go only in _out |
| Naming | How file names and dates are written | Start with a date, like 20261014_ |
All three are about place and shape rather than prohibition. A where-and-how rule was easier to reread later than a list of don'ts.
The file I actually placed
I created CLAUDE.md directly under the folder with this content.
# Promises for this folder
- The originals folder is read-only. Do not edit, delete, or move its contents.
- Put newly created files only in the _out folder.
- Start file names with the date, like "20261014_topic.ext".
- If you are unsure, stop and ask me.Four lines. The last one is an escape hatch for situations the file doesn't cover. I can't list everything that is allowed, but "stop when unsure" fits in one line.
Check that it is read by asking
Placing the file doesn't tell you whether it works. At the start of a new conversation I ask:
Summarize this folder's promises in three lines, as far as you understand them.If the three lines match what I wrote, it is working. If not, I suspect the file name or the level where I put it. Once I named it claude.md in lowercase and it wasn't read. It has to be CLAUDE.md, capitals included.
To go one step further, I make a request that would break a promise — "turn the images in originals into black and white." If it declines or asks me to confirm, the promise is in effect. Do this only in a duplicated test folder, and avoid trying it on real assets.
When it grows, halve it
After a few weeks the promises keep multiplying. I think the load of reading them grows with them, and so does the chance of misreading.
Once at the start of each month I reread the file and ask of each line, "Would I really be stuck without this?" The ones where the answer is no, I delete. I wrote about trimming always-loaded instructions in The Night I Halved the Instructions I Load Every Time: Three Drawers Before Any Cutting. For the order in which to grant folder permissions, see Write Access Came Third: The Order I Hand Folders to Cowork.
Keep secrets out of the promise file
One last line to draw. CLAUDE.md is read into conversations again and again. Don't put passwords, API keys, or customers' personal details in it. Even when you're tempted to write "this key may be used," leaving it out is safer.
Write only places and shapes in the promise file — never keys or names.
The next time you hand over a folder, start by creating a four-line CLAUDE.md and asking for a three-line summary. That alone should remove one morning of forgetting the preamble.