For approved readers

How I work with Claude

For a friend

How to set it up

Obsidian and Claude, from an empty folder to a working system.


Francisco Lorca · August 2026

What this is The other page describes what I ended up with. This one is how to build it. It assumes you have never opened Obsidian and have never used a terminal. A weekend gets you a working system; the parts that make it good arrive over months, because they come from use rather than design. Nothing here needs code — the whole method is to have Claude do the mechanical work and to check it.
Don't read this — hand it to Claude

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 the intended way to use it. Reading it front to back first is optional.

01

Three decisions before you install anything

All three are reversible, so decide quickly. But decide, because each one determines the shape of everything after it.

1

Which Claude does the work

Claude Code, or Cowork

Claude Code runs in the terminal and reads and writes files on your machine directly. Cowork — Claude in the browser and the desktop app — works through connectors instead. You will end up with both: Claude Code does the work, Cowork handles whatever is open in front of you. Start with whichever feels safer; the vault underneath is the same.

Surface

2

Where the knowledge lives

Plain files you own

Markdown files in a folder, not notes inside an app's database. That single choice is what lets every version of Claude read the same thing, and what means you keep everything if you stop using any of these tools.

Format

3

One folder, not three

The commonest mistake

Resist the urge to split knowledge across a notes app, a drive, and a wiki. One vault. Cloud sync sits underneath it as plumbing, not as a second home. Overlap is where the system quietly dies.

Architecture

Obsidian is a good default for the second decision — it is a viewer over a folder of markdown files, not a database. If you delete Obsidian tomorrow, every file is still there and still readable.

02

Build the vault

A vault is just a folder. Obsidian gives you a way to read and link it; Claude reads the same files off disk. Nothing is stored anywhere else.

  1. Install Obsidian and choose "Create new vault" rather than opening an existing folder.
  2. Put it in your cloud folder — iCloud Drive, Dropbox, whichever you already use. This is what gets you the same vault on a second machine. It is a sync layer, not a second system.
  3. Name it something neutral. It will outlive whatever you think it is for today.
  4. Make the whole vault download and stay downloaded. Not optional — see the warning below.
  5. Verify it exists on disk outside Obsidian — open the folder in Finder or Explorer and confirm you can see the files. If you cannot see them there, Claude cannot either.
The one that will actually bite you

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 — so Finder shows you a full folder while the disk holds nothing but placeholders. Obsidian handles that; Claude does not. 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.

The skeleton

Numbered folders so they sort in a deliberate order rather than alphabetically. This is the shape mine has settled into after four months:

00 Inbox/ anything unprocessed — cleared, not accumulated 10 System/ the rules. who you are, how to work, voice, memory 11 Templates/ note templates so nothing is composed from scratch 20 Projects/ one folder per active project, all the same shape 30 Areas/ ongoing responsibilities that never "finish" 40 Session Logs/ what you and Claude did, session by session 50 Archive/ finished work. not deleted, just out of the way 60 Resources/ the research library 80 People/ a note per person you deal with repeatedly 90 Sandbox/ experiments that have not earned a project yet
Ask Claude to do it

"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

Point Claude at the folder

There are several ways to talk to Claude and they should all read the same vault. One of them does the heavy lifting; the others are specialists.

Way inWhat it doesWhat it should not do
TerminalReads 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.
CoworkClaude 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 runsAnything that should happen without you — mine reads my inboxes five times a day.Anything it cannot undo. Give it read-only permissions and let it hand you drafts.
Why one writer Two surfaces both editing your rules will eventually disagree with each other, and you will not notice until something behaves strangely a week later. Pick the one that can see the whole vault and give it the pen. Everything else proposes.
Ask Claude to do it

"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

Add the second surface — Cowork

Cowork is Claude in the browser and in the desktop app. The terminal does the heavy work, so it is tempting to skip this. Do not: there are three things Cowork does that the terminal cannot, and one of them you will hit in the first week.

1

Documents that are open

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. This alone justifies the second surface.

Live editing

2

Your other apps

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

3

Away from the desk

Phone and browser

The same setup, on any machine, with no terminal. Useful far more often than it sounds — most of what I ask for in a day is a question, not a build.

Anywhere

Wiring it to the same vault

The point is that it reads the same folder, so nothing has to be explained twice. Two steps.

  1. Give it access to the vault folder on your machine, the same one Obsidian opens.
  2. Put a three-line instruction in its settings pointing at the same entry-point file the terminal reads. Not a copy of your rules — a pointer. Two copies of your rules will drift apart, and you will not notice which one is stale until something behaves oddly.
Ask Claude to do it

"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."

