Building a Second Brain with Claude: How to Create Living Reference Documents

I used to finish a productive conversation with Claude and think "that was useful, I should remember that." Then three weeks later, I'd have the same conversation again because neither of us remembered what we'd figured out.

The problem isn't Claude's memory. It's that insights from conversations evaporate unless you capture them somewhere.

Here's what changed: I started using Claude's Filesystem connector to create markdown files on my computer that Claude can both read and update. Now when we figure something out together, Claude adds it to the relevant reference file. Next conversation, that knowledge is already there.

It's like building a shared notebook that actually gets used.

What's the Filesystem Connector?

Claude can connect to your computer's file system through something called an MCP connector. Once connected, Claude can read files in folders you specify, and—this is the important part—write to them as well.

That means Claude can:

• Read your existing notes and documents

• Create new files based on your conversations

• Update files with new information as you learn things together

You're not copying and pasting between Claude and your notes. Claude works directly with your files.

Why Markdown Files?

Markdown (.md) files are plain text with simple formatting. They work well for this because:

• Claude reads and writes them easily

• You can open them in any text editor

• They're searchable on your computer

• They stay readable even without special software

• Version control (like Git) tracks changes over time

You don't need to learn markdown syntax. Claude handles the formatting. You just need to know that these files exist and what's in them.

The Core Idea: Living Documents

Instead of static notes that sit untouched, you create documents that evolve. Every time you have a conversation with Claude that produces useful insight, you ask Claude to update the relevant file.

Over weeks and months, these files become genuinely valuable references—not because you sat down and wrote documentation, but because you captured real learnings as they happened.

Here's what this looks like in practice.

Example 1: A Client Context File

Say you work with several key clients. Each client has history, preferences, quirks, and context that matters when you're preparing for meetings or drafting communications.

Create a file called client-context.md:

# Client Context

## Acme Corp

**Key contacts**: Sarah Chen (CEO), Marcus Webb (Operations)
**Working with us since**: March 2023
**Communication style**: Sarah prefers brief emails with bullet points. Marcus likes more detail and background.

**Current priorities**:
- Expanding into Queensland market (timeline: Q2 next year)
- Reducing operational costs by 15%

**Things to remember**:
- Sarah's previous company had a bad experience with consultants who over-promised. She values realistic timelines.
- Always cc Marcus on anything operational, even if Sarah requested it.
- They pronounce their company name "ACK-me" not "AK-mee"

**Recent conversations**:
- Nov 2024: Discussed potential workshop on team productivity. Sarah interested but wants to wait until new financial year.

---

## Riverside Group

**Key contacts**: David Liu (Founder)
**Working with us since**: August 2024
**Communication style**: David prefers phone calls over email. If emailing, keep it under 3 paragraphs.

...

How It Evolves

After a client call, you tell Claude:

"I just had a call with Sarah from Acme. She mentioned they've pushed the Queensland expansion to Q3 and they're now also looking at a new CRM system. Can you update the client context file?"

Claude reads the current file, finds the Acme section, and updates it with the new information. Next time you're preparing for an Acme meeting, that context is already there.

You're not maintaining a database. You're just telling Claude what happened, and the documentation updates itself.

Example 2: A Lessons Learned File

This one's simple but surprisingly useful. Every time you learn something worth remembering—from a project, a mistake, a conversation—you capture it.

Create a file called lessons-learned.md:

# Lessons Learned

## Client Work

**Don't send proposals on Fridays**
They sit in inboxes over the weekend and lose momentum. Send Tuesday or Wednesday for best response rates.
*Learned: October 2024*

**Always confirm budget range before scoping**
Spent 4 hours on a detailed proposal for a client whose budget was a third of what the work required. Now I ask about budget in the first conversation.
*Learned: September 2024*

**Workshop groups work best at 8-12 people**
Smaller feels too intimate for some topics. Larger means quieter people don't contribute.
*Learned: August 2024*

---

## Communication

**"What would success look like?" beats "What do you want?"**
The first question gets thoughtful answers. The second gets vague ones.
*Learned: November 2024*

**Read emails once before sending, out loud**
Catches tone issues that silent reading misses. Especially important for difficult conversations.
*Learned: July 2024*

---

## Tools & Systems

**Calendar blocks for deep work need to be 2+ hours**
One-hour blocks get interrupted. Two-hour blocks get protected.
*Learned: October 2024*

