How I Built My Second Brain 🧠

I use my second brain to run my company, inform my software factory, and collect random thoughts and decisions in one place.

Hello makers,

With the help of AI, I now have a robust second brain always available to me. It lives in GitHub, in the cloud, and I use it primarily in the Claude app. Here’s how it works.

TLDR

• A lot of what works is based on Andrej Karpathy’s LLM Wiki

• Organize your projects into connected hubs, with Markdown files holding the context

• I only use Claude Code, never Chat

• You can start your own second brain with a single prompt

When using agents, context is everything. Too little, and the model knows nothing about what you’re doing. Too much, and you’re burning tokens before the model even starts doing work.

Every project I’ve ever worked on has a history. Decisions I’ve made, ideas I’ve put aside, things I’ve tried that didn’t work, preferences that are obvious to me, but would take a while to explain to someone else. Claude needs that context to be useful, and I need somewhere it can access it anytime I’m using an agent to do work.

The system I use is essentially a collection of text files. Models are really good at parsing text, so it only makes sense to keep this information in a format it can use.

Adapting Karpathy’s Approach

The foundation of my second brain comes from Andrej Karpathy’s LLM Wiki. His idea is to have an AI agent maintain a knowledge base as you work. You bring it sources and questions. It turns what you learn into connected pages, revises them as new information arrives, and saves useful conclusions for next time.

He describes three layers: original source material, a wiki of organized knowledge, and instructions explaining how the agent should maintain it. An index helps find things. A log records what happened. The work of a good conversation becomes part of the knowledge base.

I’ve adapted that idea to the shape of my studio. My sources include product strategy, brand documents, project plans, and the decisions that come out of working with Claude. It also holds my vision for my company, taste choices, and my personal goals and ambitions.

Hub-and-spoke

Six Overground has several products of its own, along with client projects, each with its own audience, roadmap, and code. For example, Briefshot has an iOS app and a Next.js backend. Link My Photos has web, iOS, and Android code. Some products also depend on libraries that I maintain separately.

I’ve organized this structure into a hub-and-spoke model. At the top is sixoverground-workspace. It contains company-wide strategy, information about me, active initiatives, and an index of the projects. Each product has its own hub, which holds its specific context and points to its code repositories.

Here’s a small piece of the map:

sixoverground-workspace
├── CLAUDE.md
├── INDEX.md
├── LOG.md
├── projects
│   ├── _index.md
│   ├── briefshot.md
│   └── linkmyphotos.md
├── briefshot-hub
│   ├── CLAUDE.md
│   ├── repos.yml
│   ├── briefshot-ios
│   └── briefshot-next
├── linkmyphotos-hub
│   ├── CLAUDE.md
│   ├── repos.yml
│   ├── linkmyphotos-rails
│   ├── linkmyphotos-ios
│   └── linkmyphotos-android
└── libraries
    └── tang

Every named project in that diagram is a separate GitHub repository. The lines show relationships. On my computer, I arrange the folders together for convenience, but each repo keeps its own files and version history. I currently have 9 hubs branching off the main workspace.

The workspace knows what Link My Photos is. The Link My Photos hub knows its audience, product decisions, and plans. The iOS repo knows how the app is implemented. And Link My Photos uses Tang, my Rails subscriptions engine. Another product can also reference that same library without taking ownership. I can move from the company view down to the code as the work gets more specific.

Each fact has one home. Company-wide rules live in the workspace, product decisions live in the product hub, and implementation details live with the code. Other repositories point to that information. That way, changing a decision doesn’t mean hunting down several copies.

A brief explanation of some of the special files in the system:

CLAUDE.md

The entry point for Claude is a file named CLAUDE.md. It explains what the repository contains, where to find the important information, and how to work there. At the studio level, it points to the brand brief, channel strategy, and project index. Inside a product, the instructions get more specific.

INDEX.md

INDEX.md is the map of the workspace. Each file gets a path, a short description, and a status. Claude reads it first, then opens what the task needs. Smaller indexes, like projects/_index.md, help it drill into a particular area.

LOG.md

LOG.md records what happened and when. Each entry points to the document where the decision or analysis lives. Studio-wide events go in the workspace log, and project events go in that project’s hub log. Claude searches the relevant entries instead of loading the entire history into every session.