Skills

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. They are worth adding only once you have the voice files from section 07; before that there is nothing for them to apply.

The one hard rule Cowork never edits your rules folder. When a Cowork session produces something that belongs in the system — a new rule, a correction, something worth remembering — it writes a dated note into your inbox folder saying what it proposes and why. The terminal picks that up and decides. One writer to canon; everything else proposes. Without this, two surfaces edit the same rules from different sessions and quietly disagree.

Which one to reach for

The taskSurfaceWhy
Anything with rules, files or a project attachedTerminalThe default. It sees everything and it is the only one that can change the system.
A document open in front of youCoworkLive edits in the running app. A disk write behind an open file gets clobbered.
Away from the machineCoworkSame vault, no terminal needed.
A quick question not worth a sessionCoworkNot everything deserves the ceremony of a logged session.

Two surfaces, one vault, one writer. The split only works because the second one proposes instead of editing.

05

The three files that boot every session

This is the core of the whole thing, and it is three files. Every session begins by reading them, in one batch, before anything else happens.

FileWhat goes in itHow to write it
The entry pointWhat Claude is for, and an instruction to read the next two files together before responding.Short. Mine is under 40 lines. It points; it does not explain.
About meCareer, 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 rulesHow to work. File paths, what needs approval, output style, hard stops.Start with five rules. It grows on its own — see section 12.
Ask Claude to do it

"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. Being asked produces the things you would never have thought to write down, which are exactly the things that make the output sound like you.

Keep it honest Write what is true today, not what you intend. A rules file describing a discipline you do not have teaches Claude to discount all of it. Aspirations go in as aspirations, or they stay out.

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

Say what it's for — and when it should argue

I got this one wrong for four months. My configuration told Claude who I am and what to do, and never once said what it was there to achieve. A system made only of rules produces obedience, and obedience is not what I need from it.

The line my setup now reads first Claude is here to make me faster and sharper — to process more than I can alone, hold context I can't carry, and protect my attention for the decisions only I can make.

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 three escalating levels with honesty constant across all of them, and only the friction varying.

1

It speaks up

Always on

If Claude sees something that changes what I should do, it says so in one line and carries on with the job. The bar is deliberately checkable: would this change my decision — not would Claude have done it differently.

Unprompted

2

"Help me think"

Three words that flip it

Stop executing, argue the framing properly, find what I am missing. Agreeing with me is explicitly not the goal. It goes back to normal on the next task.

On demand

3

It attacks its own work

On anything expensive

Legal, tax, valuation, structuring — separate reviewers go looking for the errors rather than confirming the answer, and I am told what they found instead of handed a clean draft.

Automatic

What I tried first and threw away

A personality paragraph — "a sharp, incisive strategic partner" — reads well and arbitrates nothing. "Adviser, not executor" was worse, because it is simply false: I ask for execution constantly, and a line that fails on its face teaches Claude to discount everything around it. A trigger phrase on its own also failed, for the reason that matters most: 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.

Write this early. It is the single highest-return page in the whole setup, and I wrote it last.

07

Teach it your voice

Generic AI prose is the thing that makes people abandon these systems. The fix is not a prompt asking for a better tone — it is a file per format, extracted from things you actually wrote.

  1. Gather twenty real emails you sent — a spread of registers, from a lawyer to a close partner. Real ones, not ones you are proud of.
  2. Have Claude extract the patterns, not summarise them: sentence length, how you open and close, what you never say, how formality shifts with the recipient.
  3. Make one file per format and language. Email, memo, presentation — mine exist in English and Spanish, so six files. Only the one matching the task ever gets loaded.
  4. Test it against a real task, then correct the file rather than the output. Every correction you make to a draft instead of to the file is a correction you will make again.
Ask Claude to do it

"Read these twenty emails. 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."

The rule I had to tighten Voice applies to everything written in your name — not just the external, investor-facing work. I exempted internal notes at first, and two-line messages to business partners came back reading, in my own words, like AI slop. Now a message to a partner loads the voice file the same as a board paper.

Six files. One loaded per task. Corrections go into the file, never just into the draft.

08

Your first project — one shape, every time

Pick something live and slightly messy. The point of the first project is not to finish it; it is to establish the shape that every future project copies.

ArtefactWhat it isThe discipline
State fileA short snapshot: where this stands, what is open, what is next.Stays slim. Always current. Detail moves out to the log.
LogAppend-only record of what happened — dated, newest at top, a few sentences each.Never edited. Only added to.
DecisionsOne file per decision worth defending: context, alternatives you rejected and why, consequences.Frozen once accepted. Reversing it creates a new one.
OutputsDrafts 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.

