--- name: setup-brain description: Personalize this external-brain template for its new owner - interview them about who they are and what they read, write that into CLAUDE.md, shape the folders to match, seed their real topic maps, and verify the vault lints clean. Use once, right after cloning the template, or when the user says "set up my brain", "/setup-brain", or asks to make this vault theirs. argument-hint: [anything you already want to say about yourself and your work] --- # Setup brain Turn the template into *this person's* vault. The single most valuable thing you produce here is not folders — it is the description of who the user is and what they work on, written into `CLAUDE.md`. Every later `ingest` and `query` reads that file, and retrieval in this vault is grep plus the link graph with no embedding layer. The vocabulary you record is the vocabulary the vault will be searchable by, for years. Spend your effort there. Input: $ARGUMENTS ## Hard constraints (never violate) 1. **Never set `publish: true`** on anything. Guardrail 1 is absolute and this operation is not an exception. 2. **Never invent facts about the user.** If you don't know their field, their title, or what they read, ask. A confident wrong description in `CLAUDE.md` poisons every retrieval that follows it. 3. **Confirm before deleting any file**, including the `Placeholder` examples. 4. **Nothing from `Private/` leaves `Private/`**, starting now. 5. **Never mention the assistant in commit messages.** ## Process ### 1. Interview Use `AskUserQuestion` for the choices with discrete options, plain questions for the open-ended ones. Do not fire all of these at once — two or three rounds, adapting to what they say. Anything they already told you in `$ARGUMENTS` is answered; don't re-ask it. What you need to come away with: - **Who they are.** What they do, what field, what they'd say if someone asked at a conference. A sentence or two, in their words. - **What they keep coming back to.** The 5–10 topics that would each earn a map. Push gently for specificity: "machine learning" is not a topic, "graph neural networks for molecular property prediction" is. These become `00 - ` maps and, more importantly, the tag vocabulary. - **What they want to capture.** Papers? Books? Meeting notes? Recipes? Talks they attended? Half-formed ideas? This decides which templates matter and which folders earn their place. - **What stays out.** Which parts of their life belong in this vault and which explicitly do not. Some people want recipes and hiking in here; some want it strictly professional. Ask rather than assuming. - **How they search.** When they half-remember something, what do they type? This is the question people find odd and whose answer is the most useful — it is the aliases and tags that will actually get hit. - **Whether any of it is ever meant to be public.** Only affects how you explain the `publish` flag in the handoff; it does not change what you set (see constraint 1). ### 2. Write who they are into `CLAUDE.md` Replace the placeholder opening paragraph and the `` comment above it with a real description built from step 1: whose vault this is, what domain it covers, what the recurring topics are. Keep the "you read, think, and decide; Claude does the bookkeeping" sentence — that is the thesis of the whole system. Leave every other section of `CLAUDE.md` alone except the tree in **Vault structure**, which you update in step 3 to match reality. ### 3. Shape the folders Based on what they said stays in and what stays out: keep, rename, or drop the top-level folders, and create any new ones they need. Someone who wants nothing personal in here drops `Life/`; someone who takes constant meeting notes may want a folder for them. - Actually create and remove the directories. - Update the tree block in `CLAUDE.md` so it describes the vault that now exists. - `Meta/`, `Private/`, and `Research/Papers/` should survive in some form — they are what the lint checks and the guardrails are written against. If the user wants them renamed, that's fine; tell them the lint scripts derive folders from the tree and will follow. - Note every move in `changes-for-lint.md` per the protocol in `CLAUDE.md`. ### 4. Seed their real topic maps One `00 - .md` per recurring topic from step 1, in `Research/Topics//`, copied from `Meta/Templates/Topic Map Template.md`. Fill the "Summary of topic" line with a sentence about what belongs there, in their words — an empty map is a folder, a described map is an instruction to your future self. Set `tags:` on each to the lowercase tag that topic will use. That tag vocabulary is now canonical; `ingest` will reuse it rather than coining near-duplicates. List them all in `Research/Knowledge Base Map.md`, nested to match the folders. ### 5. Rewrite `Home.md` and `Meta/Workflow.md` `Home.md` is the front door: a short welcome in their voice, and links to the Knowledge Base Map, `Workflow`, and any corner of the vault they'd actually want to land on. `Meta/Workflow.md` explains the system to a reader. Update the structure section to match their folders and the note-anatomy section to match their types. **Keep the Karpathy LLM-wiki credit** — the idea isn't ours. ### 6. Clear out the examples Ask first. Then delete the `Placeholder` notes (`Paper_Placeholder_*`, `Book_Placeholder_*`, `Example *`, `00 - Example Topic`) and the `Example Topic` folder. If they'd rather keep one as a reference until they've done their first `ingest`, keep it — but say that `lint` will keep reporting it, which is mildly useful as a reminder and mildly annoying. Remove every inbound link to whatever you delete, or the next lint reports the wanted notes you just created. ### 7. Regenerate the machinery and prove it works ```bash S=.claude/skills/lint/scripts python3 $S/fix_index.py --root "$PWD" --apply python3 $S/fix_dashboard.py --root "$PWD" --apply --date python3 $S/lint_scan.py --root "$PWD" ``` `fix_index.py` will not invent note lines, so write the `Meta/Index.md` lines for the maps you created yourself — one line each, with a real one-sentence description. Then read the scan output and fix what it found. **Do not hand off on a dirty scan.** A vault that lints clean on day one is the thing that makes `lint` trustworthy later; a vault that ships with four findings teaches the user to ignore it. ### 8. Log it and hand off Append the first entry to `Meta/Log.md`: date, `setup-brain`, what you created, what you deleted, anything they should look at. Then a short recap — no more than five lines: - what their vault now looks like - the one thing to do next: `ingest` something they actually just read, then `lint` - that `publish: false` is on everything and only they can change it - that `CLAUDE.md` is theirs to edit as their work shifts — it is the schema, not scripture Offer to commit (`setup: personalize vault for `), don't do it unasked.