Build an AI second brain for your team: every prompt from the video

Every new chat with an AI starts from zero. You explain your clients, your servers, what you decided last week. Again. A wiki the AI writes for you fixes that: you explain it once, and every session after that knows it.

I run three of them: one for the company's leadership, one for our DevOps team, and a personal one for my house. The oldest is from April and it's past a thousand pages. It's still just markdown files in a git repo. No vector database, no extra service. In the video I build a new one from scratch for an ops team. These are the exact prompts I typed, in order.

One request: copy the prompts yourself. Don't hand this page to your agent and tell it to do what it says. I'm not hiding anything in here, but you shouldn't get used to letting a stranger's web page give orders to an agent that has access to your machine.

What it is

It comes from Andrej Karpathy's LLM Wiki gist. The gist has no code, just a description you give your own agent, and the agent builds the rest. There are three layers:

• Raw sources: everything you feed it. Articles, emails, meeting transcripts, configs. The AI reads them and never edits them.
• The wiki: a folder of markdown pages the AI writes and keeps up to date: summaries, a page per server, project, person or decision. Plus two special files: index.md, a catalog of every page, and log.md, an append-only record of what happened when.
• The rules: a CLAUDE.md (or AGENTS.md for Codex) that tells the AI how the wiki is organized and how to work on it.

You do three things with it: ingest (new information goes in), query (ask it questions), lint (clean up contradictions, stale claims and broken links every now and then).

You don't need to feed it every Slack message and every email. Some companies do, with search and vector databases on top. For most of us that's not needed: the big decisions, the gotchas and the things you can't easily find anywhere else give you most of the value.

What you need

• Claude Code or Codex, on the subscription you already pay for.
• An empty folder. That's the wiki.
• Obsidian, if you want to look at it as a graph. Optional: after a while you won't open it yourself. You ask the agent and it searches the wiki for you.

My prompts are about servers, GitLab projects and a meeting transcript, because that's what an ops team needs to remember (Fireflies is our meeting recorder). Swap in your own team, tools and sources: client calls, docs, a CRM export, your notes. In the video every source is fake (exported files standing in for the real servers and tools), because I can't show our real data.

1. Set it up

Open Claude Code (or Codex) in the empty folder:

I'm setting up a Karpathy-style LLM wiki for our ops team at Lynx. One shared memory for the team and our Claude sessions: servers, projects, deployments, review environments and the decisions behind them. Read his gist first: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Then set it up in this folder. Keep it simple: plain markdown files, a page for every server, project and decision, an index and a log, no database. We'll browse it in Obsidian. Put the rules in CLAUDE.md so every future session follows them. Then commit.

It reads the gist, sets up the folders, the index, the log and the rules, and makes it a git repo, so the wiki has a history. If it stops to check the plan with you first, answer its questions or just say "Go ahead."

On Codex, say AGENTS.md instead of CLAUDE.md: that's the file Codex reads.

2. Fill it

Tell it where things are instead of pasting them in:

Now fill it. Start with my ssh config, then read the ops sync we just had in Fireflies. Then go through our GitLab: the project list, every project's CI config, and the runner. Then ssh into each server and check what's actually running there. For every project, record whether it has CI, whether it has review environments, and which server it's deployed on. Ingest it all, one source at a time.

Give it whatever your team needs: email, Slack, meeting transcripts, GitLab or GitHub, even your YouTube analytics.

My run took about 8 minutes. With real data it can take an hour or more, but that's the agent's time, not yours. It ended with every project, the server it runs on, the open decisions from the meeting, and the contradictions it found between the sources. It also started improving its own structure: every project page got CI, review-environment and server fields, with "unknown" where no source said.