Ask Claude to do it

"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."

Same four artefacts, every project, no exceptions. That sameness is what lets Claude open any project cold and be useful in one read.

09

Memory that survives the session

Everything so far describes what Claude knows at the start. This is how it keeps what it learns at the end — and it is the part most setups get wrong by making it one enormous file.

How it works

  • One file per fact. Small, named, findable.
  • Four kinds: who you are, feedback you have given, live projects, and pointers to things outside the vault.
  • Every file gets a one-line entry in an index.
  • Only the index is read at every session — individual files open when a task makes them relevant.
  • Files link to each other, so pulling one brings its neighbours.

What earns a memory

  1. A correction you had to make twice.
  2. A constraint that is not visible in any file — why something is the way it is.
  3. A tool's real limits, learned the hard way.
  4. Not: anything the files already say. That is duplication, and it goes stale silently.
The failure mode A memory records what was true when it was written. Mine now number in the hundreds, and the ones that cause trouble are the ones describing a workflow that has since been automated, or a file that has since moved. Anything a memory asserts about your setup gets verified before it is acted on.

Mine holds a few hundred files behind one index. The index is the only part loaded every time.

10

Turn a repeated workflow into a command

Once you have done the same multi-step thing three times, write it down as a playbook Claude can run by name. Mine cover things like processing call transcripts, running a quarterly review pack, and closing a session.

  1. Pick a workflow you have already done manually at least twice. Never write a playbook for something hypothetical — it will be wrong in ways you cannot see.
  2. Have Claude interview you through the last time you did it, step by step, and draft the playbook from your answers.
  3. Say inside the playbook what it may do without asking, and what always needs you. That list is per-playbook, and it should start almost empty.
  4. Run it once and watch. It will be wrong somewhere. Fix the file, not the run.
Ask Claude to do it

"Walk me through what I did the last time I ran [workflow], one step at a time. Then write it as a playbook 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

How a session should end

This is the playbook that matters most, because it is what makes the next session cheap. Without it, everything you worked out today is gone tomorrow. It runs on three tracks at three different speeds.

1

Silent

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

2

Propose

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

3

Red lines

Never silent, ever

Sending anything. Deleting anything permanently. Sharing externally. Investor, legal or compliance material. Financial figures and legal terms in a deliverable.

Explicit only

A small ordering lesson that saved real time For months the wrap wrote the log first with everything parked under a "proposed" heading, then rewrote it once I had answered — so every session composed its log twice. Now the single question comes first and the log is written once, already final. I found that by measuring where the time actually went, after two more elaborate fixes I had assumed were the answer turned out to be wrong.

One word ends a session — "wrap". Three tracks run underneath it. Nothing on the third track ever moves without me.

12

Let the rules earn their place

The instinct is to sit down and write a comprehensive rulebook. Do not. Rules written in advance are guesses, and a file full of guesses is one Claude learns to read loosely.

How a rule gets in

  • Something goes slightly wrong, or right in a way worth repeating.
  • It gets logged as a candidate with a counter at one.
  • It sits there. Most never move again.
  • At three occurrences in real work, it is proposed for promotion.
  • Candidates that go ninety days without converging are retired — kept, as evidence of restraint.

The exception

  1. Red lines skip the queue entirely.
  2. One violation of "never send without asking" is one too many.
  3. If the cost of a single failure is high, write the rule after the first occurrence.
  4. Everything else waits for evidence.

Four months in, I have 137 candidates sitting in the queue and a rules file of about 290 lines. That ratio is the point: the overwhelming majority of things that looked like rules never became rules.

The system grows by use, not by design. So does the trust — the list of things Claude may do without asking got there the same way.

13

The order I would build it in

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 three files

Folder skeleton, the entry point, about-me by interview, five rules. Working, not finished.

DAY ONE

Say what it's for

Purpose and the three levels of challenge. Twenty minutes. The thing I did last and should have done first.

WEEK ONE

Voice, then one project

One voice file from real emails. One live project in the standard shape. Nothing else.

WEEK TWO

Session close

The wrap playbook 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.

What actually goes wrong Not the setup — the abandonment. The system dies when you do the work outside it "just this once", because that session leaves no trace and the next one starts cold. The discipline that matters is not writing better rules. It is ending sessions properly.

A weekend to working. A month to genuinely useful. The compounding does not start until the wrap does.

14

The brief to hand Claude

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.

Copy this

"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.

Two constraints. 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. A setup that only ever agrees with you is a more expensive way of talking to yourself.

Everything on this page came out of getting it wrong first. None of it needed to be designed up front — only ended properly, session after session.