How It Evolves

You finish a project and realise something useful:

"We just wrapped up the Harrison project. One thing I learned: when clients say 'we're flexible on timeline', they usually mean the opposite. I should have pinned down specific dates earlier. Can you add that to my lessons learned file under Client Work?"

Claude adds the entry with today's date. Your future self thanks you.

Example 3: A Project Decisions File

For any significant project, tracking why you made certain decisions is invaluable. Not just what you decided, but the reasoning behind it.

Create a file for each major project, like project-atlas-decisions.md:

# Project Atlas - Decision Log

## Scope Decisions

**Excluded mobile app from Phase 1**
*Decision date: 15 November 2024*
*Context*: Client initially wanted mobile and web. Budget only supports one properly.
*Reasoning*: Web covers 80% of their users. Mobile can be Phase 2 once web proves value.
*Agreed with*: Sarah Chen

**Chose staged rollout over big bang**
*Decision date: 18 November 2024*
*Context*: Could launch to all users at once or roll out department by department.
*Reasoning*: Staged approach lets us catch issues early and build internal champions. Slower but lower risk.
*Agreed with*: Full steering committee

---

## Technical Decisions

**Using their existing CRM rather than replacing it**
*Decision date: 20 November 2024*
*Context*: Their CRM is dated but functional. Replacing it would add 3 months and $40k.
*Reasoning*: Integration is messier but keeps project on budget and timeline. Replacement can be a separate project later.
*Agreed with*: Marcus Webb

How It Evolves

During a project meeting, a decision gets made:

"We just decided to delay the training sessions until January because half the team is on leave in December. Can you add that to the Atlas decisions file? The reasoning is that running training with only half the team means we'd have to do it twice."

Six months later, when someone asks "why did we do training so late?", the answer is documented with the original context.

Setting This Up

Step 1: Create a Folder

Create a folder on your computer for these reference files. Something like Claude References or Working Notes. Keep it simple.

Step 2: Connect Claude

In Claude, enable the Filesystem connector and point it to your folder. Claude can now read and write files in that location.

Step 3: Start with One File

Don't try to create a complete system upfront. Start with one file that addresses an immediate need. Maybe it's client context, maybe it's a project log, maybe it's just a scratchpad.

Step 4: Build the Habit

The system only works if you actually use it. After productive conversations, ask Claude to capture what's worth keeping. After meetings, ask Claude to update the relevant context. It takes 30 seconds and compounds over time.

What Makes This Work

Claude does the writing. You don't need to context-switch into "documentation mode." You just tell Claude what happened in conversation, and it updates the files.

Files stay on your computer. This isn't cloud storage you might lose access to. These are your files, in your folders, backed up however you normally back things up.

Small updates beat big documentation projects. You're never sitting down to "write documentation." You're just capturing useful things as they happen, a few sentences at a time.

Context carries forward. When Claude reads these files at the start of a conversation, it already knows your client history, your past decisions, your lessons learned. You skip the re-explanation.

Common Questions

How many files should I create? Start with one or two. Add more only when you have a clear need. Three to five files covering different aspects of your work is usually plenty.

What if the files get too long? Split them. If your client context file has 50 clients, maybe it becomes one file per major client. Claude handles multiple files fine.

Can I edit the files myself? Absolutely. They're just text files. Edit them in any text editor, reorganise sections, delete outdated entries. Claude will read whatever's there next time.

What if Claude updates something incorrectly? Review what Claude writes, especially early on. If something's wrong, correct it directly in the file or ask Claude to fix it. The files are always under your control.

Getting Started

Pick one type of information you find yourself re-explaining to Claude or wishing you'd written down:

• Client background and preferences

• Project decisions and reasoning

• Lessons learned from experience

• Meeting notes and action items

• Standard processes you follow

Create a single markdown file for it. Next time that topic comes up in conversation, ask Claude to add the new information to your file.

Do that consistently for a month. You'll have a reference document that's actually useful—built from real work, not theoretical documentation.

The best knowledge base is the one that gets updated. Making Claude the author means it actually happens.

The Filesystem connector is part of Claude's MCP (Model Context Protocol) integrations. You can enable it in Claude's settings under Connectors. You choose which folders Claude can access—it only sees what you explicitly allow.