For approved readers
Wrong password.
For a friend
Obsidian and Claude, from an empty folder to a working system.
Francisco Lorca · September 2026
This page is behind a password, so Claude cannot open the link itself. Save it first (in your browser, File → Save Page As, or print it to PDF). Then start a conversation, attach the file, and say:
"Read this guide. Walk me through it one section at a time, do the mechanical work for me as we go, and stop after each section until I say continue. Ask me anything you need rather than assuming."
That is how I would use it. You can read it front to back first if you want to, but you do not need to.
01
They are all reversible, so you can decide them quickly, but do decide them now rather than halfway through. Each one sets the shape of everything after it.
Claude Code, or Cowork
Claude Code runs in the terminal and reads and writes files on your machine directly. Cowork is Claude in the browser and the desktop app, working through connectors instead. You will end up with both, with Claude Code doing the work and Cowork handling whatever is open in front of you. Start with whichever feels safer, since the folder underneath is the same.
Surface
Plain files you own
Markdown files in a folder. Markdown is plain text with a few marks for headings and links, so any program can open it. An app's own database cannot be read that way. I keep everything in markdown so that every version of Claude reads the same thing, and so that I still have it all if I stop using these tools.
Format
The commonest mistake
Resist the urge to split knowledge over a notes app, a drive, and a wiki. Keep it to one folder. Cloud sync sits underneath it and does nothing else, and it is not a second place to put things. Anything kept in two places will disagree with itself, and then you stop trusting either copy.
Architecture
Obsidian is a good default for the second decision. It is a viewer over a folder of files and it stores nothing of its own. If you delete Obsidian tomorrow, every file is still there and still readable.
02
A vault is just a folder. Obsidian gives you a way to read and link it, Claude reads the same files off disk, and nothing is stored anywhere else.
Cloud storage lies to you about what is on your machine. iCloud, Dropbox and OneDrive all default to keeping files "in the cloud" and streaming them down when you double-click. Finder shows you a full folder while the disk holds nothing but placeholders. Obsidian handles that but Claude does not, because it reads the disk. A streamed file reads as missing or empty, and you get confident answers built on nothing.
Turn streaming off for the vault before you put anything in it. On a Mac: System Settings → your Apple Account → iCloud → iCloud Drive, and switch off Optimise Mac Storage. Then right-click the vault folder in Finder and choose Keep Downloaded. Dropbox calls the same setting "make available offline"; OneDrive calls it "always keep on this device". Do it on every machine, not just the main one.
Numbered folders so they sort in a deliberate order rather than alphabetically. This is the shape mine has settled into since March 2026:
"Create this folder structure in my vault, with a one-line README in each folder saying what belongs there. Do not create anything else yet."
Empty folders are fine. They are a set of decisions about where things go, made once, so you never have to make them again mid-task.
03
There are several ways to talk to Claude and they should all read the same vault. One of them runs the system and the others are specialists.
| Way in | What it does | What it should not do |
|---|---|---|
| Terminal | Reads and writes files directly, runs the system end to end, and is the only one allowed to edit your rules. | Nothing. This is the one that does the work. |
| Cowork | Claude in the browser and the desktop app. Drafting, quick questions, editing an open Word or PowerPoint file, working from a phone. Section 04. | Editing the rules folder. It proposes changes as dated notes for the terminal to review and apply. |
| Scheduled runs | Anything that should happen without you. Mine reads my inboxes every morning. | Anything it cannot undo. Give it read-only permissions and let it hand you drafts. |
| Another vendor | Optional, and worth doing once the vault is real. I point OpenAI's Codex at the same folder, mainly so that I can talk to it out loud while I work. It also gives me a view that is not Claude's. | Reading everything. Mine boots from a trimmed profile and never opens the memory folder. |
"Here is my vault folder. Set yourself up to read it at the start of every session, and tell me exactly which file you will read first and where it lives."
Test it before moving on: start a fresh session and ask a question only the vault could answer. If it answers from the file, the wiring is right.
04
Cowork is Claude in the browser and in the desktop app. The terminal runs the system, so it is tempting to skip this one, but Cowork does things the terminal cannot and you will hit the first of them inside a week.
The one you will hit first
Editing a Word, Excel or PowerPoint file that is open in front of you, live, while you watch. Writing to that file from the terminal instead gets silently overwritten the next time the app saves. I keep the second surface for this alone.
Live editing
Connectors
Email, calendar and cloud drive attach here as permissions you grant once. This is how Claude comes to know what is in your inbox and what your week looks like.
Reach
Phone and browser
The same setup, on any machine, with no terminal. Useful far more often than it sounds, because most of what I ask for in a day is a question rather than a build.
Anywhere
The point is that it reads the same folder, so nothing has to be explained twice.
"Write me the shortest possible instruction to paste into my settings here so that you boot from my vault's entry-point file and follow the same rules as my terminal sessions. Then confirm what you can and cannot reach from this surface."
Cowork also takes skills (small instruction modules that fire on a kind of task rather than on a keyword). Mine cover drafting an email in my voice, building a document on my template, and building a deck. Add them only once you have the voice files from section 07. Before that there is nothing for them to apply.
| The task | Surface | Why |
|---|---|---|
| Anything with rules, files or a project attached | Terminal | The default. It sees everything and it is the only one that can change the system. |
| A document open in front of you | Cowork | Live edits in the running app. A disk write behind an open file gets clobbered. |
| Away from the machine | Cowork | Same vault, no terminal needed. |
| A quick question not worth a session | Cowork | Not everything deserves the ceremony of a logged session. |
Both surfaces read the same vault, and the split only holds up because the second one proposes rather than edits.
05
This is the core of the whole thing. Every session begins by reading them, in one batch, before anything else happens.
| File | What goes in it | How to write it |
|---|---|---|
| The entry point | What Claude is for, and an instruction to read the next two files together before responding. | Short. Mine is under 40 lines and it points at things rather than explaining them. |
| About me | Career, current ventures, who you work with and in what register, languages, what you are focused on this quarter. | Do not write this yourself. Have Claude interview you and draft it. |
| My rules | How to work. File paths, what needs approval, output style, hard stops. | Keep it short at the start. Mine began with five rules and grew on its own (section 12). |
"Interview me to write my about-me file. Ask one question at a time, and push back when an answer is vague or when it contradicts something I told you earlier."
"Now draft my rules file from what you have learned about how I actually work in this conversation, not from best practice."
The interview matters more than it sounds. Writing about yourself from a blank page produces a CV, whereas being asked questions gets at the things you would never have thought to write down, and those are the ones that make the output sound like you.
One batched read at the start of every session: entry point, about me, rules. Everything else loads only when a task calls for it.
06
I got this one wrong from March until the end of July 2026. My configuration told Claude who I am and what to do, and it never once said what it was there to achieve. A system made only of rules produces obedience, which is not what I need from it.
The harder half is disagreement. I did not want to be argued with about everything, and I did not want a second personality to manage. What worked was escalating levels, where the honesty stays constant across all of them and only the amount of friction changes.
Always on
If Claude sees something that changes what I should do, it says so in one line and carries on with the job. I set the bar so that it can be checked. Would this change my decision? Whether Claude would have done it differently does not count.
Unprompted
When I want the argument
It stops executing and we work the problem instead. I set it up to argue the framing and tell me what I am missing rather than agree. Normal again on the next task.
On demand
On anything expensive
Legal, tax, valuation, structuring. Separate reviewers go looking for the errors rather than confirming the answer, and I get told what they found rather than handed a clean draft.
Automatic
A personality paragraph ("a sharp, incisive strategic partner") reads well and arbitrates nothing. "Adviser, not executor" was worse. It is simply false: I ask for execution constantly. A line that fails on its face teaches Claude to discount everything around it. A trigger phrase on its own also failed, because the moment I most need challenge is when I am moving fast and confident, and that is exactly when I would never think to ask for it.
I would write this one early. It turned out to be the highest-return page in the whole setup and I wrote it last.
07
Generic AI prose is the thing that makes people abandon these systems. Asking for a better tone in a prompt does not fix it. What works is a file per format, extracted from things you actually wrote.
"Read these documents. Check the author on each one first and drop anything I did not write myself. Then write a voice file that would let you reproduce how I write, including the things I avoid. Be specific enough that another person could follow it. Then show me the three patterns you were least sure about."
I keep seven files and only load the one the task needs, and corrections go into the file rather than only into the draft. Mine were rebuilt from my own documents in August 2026, and the email one is still waiting its turn.
08
Pick something live and slightly messy. The aim is not to finish it but to establish the shape that every future project copies.
| Artefact | What it is | The discipline |
|---|---|---|
| State file | A short snapshot: where this stands, what is open, what is next. | Stays slim. Always current. Detail moves out to the log. |
| Log | Append-only record of what happened. Dated, newest at top, a few sentences each. | Never edited. Only added to. Write the entry when the thing happens, rather than at the end of the session. I changed this in September: the state had collected somewhere only one of my surfaces could write, so opening a project anywhere else meant going to fetch it first. |
| Decisions | One file per decision worth defending: context, alternatives you rejected and why, consequences. | Frozen once accepted. Reversing it creates a new one. |
| Outputs | Drafts in current. Signed-off in sent. Replaced versions in superseded. | A state machine on documents. Nothing is ever deleted. |
The distinction that took me longest: a log entry records something that happened; a decision record captures something you decided, with the alternatives. Both can come out of the same session. If you cannot tell which one you are writing, you are writing a log entry.
"Create a project folder for [project] in this shape. Then interview me to write the state file (status, open items, next priorities). Ask about what is blocked and why, not just what is happening."
I use the same artefacts on every project with no exceptions, and that is what lets Claude open any project cold and be useful in one read.
09
Everything so far describes what Claude knows at the start of a session. This section is how it keeps what it learns by the end of one. Most setups get it wrong by making it one enormous file.
Mine holds a few hundred files behind one index. The index is the only part loaded every time.
10
Once you have done the same multi-step thing three times, write it down as a command Claude can run by name. Mine cover processing call transcripts, running a quarterly review pack, and closing a session.
"Walk me through what I did the last time I ran [workflow], one step at a time. Then write it as a command you could follow without me, and flag every step where you would need my approval."
A dozen of these run my week. Each one started as something I did by hand and got tired of explaining.
11
This is the command that matters most, because it is what makes the next session cheap. Without it everything you worked out today is gone tomorrow. It sorts into tracks by how much of it needs me.
Done without asking
Housekeeping you never want to be consulted about: drafts filed, log entries written, project state updated, new memories saved, follow-up tasks created.
Automatic
One question, answered in chat
Anything needing your say-so: filing a document as final, a new decision record, a rule earning its place. It all arrives as a single numbered question. You answer by number, or "all".
By approval
Never done silently
Sending anything. Deleting anything permanently. Sharing externally. Investor, legal or compliance material. Financial figures and legal terms in a deliverable.
Explicit only
I end a session by typing "wrap", and nothing on the red-line track moves without me.
12
The instinct is to sit down and write a comprehensive rulebook. Do not do that. Rules written in advance are guesses, and a file full of guesses is one Claude learns to read loosely.
Since March 2026 the queue has collected 231 active candidates and the rules file is 323 lines. The overwhelming majority of things that looked like rules never became rules.
The system grew by use rather than by design, and so did the trust. The list of things Claude may do without asking got there the same way.
13
This is not the order I built it in. I am fairly sure it is the order that would have got me here faster.
DAY ONE
Vault and the boot files
Folder skeleton, the entry point, about-me by interview, five rules. It works from here and is not finished.
DAY ONE
Say what it's for
Purpose, and when it should push back. Twenty minutes. The thing I did last and should have done first.
WEEK ONE
Voice, then one project
One voice file from things you actually wrote. One live project in the standard shape. Nothing else.
WEEK TWO
Session close
The wrap command and the memory index. This is where sessions start compounding instead of resetting.
ONGOING
Everything else
Commands, connected apps, scheduled runs, the research library. All of it earned its way in.
A weekend gets it working and a month gets it genuinely useful. None of that compounding starts until you are ending sessions with the wrap.
14
If you want to start now rather than read this twice, paste this into a fresh conversation with the vault folder in front of you.
"I want to build a personal operating system in a folder of markdown files that you read at the start of every session. Do not build it all at once and do not write anything until I approve the plan.
Start by interviewing me, one question at a time, about who I am, what I am working on, and how I like to work. Push back when an answer is vague. Then propose: a folder structure, an entry-point file stating what you are for and when you should disagree with me, an about-me file, and a rules file with no more than five rules in it.
Write only what is true today. If I describe a discipline I do not actually have, say so rather than writing it down. And tell me which of your proposals you are least confident about."
The last line is the one that matters. I ask for it because a setup that only ever agrees with me is an expensive way of talking to myself.
Everything on this page came out of getting it wrong first. None of it had to be designed up front. It just had to be ended properly, session after session.