One more source you already have: your old sessions. Every Claude Code and Codex conversation is saved on your machine as a text file (Claude Code's are in ~/.claude/projects/), and they're worth ingesting too. Claude Code deletes them after 30 days by default. To keep them longer, set cleanupPeriodDays in ~/.claude/settings.json (for example "cleanupPeriodDays": 365). They're small text files. Codex keeps its sessions in ~/.codex/sessions.

3. Ask it something, and keep the answer

docker-01 keeps running out of disk. What's on it, what can go today, and what do we change so it stops happening? Answer from the wiki, and save the answer as a page.

The second half matters. A good answer you don't save is gone with the chat. Saved as a page, the next session starts from it.

Here I told it to answer only from the wiki. In real use, don't. The wiki is an index, not always the source of truth. Keep the important things in it: decisions, gotchas, what you learned along the way. When the agent can check the real thing (the server, the project in GitLab, the document in SharePoint), that's the better source, and the wiki tells it where to look.

4. Clean up

Lint the wiki. Look for contradictions, outdated info, orphan pages and gaps, and write me a report. Fix what's safe to fix and list the rest for me.

It fixes what it can on its own (relative dates like "last week", missing links between pages, claims without a source) and gives you a short list of what needs you: decisions only you can make, contradictions it needs another source for, gaps no source covers, and risks worth a look. Each answer you give makes the wiki better for everyone who uses it.

5. Make it run by itself

This step makes it run on its own:

Now make it run by itself. Turn ingest and lint into skills in this repo, so I can type /ingest and /lint; /ingest also processes an inbox/ folder. Add hooks to this repo: when a session starts, pull and tell me how many notes are waiting in the inbox; when it ends, commit what's left, pull and push. Then create a global skill called /wiki for all Claude sessions on this machine, so any project can drop a short note into this wiki's inbox/, commit it and push. And add a short section to the main CLAUDE.md for all sessions on this machine: check the wiki's index.md first when the work touches our servers, projects or deployments, and send anything worth remembering with /wiki, without asking me.

What you get:

• /ingest and /lint become commands.
• /wiki works from any project. A session drops a short note into the wiki's inbox/ instead of editing wiki pages directly, so many people and sessions can feed one wiki without stepping on each other. /ingest files the notes later.
• The hooks keep everyone on one copy: pull when a session starts (and say how many notes are waiting), push when it ends.
• The rule in your main CLAUDE.md (~/.claude/CLAUDE.md, the one every session reads) makes every session, in every project, look in the wiki before it asks you, and send a note when a big decision is made or it learns something the wiki should know. "Without asking me" matters: if it asks, you say "later", and it doesn't happen.

On Codex, skills run as $ingest instead of /ingest, and the main rules file is ~/.codex/AGENTS.md.

I run /ingest by hand

A lot of people add a hook that ingests every note the moment it arrives. I don't. A busy wiki gets a lot of notes, and ingesting them well takes a lot of tokens. I run /ingest myself in batches: when my usage limit is about to reset anyway, or at the end of a long day when I don't need the usage for anything else.

If you do the same, notes can sit in inbox/ for a while. Add one line to the rule above so sessions look there too:

When you search the wiki, also read the notes waiting in its inbox/ folder; they aren't ingested yet.

Projects that shouldn't use the wiki

Once the rule is in your main CLAUDE.md, every session on your machine uses the wiki. For a personal project you may not want that. Two ways out:

• The quick one: tell the session in that project to write into the project's own CLAUDE.md that it must not search the wiki or send anything to it (or that it should use a different, personal wiki). This has worked well for me, but it isn't foolproof: you're trusting the model to follow it.
• The clean one: a separate Claude profile. A profile is just a separate config folder with its own skills, memory, rules and login. Claude Code can set one up for you if you ask; underneath it's one environment variable:

alias claude-personal='CLAUDE_CONFIG_DIR=~/.claude-personal claude'

Type claude-personal and you get the other profile. One catch: Claude Code also reads the .claude/CLAUDE.md of every parent folder, and your home folder is the parent of most projects, so the main rule can still load there. Keep those projects outside your home folder, or run /context in the personal profile to check what it loads.

You can still share a skill between profiles: keep it in one profile and symlink it into the other, so both use the same files. Again, just ask Claude to set it up that way.

6. Use it from another project

Open a different project. Mine was a client site on our static server that now needs a backend:

This site runs on our static server, and the client wants a contact form, so it needs a backend. Move it to the docker server: one container with a small Node.js server that only serves the static site for now. The devs will add the backend later. Set it up the way we do our other docker projects, and update the .gitlab-ci.yml based on our other projects that live there.

I never mention the wiki here, and I don't say which server is which or which project to copy. The rule makes the session read the wiki first, so it finds the docker server, picks a project already running there and copies its configuration and CI. When it learns something new on the way, it sends a note to the wiki's inbox on its own.

7. File it

Back in the wiki:

/ingest

Now every Claude session on the team knows what that one session learned.

Sharing it with your team

It's a git repo, so sharing it is simple: add a remote and push. Everyone's sessions read it and send notes; one wiki session files them. The only problem is how sensitive the data is. A company brain has client names and decisions in it. What we tried:

• git-crypt encrypts the contents of the files, so GitHub or GitLab only see encrypted data, and only people with the keys can read it. But file names and commit messages are not encrypted. For a company wiki, where client names sit right there in the file names, that's not enough.
• git-remote-gcrypt encrypts the whole repository: the platform sees only a few encrypted files and no readable history (you still have it locally). Every push is a force push. In our experience it was buggy: sometimes a push came out unreadable, sometimes it wasn't encrypted for everyone's key, so someone couldn't decrypt it. I wouldn't use it.
• What we ended up doing: a small server just for the wiki, used as the git remote. The files aren't encrypted on it, but the server is inside our network, IP-allowlisted, and only the people who need it have SSH keys for it. I think that's the best option, and it keeps things simple.

Whatever you pick, keep secrets out of the wiki: passwords, keys, tokens. Put that in the rules, and make /wiki refuse to write them.

Is this enough?

Today's models are good at finding things as long as they have a basic structure and an index to start from. For most companies, this is enough.

This wiki is the first part of a series on my full AI setup. Questions, or your own version? Get in touch.