repos.yml

A project’s repos.yml file lists the repositories it owns and the libraries it depends on.

Maintenance commands

I’ve added a few custom Claude Code commands to keep the brain useful. /save files useful thinking back into the system. /promote moves important local memories into the repository that owns them. /lint checks for contradictions, missing links, duplicated information, and stale documents. Claude can flag an old strategy, but I still have to decide whether it makes sense.

Markdown, good for bots and humans

The knowledge itself is written in Markdown. Agents love working in Markdown. The files typically end in .md.

“It’s a simple, elegant syntax to apply formatting to text, and anyone can write it.”
— Serial Maker Issue 18: Markdown Goodies

For a super-friendly reading experience, I recommend using Obsidian. Just open the workspace folder as an Obsidian vault. Obsidian renders markdown in a human-friendly format, with all the formatting syntax applied. Obsidian reads my local files, so I pull changes from GitHub to keep that view current. You can read your second brain and edit it directly.

Code over chat

But most of the time, I’m just talking to Claude. I only use Claude Code for this. Never Chat. Even when the task is brainstorming, writing, or figuring out what to focus on, I start a code session. I want Claude leveraging my second brain, with the ability to read its context and save what we figure out.

“When we least expect it, that most special idea comes upon us like a bolt of lightning from heaven, seemingly out of nowhere.”
— Serial Maker Issue 8: Brainstorm

Let’s say I have a random idea when I’m out and about. I bring up the Claude app on my phone, start a new Claude Code session, and add the sixoverground-workspace repo to the session. Now I can discuss priorities, develop an idea for this newsletter, or work through how different projects fit together.

If I’m planning a new Briefshot feature, I include the hub and the relevant code repositories. Claude can use the product strategy alongside the implementation. We can work through what the feature should do, then save a plan that another session can pick up.

The simplest thought capture goes straight to initiatives/inbox.md, a plain queue. Claude will just add the idea there, and I’ll be able to recall it and organize it later. Capture is easy and quick.

Once changes are saved and pushed to GitHub, a new session can pick them up. Claude Code cloud sessions keep running when I close my laptop, and I can return to them from my phone.

That means my second brain is in my pocket.

Start your own second brain

If you want to build your own second brain, create a private GitHub repository. Then connect that repository to a new Claude Code session. To get started, you need a Claude subscription that includes Claude Code and a free GitHub account. That’s it.

You can use a prompt like this to get started:

Set up a second brain for this project as a git repo of markdown files.

Create three files:

- CLAUDE.md: the schema. What this repo is, what it is not, where each kind of fact lives, and
  the rules below. Short enough to load every session.
- INDEX.md: the router. One row per file: path, one-line summary, status (canonical, active,
  draft, superseded). No prose. Read this first and open only what the question needs.
- LOG.md: an append-only log, newest at the bottom. One entry per event:
  "## YYYY-MM-DD | kind | title", then a "Pointer:" line naming the file that holds the content.
  Entries point, they never restate.

Rules:

- Every fact has one home. Everywhere else points at it. A copy is a defect.
- Keep raw sources separate from notes. Never edit a source. Every note cites the source it
  came from.
- When we reach a decision, write it in the doc that owns the topic, dated, with the reasoning
  and the source. Add one pointer line to LOG.md.
- Update a file's INDEX.md row in the same change that creates or changes it.
- Flag missing information and contradictions instead of resolving them silently. Never invent a
  fact to fill a gap.
- Show me what changed at the end of every session.

Read what is already here, then propose the structure before you write it.

Then use it for something real. Ask a question you’ve been trying to answer. Read the result. Correct what Claude misunderstood. Have it save the useful parts, and check that a fresh session can find them.

As you add projects, give each one a hub and connect it to the top-level index. Let the structure grow with the work.

Keep making, and thanks for reading! 🙌

Reply and tell me what you’re making. I’m looking for anyone interested in talking about their own side-projects and maker journey, so speak up if you’d like to appear in Serial Maker. I’d also love to know what you thought of this issue, and what you want to hear about in the future. Check out the past editions if you missed them, and don’t forget to continue the conversation on Discord!

Until next time,

Craig 👋