The File That Remembers
Every session starts with one uploaded file. It tells the AI where everything lives, which mistakes we’ve already paid for, and how I like to work. What the AI world calls it, what’s in mine, and how to start your own.
Every working session on HoldemRobots starts the same way. I upload one file and type something like “here’s our setup.” By the time Claude answers, it knows the three machines I work across, where every file lives, how a fix gets deployed, which mistakes we have already paid for, and how I like to work. Part 13 called this file our shared memory and put it first on its list of habits worth stealing. This article opens it up.
The problem it solves
An AI starts every conversation from nothing. It doesn’t remember yesterday’s session, the server you described last week, or the rule you made it promise to follow. Some tools now keep a little memory between chats, but you can’t see all of it or edit it line by line. Without help, every session starts by explaining the whole project again, and every lesson has to be learned twice.
The fix is old-fashioned: write it down. Keep one plain text file that holds what your AI partner needs to know, hand it over at the start of every session, and update it at the end.
What the AI world calls it
The idea is common enough now that the tools have built it in. AI coding assistants read a project instruction file automatically. Claude Code reads a file called CLAUDE.md. Many other tools, from OpenAI’s Codex to Cursor and GitHub Copilot, read AGENTS.md, an open format started in 2025 that its makers call “a README for agents.” Chat apps offer the same thing in other forms: custom instructions, project knowledge files, and memory.
Mine is the hand-made version. It’s a Markdown file I upload myself, so it works with any AI and I can read every word of it. The name doesn’t matter. What matters is what goes in it.
What’s in mine
It started in early July as a page of setup notes. By mid-October it had been rewritten 21 times and run to about 1,400 lines. It is not an easy read. Roughly, it holds:
- How to use it. Two lines at the top: upload this, say “here’s our setup,” and remind Kevin of the login steps before any testing.
- A change log. What changed in each version, newest first.
- Project history and status. What shipped, what’s open, and what we decided not to build.
- A map of the machines. My Windows cloud desktop, the Linux server, and the container inside it, with which commands run where.
- The test routine. Which page to open, in which order, every time.
- How I like to work. The section that matters most, and the one this article is about.
- Standing reminders. The rules Claude reads before touching anything.
How I like to work
The working preferences are the heart of the file. Nobody wrote them in advance. Each one came out of a session that went wrong. Here are the ones that shaped everything, mostly in the file’s own words.
Slow down: one change, one test
One change → one test → one report.
The file says this came “directly out of a session that ran in circles from over-batching.” Make five fixes at once and something breaks, and you can’t tell which fix did it. One at a time is slower per step and much faster overall.
Don’t call it working until I’ve seen it
This one is in the file three different ways, because it kept coming up. A fix can be sitting in the file on the server and still not be live. So nothing counts until it clears two checks: the change is in the file, and the change is in the running copy. Even then the file tells Claude to stay neutral:
The right phrasing after two gates pass is neutral: “both gates cleared, go ahead and test.”
The file even records the moment I pushed back: “don’t declare success to early, should we test it first.. You know my opinion on this stuff.” It’s there, typo and all, so the next session knows I meant it.
Be honest about what you can’t see
Claude should never claim to have verified a rendered result it cannot see.
Claude writes the change. I deploy it and look at the browser. The file keeps that split clear, so an AI that has only read the code never reports on a page only I can see.
Give it the real file
Early on, Claude retyped code from memory or from short excerpts I pasted. It looked identical on screen and failed to match byte for byte, because the old file mixes tabs and spaces. The rule now is simple: I upload the actual file, Claude reads it with its own tools, and edits are copied exactly, never retyped.
Make it easy to copy
Every URL, command and file path goes in its own code block, because I use the copy button and small inline text is easy to grab wrong. Before any test, Claude repeats the full login steps with the addresses ready to copy. That rule existed and still got missed twice in one session, so the file now spells out the trigger: any message that asks me to look at something in the browser carries the full address in that same message.
But I’m the boss
Sometimes I want to move faster. The file allows for that: when I say “let’s make all the changes now, confirm them when we are done with all of them,” Claude should do exactly that, “but still verify everything together at the end with the same rigor.” A rule I can override on purpose is better than one that gets ignored by accident.
Every rule has a date and a price
What makes the file worth trusting is that almost every rule says when it was learned and what it cost. Here are a few:
| Date | What happened | The rule it left behind |
|---|---|---|
| Jul 4 | One unclosed image tag blanked a whole page | The old page engine reads strict XML, so every tag must close |
| Jul 5 | Edits sat correctly in the file, but nothing changed in the browser | Two checks before testing: in the file, then in the running copy |
| Jul 5 | The same stale text appeared three times; one replace would have missed two | Say when text appears more than once, use Replace All, then recheck |
| Jul 7 | Code pasted through chat kept losing an &; cost 3+ rounds | Write the code so it never needs that character |
| Jul 7 | A replace clicked repeatedly copied one rule four times | Check returned files for accidental duplicates |
| Oct 6 | Site updates went to the wrong Cloudflare project for a week | Only the real address, in a private window, proves it’s live |
| Oct 14 | An old zip almost wiped out a newer article | Always build the next version from the latest one |
A rule with a story behind it gets followed. A rule without one gets argued with.
Keep secrets out
A working file collects things it shouldn’t. Mine holds a test login, internal server addresses and an account number, which is fine for a file only Claude and I see. It isn’t fine for a file you share. If you start one, keep passwords and keys in a separate place and write placeholders like <your-server> in the file. Then you can hand it to a classmate, a teacher or a new AI without a second thought.
Keep it current
A stale file is worse than none, because it’s wrong with confidence. Every session on HoldemRobots ends the same way: Claude writes up what changed, I save it as the next version, and that is the file I upload next time. The version number and change log at the top tell both of us which copy we’re looking at.
Start your own
You don’t need 1,400 lines. Start with twenty and let the mistakes write the rest.
# My Project: setup and working preferences
Version 1, updated <date>
## How to use this file
Upload at the start of each session. Read "How I like to work" first.
## What we're building
One paragraph: the goal, and what "done" looks like.
## Where things live
- Code: <folder or repo>
- Runs on: <laptop / server / cloud>
- How to test: <the exact steps>
## How I like to work
- One change, one test, one report.
- Don't say it works until I've seen it work.
- Put every command and URL in its own code block.
- Work from the real file, not from memory.
## Lessons learned (newest first)
- <date>: what went wrong, and the rule it taught.
## Open items
- What's next, and what we decided not to do.Then add a line every time something goes wrong. In three months it will know more about how you work than you could have written down on day one.
If you’re taking the course and want to see the real thing, ask, and I’ll give you a copy of mine.
Written by Kevin Swinson with Claudette, the pen name for Claude, the AI from Anthropic that helped build HoldemRobots.AI. Quotations come from version 21 of the environment file. It describes the project as it stood on the date above.