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

Here’s a pattern I see constantly with people using AI tools: they have the same great conversation five times. They explain their client situation to Claude, get useful advice, close the tab. Next week, same client, same context, they explain it all over again. The knowledge generated in that conversation just evaporates.

It doesn’t have to work this way.

Claude’s Filesystem connector lets you create and maintain Markdown files that persist between conversations. These aren’t just notes - they’re living reference documents that Claude can read, update, and reference automatically. Think of them as an external brain that gets smarter the more you use it.

The Core Concept

A reference document is a structured Markdown file that contains knowledge you want Claude to have access to across conversations. Unlike a Skill (which tells Claude how to do something), a reference document tells Claude what it needs to know.

The key distinction: conversations are ephemeral. Reference documents are persistent. When you learn something important about a client, discover a useful approach, or make a strategic decision, capturing it in a reference document means you never have to re-explain it.

Claude can both read from these documents (to use existing knowledge) and write to them (to add new information as you work). Over time, your reference documents become a comprehensive, always-current knowledge base that makes every conversation more productive than the last.

Three Examples That Change How You Work

1. The Client Context File

This is the single most useful reference document for anyone in professional services.

Create a Markdown file for each major client or project. Include:

# Client: Meridian Property Group

## Key People
- Sarah Chen - CEO, decision-maker, prefers email over phone
- David Park - IT Manager, our main technical contact
- Lisa Wang - Operations Manager, end user champion

## Business Context
- Mid-size commercial property management, 47 properties across SEQ
- Currently using a mix of spreadsheets and an aging FileMaker database
- Pain point: maintenance request tracking takes 3-4 hours per week manually

## Project History
- 2025-06: Initial discovery session - mapped current maintenance workflow
- 2025-07: Delivered Power Apps prototype for maintenance tracking
- 2025-08: Go-live with Phase 1, 12 users onboarded
- 2025-10: Phase 2 scoping - they want to add contractor management

## Communication Preferences
- Sarah responds fastest to short emails with clear asks
- David prefers technical detail and wants to understand the "why"
- Monthly check-in calls on first Tuesday, 2pm

## Open Items
- Contractor portal proposal due by end of November
- Sarah mentioned budget review in January - may affect Phase 3 timing

Now when you ask Claude to draft an email to Sarah about the contractor portal, it already knows who Sarah is, what the project history looks like, and how she prefers to communicate. You don’t explain any of this - Claude reads the document and applies the context automatically.

After each interaction with the client, you (or Claude) update the document. The knowledge accumulates. Six months in, your client context file is a comprehensive history that no human memory could reliably maintain.

2. The Lessons Learned File

Every professional accumulates hard-won knowledge over their career. Most of it lives in their head, inaccessible to tools and team members. A lessons learned reference document changes that.

# Lessons Learned - Power Platform Projects

## Discovery & Scoping
- Always ask about data volumes early - Power Apps performance degrades noticeably above 2,000 rows in a gallery
- If the client says "we just need a simple form," budget for at least 3x the complexity they described
- Get the IT team involved in the first meeting, not the third - permissions and licensing delays kill timelines

## Development
- Build the approval workflow first, even if it seems like a secondary feature - it always becomes critical
- Test with real data from day one, not dummy data - edge cases only appear with real records
- Canvas apps: set up a component library before building screens - retrofitting consistency is painful

## Deployment & Adoption
- Schedule training sessions within 48 hours of go-live - longer gaps mean people revert to old processes
- Create a "quick reference card" - a one-pager with screenshots for the 5 most common tasks
- Assign an internal champion before launch, not after - they need to be part of the testing phase

## Pricing & Proposals
- Fixed price works for well-defined Phase 1 projects - switch to time & materials for ongoing phases
- Always include a "documentation and handover" line item - clients expect it even if they don't ask for it

Every time you finish a project, have a difficult conversation, or discover something the hard way, add it to the file. Claude references this knowledge in future work - suggesting approaches based on your actual experience, not generic best practices.

3. The Project Decisions File

For any significant project, there are dozens of decisions made along the way. Why did we choose this technology? Why did we structure the data this way? Why didn’t we include that feature?

Six months later, nobody remembers. A decisions file solves this.

# Project Decisions - Meridian Maintenance App

## Architecture
- **Decision:** Canvas App + Dataverse (not Model-Driven App)
  - **Date:** 2025-06-15
  - **Rationale:** End users are non-technical, need simple mobile interface. Model-driven would be faster to build but harder for field staff to use.
  - **Trade-off:** More development effort upfront, but higher adoption expected.

## Data Model
- **Decision:** Single "Request" table with status field (not separate tables per status)
  - **Date:** 2025-06-20
  - **Rationale:** Simpler to query and report on. Status-based tables would create data synchronisation issues.

## Notifications
- **Decision:** Power Automate email notifications (not push notifications)
  - **Date:** 2025-07-03
  - **Rationale:** Field staff don't always have the app open. Email is checked more reliably. Push notifications can be added in Phase 2 if requested.
  - **Note:** Sarah specifically asked for email. Revisit if adoption data shows emails are being missed.

When someone asks “why did we do it this way?” - the answer is documented. When you’re scoping Phase 2, Claude can reference the original decisions and flag any that might need revisiting based on what you’ve learned since.

Setting It Up

Getting started with reference documents is straightforward.

Choose a location. Create a folder on your local machine where your reference documents will live. Something like ~/Documents/claude-reference/ works fine. Keep the structure simple - one file per client, one file per knowledge domain.

Use Markdown. Plain Markdown files (.md) are the right format. They’re readable by both humans and Claude, they version well with Git if you want history, and they don’t require any special tools to edit.

Connect Claude. Enable the Filesystem connector in Claude and point it at your reference folder. Claude can then read and update these files across conversations.

Start with one document. Don’t try to build your entire knowledge base on day one. Pick your most active client or your most common type of work. Create one reference document. Use it for a week. Add to it as you work.

What Makes It Work

Structure matters. Use clear headings, consistent formatting, and logical grouping. Claude parses structured documents much more effectively than stream-of-consciousness notes.

Keep it current. A reference document that’s three months out of date is worse than no document at all - it gives Claude confident but wrong context. Build updating into your workflow. After a client meeting, spend two minutes updating the client context file.

Be specific. “Sarah is hard to work with” is not useful. “Sarah pushes back on pricing in every meeting - always have a value justification prepared before discussing costs” is actionable knowledge that Claude can use.

Let Claude help maintain them. After a working session, ask Claude to summarise what was decided or learned and add it to the relevant reference document. The AI becomes part of the knowledge management workflow, not just a consumer of the knowledge.

Common Questions

How many reference documents should I have? Start with 3-5. One per major client, one for lessons learned, one for your business processes. Add more as the need arises naturally.

What about sensitive information? Reference documents live on your local machine. They’re as secure as any other file on your computer. That said, use judgement about what you store - you probably don’t need to include passwords or financial details.

Can my team share reference documents? Yes, if you store them in a shared location like OneDrive or a Git repository. Shared reference documents are particularly powerful for team consistency.

How is this different from just keeping notes? Notes are for humans. Reference documents are structured for both human and AI consumption. The formatting, the consistency, the clear categories - these make the difference between notes that Claude can use effectively and notes it struggles to parse.

The Bigger Picture

Reference documents aren’t just a productivity trick. They represent a shift in how knowledge workers manage their expertise.

Every insight, every lesson, every decision you capture in a reference document becomes part of a persistent knowledge base that makes your AI tools more effective over time. You’re not just getting work done - you’re building an asset that compounds.

The conversations still happen. The thinking still happens. But the knowledge stops disappearing when you close the tab.