--- title: "I built a brain for work, and Claude keeps it up to date" url: https://akdarrah.com/posts/i-built-a-brain-for-work-and-claude-keeps-it-up-to-date author: Adam Darrah published: 2026-11-04T18:43:04Z updated: 2026-11-04T18:43:04Z tags: ["ai","tools"] --- # I built a brain for work, and Claude keeps it up to date I'm taking ownership of a part of our product, and the first thing I noticed is how much of it lives in my head, or in nobody's head. A decision gets made in a meeting. The reason for it is in a Slack thread. The code that does it is in a PR from three months ago, and the ticket that asked for it says something slightly different. When someone asks "why does it work this way?", the answer is scattered across five tools. So I built a brain: one place where I, and later anyone else, can see what was decided and why. I didn't fill it by hand. Claude did the reading, and now it keeps the brain current on its own. ## The shape It's an Obsidian vault. Plain markdown files in folders, so any tool can read it and nothing is locked in: - `Projects/`: one note per project, with status, PRs, tickets, meetings and decisions. - `Decisions/`: one note per decision, named `YYYY-MM-DD Short title.md`. - `Meetings/`: one note per meeting. - `People/`: one note per person, with what they own and what they've worked on. - A folder for the area I own, with a map of the code that belongs to it. The vault is a local git repo with **no remote**. Work notes hold things that shouldn't leave my machine, so the brain never gets pushed anywhere. ## Four rules that make it trustworthy A brain is only useful if you believe it. These rules live in the vault's `CLAUDE.md`, so every agent that touches it follows them: 1. **Every fact has a source.** Every note has a `source:` property: a meeting link, a PR, a Slack permalink. If I can't click through to where it came from, it doesn't go in. 2. **When sources disagree, record both.** The meeting said one thing and the PR did another? The note says so and marks it as an open question, instead of quietly picking one. 3. **Decisions are their own notes.** Not bullets buried in a meeting summary. A decision note has the decision, why, what else was considered, and who decided. 4. **"No decision yet" counts too.** An open question gets a note with `status: open`. Those turned out to be some of the most useful notes in the vault. ## Filling it: let subagents do the reading I pointed Claude Code at everything since the start of August: my PRs on GitHub, my meeting notes in Granola, the Slack channels I picked, tickets in Linear, and my calendar. That's a lot of raw text, so I didn't want it in one conversation. Each source went to its own **subagent**, and only conclusions came back. What made this work with several agents writing at once: - **One shared brief.** Every helper read the same short file first: the vault's rules, what to skip, and what to return. - **Helpers only create files. They never edit existing ones.** Instead, each one ends its report with "links to add" (`this project -> that new decision`). The main session applies those links and makes the commits, so nothing gets overwritten. - **A privacy line drawn up front.** Only the Slack channels I approved, no DMs. HR and personal meetings are skipped completely. No raw transcripts, only summaries in the agent's own words. No credentials, ever. Before each commit I ran a scan for anything that looked like a key, an email address or a card number. The best moment came at the end. Later sources kept **answering open questions** that earlier ones had raised. A GitHub pass would flag "nobody recorded why this changed", and then the Slack pass would find the thread where it was decided. Because open questions were notes, I could go back and close them with a link. ## Keeping it current A brain that's only true on the day you built it isn't worth much. Two things keep it current. **Every Claude session knows it exists.** My global `~/.claude/CLAUDE.md` imports the vault's rules with one line, and adds a rule: before finishing a task, record any decision in `Decisions/`, update the project's status, and commit. The vault folder is also in `permissions.additionalDirectories`, so any session can read it. ```markdown title=~/.claude/CLAUDE.md ## Brain @~/Developer/obsidian/CLAUDE.md - Before finishing a task, log any decision to the brain and update the project's status. Commit to the vault. Never push it. ``` **A weekday job does the rest.** A launchd job runs `claude -p` at 7:30 every weekday morning. It reads what's new since the last run in my meeting notes, my chosen Slack channels, GitHub and Linear, files it into the vault, commits, and **emails me a short brief**: what's on today, what needs me, what changed, and what's due soon. Monday's run covers the weekend. It runs locally, not in the cloud, for the same reason the vault has no remote. The job only gets the tools it needs. It runs in `dontAsk` mode with an explicit allow list: read-only tools for each source, file tools, and `git add` / `git commit`. Every write tool on the other services is blocked, so it can't post to Slack, change a ticket or comment on a PR, and it can't `git push`. ```zsh title=run.sh claude -p "$PROMPT" \ --allowedTools Read Write Edit Glob Grep "Bash(git add:*)" "Bash(git commit:*)" \ "Bash(gh pr list:*)" "Bash(gh pr view:*)" \ --disallowedTools "Bash(git push:*)" \ --permission-mode dontAsk ``` One gotcha: **tool names can differ between an interactive session and `claude -p`.** My first test run said Linear was "access denied". Interactive sessions reached Linear through a plugin, but the headless run saw the claude.ai connector under a different name, which wasn't on the allow list. The fix was to allow both names. If a scheduled run says a tool was denied, check the exact tool name in its log. ## How I plan to use it - **Meeting prep.** Before a meeting about a project, I ask Claude to read the shared docs into the brain and write a prep note: what's already decided, what's still open, and the questions to ask. After the meeting, the next morning's run fills in the summary from my notes. - **"Why does it work this way?"** I ask the brain before I go digging. If the answer has a source, I trust it. If it doesn't, that's a gap worth filling. - **The morning email.** It tells me the sync ran, and it surfaces the things I'd otherwise miss: a new open question, an action item with my name on it, something due this week. - **Handing things off.** The point was never just my memory. When someone else picks up a project, the project note and its decisions are the handover. - **Deciding what to own.** The code map and the open-ticket list showed me where my area overlaps other people's. Each overlap became an open decision to agree with them, instead of something we argue about later. ## Build your own Paste this into Claude Code to start a brain like this one: ```text title=brain-prompt.txt Help me build a work "brain": an Obsidian vault at ~/Developer/brain that records what was decided and why. 1. Create folders: Projects/, Decisions/, Meetings/, People/, Templates/. Add a CLAUDE.md with these rules: every fact has a source property; when sources disagree, record both and mark it open; one note per decision (YYYY-MM-DD Short title.md) with Decision, Why, Alternatives, Who decided; "no decision yet" is a note with status: open. Never store credentials, HR or personal content, or raw transcripts. Make it a local git repo with no remote. 2. Audit what I've done since : my GitHub PRs, my meeting notes, the Slack channels I list, my tickets. Give each source to its own subagent with one shared brief. Helpers only create notes, never edit existing ones, and end with a list of links to add. You apply the links, scan for anything sensitive, and commit. 3. Ask before touching my global config. Then add the vault's CLAUDE.md to ~/.claude/CLAUDE.md, with a rule to log decisions and project status before finishing a task, and add the vault to permissions.additionalDirectories. 4. Set up a local launchd job that runs claude -p on weekday mornings with a read-only allow list plus git add/commit, files what's new since the last run, commits, and emails me a short brief. Do one manual test run and show me the log. ```