The first move
A good friend told me recently, face to face, that he had read my article about SEBI, gone as far as buying a Claude Code license, and then stopped, because he did not know what the first move was.
I recognized that state immediately. It was me in March: I understood the second brain concept the same day I met it, and then did nothing with it for two months. The person who taught me needed three or four months to build his first version. I needed six weeks. This guide exists so my friend needs two. Each round is supposed to compress the path for the next one. Here it is, lightly anonymized, essentially as I sent it.
One principle before anything else: AI will not make you faster. The thinking you have already done makes you faster. The tool only writes it down. That is why day zero happens on paper.
A note on the examples: my friend researches local history, a village monograph, heritage buildings, old newspapers in digitized archives. Your domains will differ, but the steps are the same.
Day 0: the macro structure, on paper (2-3 hours, no laptop)
Think hard about ALL your interests, even the ones you will not touch for months. The structure has to be able to receive them later without a reorganization. I had the advantage of having already split my life into a project tool weeks before I built anything. Do it on paper now.
- List everything you care about. For my friend: the monograph, city heritage, his profession, community work, and entities cutting across all of them: buildings, streets, architects, newspapers, people, years. For contrast, my own vault's top level: job search and commercial initiatives, finance, academic work, communities, entities (people, companies, tools), concepts (frameworks and mental models), syntheses, meta. Different life, same shape.
- If you are in a job search, make it a first-class domain. Mine lived in the vault: applications, interview notes, rejection patterns, prep checklists. Few things compound faster, because a job search is exactly what this system eats for breakfast: many scattered interactions over months that your memory quietly drops and your vault does not.
- Pick ONE starting project, the one where you already hold the most material. Everything else gets an empty folder. Empty folders are not mistakes, they are targets. They are your list of what to collect next.
- Decide the small conventions now, because changing them later hurts: kebab-case filenames (
old-train-station.md, notOld Train Station.md) and one single link style between pages, I recommend[text](path/page.md). Write them into the constitution on day one. The constitution is CLAUDE.md, a single file that governs the whole system: you will meet it in a moment.
From my own run: I still have two zones of my vault with different naming conventions and two link styles mixed together. It works, but I am cleaning it up retroactively and it annoys me to this day. Decide once, write it down.
Day 1: install and first contact (1 hour)
- You need a paid Claude account. A free one will not work with Claude Code, and the Pro plan ($20/month) is plenty to start.
- Install Claude Code: the desktop app from Anthropic or, from the terminal,
npm install -g @anthropic-ai/claude-code. Log in with the account that holds your license. And a reflex worth installing on day one: when anything fails during setup, paste the error into Claude and ask, with as much context as you can give, screenshots included. - Important: you do not need to know how to program. Claude Code works on any folder of text files, not just code. A Pro license works in 5-hour windows, so work in focused sessions, not five scattered minutes at a time.
- A warm-up with zero stakes, in an empty folder:
Create a file called test.md with 3 chapter ideas for a local history
monograph. Then tell me exactly which files you created.
The point is simply to see with your own eyes that the agent writes real files to disk and reports what it touched. When it asks for permissions, read what you are approving. Approve narrowly, never "allow all". I granted too much early on and only tightened it after a security audit, weeks later.
Days 1-2: the vault and its constitution
- Create the folder, for example
vault/, open Claude Code inside it and give it this:
Create the structure for a knowledge vault: 1.raw/ for raw sources,
2.wiki/ with subfolders monograph/, heritage/, work/, community/,
entities/, syntheses/, meta/, each domain folder with its own sources/
subfolder, and 3.output/ for finished deliverables. Plus empty
index.md and log.md at the root. Do not write any content yet.
Ideally, mirror the same domain structure inside 1.raw/ and 3.output/ as inside 2.wiki/. The wiki is the most important of the three, but a shared shape keeps everything findable: raw material enters at 1, knowledge lives at 2, finished work leaves at 3.
- Then write CLAUDE.md at the root: the constitution. It is the most important file in the whole system. Claude Code reads it automatically at the start of every session, it is the agent's working memory. Do not write it alone, write it WITH the agent, starting from this:
# Vault · CLAUDE.md
## Identity
You are my knowledge agent. This vault is a personal wiki that YOU
write and maintain. I direct and validate, you execute.
## The iron rule
1.raw/ is immutable: you read from it, you NEVER write to it.
2.wiki/ is entirely yours.
3.output/ holds finished deliverables: write there when I ask for
an export or a draft to send, never ingest from it.
## Structure
- 1.raw/ · raw sources (archive PDFs, photos, notes, exports)
- 2.wiki/monograph/ · the main research project
- 2.wiki/heritage/ · city heritage and architecture
- 2.wiki/work/ · the professional side
- 2.wiki/community/ · civic projects
- 2.wiki/entities/ · buildings, streets, architects, newspapers, people
- 2.wiki/syntheses/ · answers and analyses worth keeping
- 2.wiki/meta/ · decisions about the system itself, retrospectives
- 3.output/ · finished deliverables (chapter drafts, exports,
things I send to other people); not a knowledge source
- index.md · catalog: one line per page, organized by folder
- log.md · chronological journal, append-only, newest on top
## INGEST (when I say "ingest file X")
1. Read the source from 1.raw/
2. Write a source page in 2.wiki/[domain]/sources/[slug].md
3. CRITICAL RULE: every historical fact gets its exact citation
(publication, date, issue, page). No source, mark it explicitly
as "to verify".
4. Create or update every entity page you touched
5. Update index.md and log.md
6. Report the full list of pages created or changed
## Frontmatter
Every new page starts with:
---
type: source | entity | concept | synthesis | meta
description: one sentence
tags: [list]
updated: ISO date
---
## Thresholds
- An entity page only for what recurs across multiple sources.
A single mention stays inline in the source page.
- Binaries (photos, PDFs) stay in 1.raw/; the wiki gets the
transcription and the reference, not a copy.
## QUERY (when I ask a question)
1. Read index.md first, then the relevant pages
2. Answer ONLY from the wiki, linking to pages. Whatever is missing,
say so explicitly and suggest what source would fill the gap.
3. Ask me whether we save the answer into syntheses/
## LINT (on request, or after every ~10 ingests)
Look for: contradictions between pages, entities mentioned without
a page, pages nothing links to, an index out of sync with reality.
Report as a numbered list. FIX NOTHING without my explicit approval.
## Language
Your language of choice. Quotes from sources stay exactly as written.
- Then tune it until it sounds like you:
Read CLAUDE.md and tell me: what is ambiguous, what is missing, what
would you misinterpret? Propose improvements, do not apply them yet.
Days 2-3: the first ingest
This is where the system becomes real. Start with the project you chose, the one with the most material.
- Take one relevant source and save it into
1.raw/archive/with a descriptive name, for examplegazette-1936-06-14-train-station.pdf. The publication-date-subject convention: you will thank me at file fifty. (If your topic is Central European local history, the digitized newspaper archive Arcanum is your best resource.) - Give the agent:
Ingest the file 1.raw/archive/gazette-1936-06-14-train-station.pdf
following the flow in CLAUDE.md. At the end I want the exact list of
pages you touched.
- Check the first page it produces word by word against the source. The whole system is worth exactly as much as its accuracy. When you find an error, do not just fix it, turn it into a rule:
You wrote that the station opened in 1935, but the article says 1936.
Fix the page, and add to CLAUDE.md, under INGEST, the rule that would
have prevented this.
That loop is what makes the system improve: every mistake becomes a line in the constitution.
- Repeat with 2-3 more sources, then ask:
Show me index.md and log.md. Do they match the pages that actually
exist on disk?
I discovered ghost pages and missing index entries on day three. Check from day one, it costs two minutes.
Days 3-7: the rhythm
- A small daily habit beats the marathon: 1-3 sources a day, in 30-60 minute sessions, not one weekend day with twenty.
- After each archive session, ask the vault what it already knows:
What do I know so far about the family that owned the mill? Cite the
pages. What is missing, and what search terms would you try in the
archive to fill the gaps?
The second half of that prompt is the quiet superpower: the agent becomes the one writing your search list, and you do what you do best, find the needle. The right division of labor: you find and save, it processes and connects.
- The same flow carries a job search, if that is your domain: postings, applications, interview notes and rejection emails all become sources, and the vault remembers every interaction long after you stopped counting. For example:
Ingest the notes from today's interview. Update the company's entity
page and the pipeline page. Then tell me: what patterns repeat across
my last five interviews?
- Good answers must not die in the chat:
Save this analysis into 2.wiki/syntheses/ with frontmatter, and update
index.md.
For a book project, these syntheses become chapter drafts directly.
- At around ten ingests, run the first LINT. Read the report, approve selectively ("fix 1, 3 and 4, I will handle 2"):
Run a full LINT following CLAUDE.md. Numbered report, no repairs.
The "aha" moment lands around here: the agent starts connecting sources you found weeks apart, the same building in three newspapers from three different decades.
Days 8-10: git, the safety net and the dual backup
Until now your vault lives on one disk. If the laptop dies, the research dies. Git solves exactly that, and gives a research project something precious on top: the complete history of your work, every version of every page, with its date. You do not need to understand git like a programmer. You need to know what it does for you and let the agent operate it.
- Understand before you configure. The first command is not setup, it is an explanation:
Explain to me, as someone who has never used git: what git is, what
GitHub is, what commit, push and pull mean, and why any of it makes
sense for a research vault. Fifteen lines maximum, no jargon.
- Start with local git. This gives you history on your own machine. If git is not installed yet, the agent will install it for you, just ask:
Initialize git in this vault, with a .gitignore that excludes
auto-generated files. Make the first commit. Do not publish anything
online yet.
- Pick a provider for the cloud copy. My recommendation: GitHub. It is free for private repositories, it is the most beaten path (whatever goes wrong, the agent knows how to fix it), and it plugs into the Claude ecosystem in ways that pay off below. GitLab or Bitbucket are perfectly fine too, but absent a specific reason, take GitHub. Create an account, then a new repository, set to Private. Private is not optional: this is your unpublished research.
- Configure the dual, two-way backup. Laptop and GitHub keep each other current, automatically, every hour:
I created a private GitHub repository called vault. Connect this local
vault to it and upload everything we have. Then set up an automatic
hourly sync: commit locally if there are changes, pull, push. If there
is ever a conflict, stop and tell me, do not resolve it yourself. At
the end, explain in 5 lines what you configured and how I check that
it ran.
What you get: if the laptop disappears, the research exists in full on GitHub. If you edit something on another machine, it flows back at the next sync. And it costs nothing from your Claude quota: the sync is pure git, no AI involved. One more door this opens: with the vault on GitHub, you can run Claude Code remotely from any device at claude.ai/code, selecting your repository. The laptop stays home, the second brain does not.
- Hygiene rules, tell the agent to enforce them and write them into CLAUDE.md:
- Everything on the main branch, always. No parallel branches.
- Auto-generated files are not versioned, only sources and wiki.
- Never passwords, banking data or sensitive personal documents in the vault. What enters git stays in its history practically forever.
- GitHub rejects files over 100 MB. Very heavy scans stay out of the sync (the agent puts them in .gitignore) or get archived separately.
- Do not edit the same file on two devices within the same hour, between syncs.
- The trust exercise. Do it once and you will never fear the system again:
Delete the file test.md, then show me how I recover it from git
history. I want to see with my own eyes that nothing is ever lost.
From my own run: my vault once sat for two days on the wrong branch and the automatic backup was blind, the commits existed on a single disk. And one lint found 4 MB of generated files versioned for nothing. Both rules above come from exactly there.
Days 11-14: the expansion
- Only now the second domain, with 2-3 sources. Watch
entities/start stitching domains together: an architect from the capital can show up in the story of a village train station. That is where the compounding lives. - Institute the decision journal, the rule I lacked for seven weeks: every decision about the system itself (a new folder, a new convention) goes into
2.wiki/meta/decisions.mdwith the date, the reason, and a field "check by [date]: did it work?". Otherwise you accumulate decisions without learning from them. - Close week two with a small retrospective:
Look at log.md over the last two weeks. What patterns do you see?
Where did I lose time? Which CLAUDE.md rule did I break?
- And once these two weeks are behind you, start widening the circle at your own pace: look up what MCP, automations and routines mean, and bring the agent any new idea you would like to try. The automation ban in the next section is about sequencing, not about never.
What not to do in the first month
Every line below is a scar, not a theory.
- Zero automation. No automatic emails, scheduled tasks, integrations. I spent weeks on an automated email pipeline I later switched off almost entirely. Your base system is a folder, Claude Code, and the index/log discipline. That is all.
- Zero extra tools. You do not need Obsidian, Notion, anything. Markdown opens everywhere.
- Do not migrate everything you have. One project, then a second. I once poured 1,735 files in at once and created more triage work than value.
- Do not let the agent make structural decisions alone. You direct, it maintains. Any unapproved "I reorganized your folders" gets reverted.
- Keep infrastructure under control. If more than roughly 20% of your time with the system is about the system (setup, tooling, cosmetics) rather than content, stop and go ingest sources. Mine climbed far above that at one point, and it is the most reliable alarm signal I know.
The shortcuts, in one table
| I learned this in | You have it from |
|---|---|
| Week 1: index and log drift apart on their own | day 1, a rule in CLAUDE.md plus a check at ingest three |
| Week 3: thresholds for entities and binaries | day 1, in the constitution |
| Weeks 3-4: dual backup, local plus GitHub | day 8, with the agent holding your hand |
| Weeks 4-6: premature automation costs weeks | banned for the first month |
| Week 6: one branch only, generated files unversioned | day 8, as hygiene rules |
| Week 7: frontmatter on pages, decisions with an outcome check (borrowed from the midbrain project) | day 1 and day 11 |
That last row makes a bigger point. None of this is static. Seven weeks in, a project I stumbled upon taught me that a decision without a later "did it work?" is just a record, not experience, and my constitution changed the same day. Ideas will keep arriving from everywhere: a report, a product, a conversation with a friend. The system is designed to absorb them, one rule at a time, and yours will end up looking like you, not like mine.
The person who taught me needed months. I needed six weeks. My friend gets this guide so he needs two. If you are where he was last week, license bought, cursor blinking, no first move: this is the first move.
In two weeks, do not tell me how it went. Show me your log.md.
And if you have come this far and it still feels hard, there is one more door: hand Claude this very article.
Here is the structure I sketched for myself: a main folder with job
search, academics and community. I want to replicate what Tudor
describes in this article:
https://tudorcretu.ro/blog/the-first-move/
Help me understand it while we build it.
Question everything until you understand it.
Stick around.
Comments