How I Use Claude
← lovelace.solutionsThe files, the rituals, and why an amnesiac AI can still remember. Templates at the bottom.
READING LEVEL
01THE PROBLEM
An AI chat has no memory of you. Not a poor memory — none at all. You close the window and everything you told it is gone.
It is like hiring a brilliant new assistant who quits at the end of every conversation. Tomorrow you start over: who you are, what you are working on, what the two of you already settled. Most people retype it all. Some skip it and let the AI fill in the blanks by guessing, which is worse.
You know the shape of this already: a good chat, real decisions, and then the window closes and none of it carries. The next chat has never met you.
So you paste the same background in again, and again, and you end up paying a re-briefing tax at the start of every chat. Skip the paste and the model fills the gaps with plausible invention instead.
Every AI chat starts from zero. It doesn't know who you are, what your machines are called, what you decided last week, or which mistakes it already made once. Most people re-explain their world every session — or worse, let the AI guess.
Sessions are stateless. No identity, no history, no decision log: context is reconstructed from scratch on every invocation.
Unmanaged, that cost lands on you as repeated manual briefing, and the failure mode is silent — an unbriefed model interpolates rather than asks.
02THE FIX: FILES ARE THE MEMORY
So stop asking the chat to remember. Write the things that matter into ordinary documents — the plain kind, nothing special — and keep them somewhere you can always find. At the start of a session you show them to the AI. At the end, anything you decided goes back into them. The conversation is throwaway. The documents are not.
↻ tomorrow's session starts where today's finished
Invert it. Durable knowledge lives in a handful of plain text files kept in one canonical place and attached to the project, so every new chat reads them before it does anything else. The chat is disposable; the files are not. Anything worth keeping gets pulled out of the conversation and into a file before you close the tab.
↻ each chat inherits the last one's output
Flip the problem around. Keep your durable knowledge in a few plain text files, stored in one canonical place, and have every session read them first. The chat is disposable; the files aren't. Anything worth keeping gets pulled out of the chat and into a file — that's the whole game.
↻ next session starts smarter than the last one
Externalise state. Durable context lives in versioned plaintext masters under one canonical root; sessions hydrate at open and extract deltas back at close. Nothing durable exists only in a transcript.
↻ idempotent: replay from masters reproduces the same briefing
03THREE LAYERS OF SCOPE
Not every fact belongs in every place. Put each one at the widest level where it is still true, so you write it down once and it shows up wherever it is needed.
ACCOUNT SETTINGS
things that are always true about you — these appear in every conversation you have
PROJECT INSTRUCTIONS
how you want this one piece of work handled
PROJECT KNOWLEDGE
the actual documents and details that work runs on
Scope each fact to the widest layer where it stays true. Write it once at the right level and it reaches everything below it, instead of being pasted into three places and going stale in two.
ACCOUNT SETTINGS
your standing profile — loaded into every chat, nothing to attach
PROJECT INSTRUCTIONS
the working rules for this one project
PROJECT KNOWLEDGE
the attached files and facts this project runs on
Not everything belongs everywhere. Facts live at the widest layer they're true at:
ACCOUNT SETTINGS
who I am — loads in every single chat
PROJECT INSTRUCTIONS
how we work on this one project
PROJECT KNOWLEDGE
the facts and files of this project
Scope by widest-true. One fact, one home; lower layers inherit. Duplication across layers is drift waiting to happen.
ACCOUNT SETTINGS
global identity — always in context
PROJECT INSTRUCTIONS
per-project operating contract
PROJECT KNOWLEDGE
per-project corpus
04THE FILES
A short profile of you. Your name, what you do, the equipment you use, how you like answers written, and the mistakes you have already had to correct once. Write it once, reuse it on everything.
The house rules for one piece of work. Who makes the calls and who does the typing, and the standing instruction to look before it changes anything.
Two documents that give a project a memory. One holds the current state of play and gets read at the start of every session. The other is a dated diary you only ever add to. Between them, nothing important quietly disappears.
Your portable identity file: role, setup, preferences, and the traps you never want to explain twice. The same file drops into every project.
Rules of engagement for one project — who decides, who executes, investigate before editing, and how work gets handed off.
The project's memory. BANK is the current-state contract every session reads first; NOTES is the dated, append-only log it writes to.
Who I am: role, machines, preferences, the traps I've hit once and never want to re-explain. One portable file, dropped into every project.
How we work here: who decides and who executes, investigate-before-editing, how commands get handed back. The rules of engagement for one project.
How the project remembers itself. BANK is the contract every session reads first; NOTES is the dated, append-only diary it writes to. Together they're the project's memory.
Portable identity master. Role, hardware, constraints, known traps. Facts and pointers only, no procedures.
Per-project operating contract. Decision and execution split, step-0 investigate gate, hand-off format.
State plus journal. BANK is the read-first contract; NOTES is dated and append-only. Never rewrite NOTES.
05THE RITUALS
One word you type at the end of a real working session. It tells the AI to write the day's conclusions into the documents and to say what it thinks is worth keeping. Without it, good decisions die with the conversation.
Look before you touch. Ask the AI to read what is actually there and report back before it changes a single thing. If anything could be deleted, ask for a practice run first.
Start by saying which device you are at — desk computer, laptop, phone. What the AI can actually reach depends on that, and saying it up front stops it suggesting things it has no way to do.
Use two conversations. One thinks the job through and writes clear instructions; the other carries them out. Never let the same one both plan the work and decide it went well.
Chat titles get made from your very first message, so they describe the question you had, not the answer you got. Rename a finished chat after what it produced and you will be able to find it again.
Put a letter at the front of the title: one for still open, another for finished. Then a glance down the list tells you what is done and what is still waiting on you.
When one conversation does work for another, ask it to finish with one short summary box: what happened, what changed, what still needs doing. That box is the only part that survives being copied across. Everything else is quietly lost.
One word at the end of real work. The chat syncs its memory, appends a dated entry to the notes file, and proposes what is worth keeping.
Investigate before editing. It reads what is actually there and reports back before changing anything, and dry-runs anything destructive.
Open with where you are: desk, laptop, phone. Reach depends on the machine, and saying so stops it proposing what it cannot run.
Two chats, not one. One plans and writes the instructions; another executes them. Never let one AI both design and grade its own work.
Titles auto-generate from your first message — they name the question, not the answer. Rename finished chats by what they produced.
O_ for open, X_ for settled. Renaming at the end is your only chance to make a chat findable by its result.
End every handed-off prompt by asking for one short block: status, files changed, verify results, open items, next step. Only that block survives the copy-paste.
One word, said at the end of real work. The AI syncs its memory, appends a dated entry to the notes file, and proposes what's worth keeping. It's how a session's conclusions survive the session.
Investigate before editing — always. The AI reads what's actually there and reports back before it's allowed to change anything. Dry-run before anything destructive.
Open every session with where you are: [desk], [laptop], [phone]. The AI's reach depends on which machine it's connected to — telling it up front stops it proposing things it can't actually do.
Two conversations, not one. A chat session plans and writes precise instructions; a second session (like Claude Code in a terminal) executes them. Never let one AI both design and grade its own work.
Chat titles auto-generate from your first message — they name the question, not the answer. Rename finished chats by what they produced, so future-you can actually find them.
O_ means open, X_ means settled. Chat titles auto-generate from your first message, so renaming at the end is the only chance to make a session findable by what it actually produced.
Every prompt handed to a terminal session ends by asking for one short fenced block: status, files changed, verify results, open items, next step. That block is the only thing that travels back. Long transcripts do not survive copy-paste, and the loss is silent.
Close-of-session trigger: sync memory, append dated NOTES entry, emit retention proposals.
Read-only investigate gate before any write. Dry-run destructive operations.
State the host in line one. Capability follows the host, not the client.
Split planning from execution across sessions. No self-grading.
Titles derive from the opening message. Retitle on close, by artifact produced.
O_ open, X_ settled. Cheap triage across a long backlog.
Hand-offs return one fenced block: status, files changed, verify, open items, next. Transcripts do not survive the copy and the loss is silent.
06THE SYSTEM CHECKS ITSELF
Once a day, something reads through all of the documents and writes a list of things that look wrong: two pages that disagree, a link that goes nowhere, a fact that has quietly stopped being true. It only makes the list. It does not change anything.
You read the list and pick what is worth acting on. The ones you accept get made as ordinary edits, the same careful way as everything else.
A second check compares what the AI said it did against what is really there. Chats will tell you something is finished. Sometimes it is not.
When a job needs a real judgement call on each item, look at them yourself instead of letting the AI guess. A guess that lands in the document you trust most is very hard to spot later. And a check you skipped is not a check that passed.
A scheduled job reads the whole corpus each morning and writes a proposals list: contradictions, pointers that no longer resolve, claims that stopped being true. It never edits anything itself.
Proposals land on a small review page. The accepted ones get applied by an ordinary session, through the same ritual as any other change.
A separate sweep diffs claimed-done against what is actually on disk. Chats assert things shipped; sometimes they did not.
When a batch needs judgement row by row, build a throwaway click-through page instead of guessing. Guessing quietly corrupts the file you trust most, and an unavailable check is not a passed check.
A scheduled pass reads the whole corpus each morning and writes a list of proposals: contradictions, pointers that no longer resolve, claims that stopped being true. It never edits anything itself.
Proposals land on a small review page. Accepted ones get applied by an ordinary session, through the same ritual as any other change.
A separate sweep diffs claimed-done against what is actually on disk. Chats assert things shipped. Sometimes they did not.
When a batch needs judgment row by row, build a throwaway click-through review page instead of guessing. Guessing quietly corrupts the file you trust most. And an unavailable check is not a passed check.
Scheduled read-only sweep over the corpus. Emits proposals — contradictions, dead pointers, stale claims. Zero write authority.
Proposals queue to a review surface. Accepted items apply through the normal session path, never the detector.
Diff asserted state against disk. Treat transcript claims as unverified until reconciled.
Row-level judgement gets a disposable review UI. An unavailable check is not a passed check.
07WHEN THERE IS MORE THAN ONE PROJECT
Give each piece of work a one-page description: what it is, what it touches, and what the others must never do to it. Keep a copy of that page with the other projects, so none of them has to be explained from scratch.
One document sits above all of them and holds only the big picture — what exists and where to find it. Update it when the big picture changes, not on a timetable, and keep the fine detail out of it.
Copies drift out of date without announcing it. Before you trust one, check the date on it. Working confidently from an old copy looks exactly like working correctly, right up until it does not.
Each project keeps a short summary: what it is, what it touches, and what a sibling project must never do to it. Copies live in the siblings, so no chat starts unbriefed.
One account-level file holds orientation facts only, refreshed when an orientation fact changes, with a calendar sweep as the backstop rather than the primary.
Mirrors go stale silently. Check the version line before reasoning from a copy. Reasoning from a mirror that moved on looks exactly like reasoning correctly.
Each project keeps a short summary doc: what it is, what it touches, and what another project must never do to it. Copies live in the sibling projects so no session has to be re-briefed from scratch.
One account-level file holds orientation facts only, refreshed when an orientation fact changes, with a calendar sweep as backstop rather than the primary.
Mirrors go stale silently. Check the version line before reasoning from a copy. Reasoning confidently from a mirror that moved on looks exactly like reasoning correctly, right up until it does not.
Per-project summary: identity, blast radius, cross-project prohibitions. Replicate into siblings.
Account-level file carries orientation depth only. Event-driven refresh, calendar sweep as backstop. Cite the recipe, never the number.
Mirrors drift silently. Verify the version line before reasoning from a copy. Master wins.
08TIPS & TRICKS
- Ask for the answer in a form you can use straight away. You can always ask for the reasoning afterwards.
- Tell it to read your documents before it asks you anything. Then it only asks the one or two questions that genuinely need you.
- Do not take its word for it. If it says it saved something, have it read the file back to you, or go and look yourself.
- If it gets the same thing wrong twice, that is not bad luck — it is a rule you have not written down yet. Write it down.
- Keep the documents short. Facts and pointers, not essays. A long one waters down everything in it.
- Keep exactly one real copy of each document. Everything else is a copy, and when a fact changes you fix the real one first.
- Match the tool to the job. Quick questions do not need the slow careful setting; hard problems do.
- Finish real work by asking what is worth remembering from it — then actually save the answer somewhere.
- Ask for copy-paste-ready output. Explanations on request, not by default.
- Have it check your files before it asks you anything — then it only asks the one or two questions that matter.
- Never accept "done" from the AI's own echo. Have it read the file back, or check yourself.
- Wrong twice the same way is not bad luck, it is a missing rule. Write it into the file.
- Keep the files lean: facts and pointers, not essays. A bloated instruction file dilutes everything in it.
- One canonical copy per file. Uploads and attachments are mirrors — when facts change, fix the master first.
- Match the model to the job: quick questions on the fast one, architecture on the big one.
- End real work with "what is worth remembering from this?" — then actually save the answer.
- Ask for copy-paste-ready output. Explanations on request, not by default.
- Make it check your files before asking you anything — then it only asks the one or two questions that actually matter.
- Never accept "done" from the AI's own echo. Have it read the file back, or check yourself.
- When it's wrong twice the same way, that's not bad luck — that's a missing rule. Write it into the file.
- Keep the files lean: facts and pointers, not essays. A bloated instruction file dilutes everything in it.
- One canonical copy of every file. Uploads and copies are mirrors — when facts change, fix the master first.
- Match the model to the job: quick questions on the fast model, architecture on the big one. Don't burn deep thinking on formatting.
- End real work with "what's worth remembering from this?" — then actually save the answer.
- Default to copy-paste-ready output. Reasoning on request.
- Files before questions. Cap intake at the one or two genuinely blocking unknowns.
- Self-report is not verification. Re-read the artifact.
- The same failure twice is a missing rule, not bad sampling. Encode it.
- Keep masters lean, facts and pointers. Bloat dilutes every line in the file.
- One canonical master per fact. Everything else is a mirror; fix the master first.
- Route by task shape. Reserve extended reasoning for reasoning, not volume.
- Close with an extraction step. Unextracted conclusions are lost at session end.
09STEAL THE TEMPLATES
These are empty versions of the real documents. Fill in the blanks and drop them into whatever AI assistant you use — they are just plain text, so they work anywhere, not only with Claude.
If any of it looks unfamiliar, that is fine. Open a chat, attach the file, and ask it to walk you through what each part is for. That is a perfectly good first use of the whole system.
Blank versions of the real files — fill in the brackets and attach them to your own projects. They are plain text, so any assistant that reads project files can use them, not just Claude.
They were written for public use rather than exported from the live files, so treat them as a starting shape, not a mirror.
These are blank versions of the real files — fill in the brackets and drop them into your own projects. They work with any AI assistant that reads project files, not just Claude.
These templates were written for public use rather than exported from the live files, so treat them as a starting shape, not a mirror.
Blank masters. Fill the brackets, attach per project. Plaintext and assistant-agnostic; authored for publication, not exported from live files — a starting shape, not a mirror.