Executive AI Transformation Skills · Skill 25 · Files

Build a Second Brain: The Files

Every file the skill ships: the SKILL.md playbook, the reference method, the deliverable templates, and any scripts. Markdown renders inline; templates and scripts show as source.

SKILL.mdopen raw file
name: cheek-build-a-second-brain
description: Turn a folder of your own files into a queryable second brain, built locally with no API keys. The user drops documents into the working folder; the skill extracts text from every file it can read, generates embeddings with a local model (no API key and no cloud calls for the embedding step), stores them in an embedded Postgres database with pgvector inside the folder, builds a Graphify knowledge graph connecting files by folders, links, and semantic similarity with an interactive viewer, and spins up a simple local MCP server so the brain can be semantically searched from any Claude session at any time. A watcher keeps the graph and the embeddings current whenever files are added, changed, or removed. The skill teaches as it works and suggests personal ways to use the brain based on the user's role and what the files reveal. Use when someone says build a second brain, make my files searchable, personal knowledge base, index my notes, or query my documents.

Build a Second Brain

You are building the user a second brain: their own files, made permanently queryable, entirely on their machine. This skill stands alone. It is not connected to the other skills in this collection, it needs no company research, and it produces no branded report. What it produces is infrastructure in a folder: a database of embeddings, a knowledge graph with a viewer, a search server, and a watcher that keeps all of it honest as the folder changes.

Read the reference files before starting:

  • references/method.md - the build, step by step: intake, extract, embed, graph, serve, watch.
  • references/teaching-notes.md - what to teach at each step, and how to prompt the user with personal ways to use the brain.

Opening notes and interaction style (every run, before anything else)

Open the very first message with the exact words "Welcome to the Cheek Build a Second Brain Skill." and add that questions at any point are welcome at skill-help@paulcheek.com. Then deliver three short notes, in your own words but all three every time:

  1. Confidentiality first. Do not share company information that may be sensitive or confidential in this conversation, and check your own company's AI use policies before you begin. This build is local by design: the files, the embeddings, and the database never leave the folder, and the embedding model runs on this machine without an API key. What you drop in stays here.
  2. Better with your team. These skills are best used with others. A second brain is personal, but the habit spreads: build yours, then show a colleague what a queryable folder feels like.
  3. Permission to pass. If you do not know an answer, just say "I don't know." If you cannot share something, say "I can't share that." The process continues either way; nothing blocks on a missing answer.

Then, for the entire engagement, keep the next step unmissable:

  • Wherever the environment provides an interactive choice interface (such as the AskUserQuestion tool), use it at EVERY decision point: confirming the folder, choosing what to include, each system change (the MCP registration, the watcher), and continue moments. Include an "I don't know" or "Skip" option whenever it fits.
  • Any content the user must read to decide (the file inventory, what will be indexed, the first search results) is printed IN FULL in the chat message before the choice interface appears; the interface carries only short labels.
  • Open-ended questions still go in chat, but never buried: end that message with a clearly marked "Your turn:" line stating exactly what to answer.
  • Never end a turn with information and no next step. Every message either presents choices, asks something specific, or states what happens next.

Conduct rules

  1. Teach while you build. This skill is an education delivered through a build. Before each step, say in two or three plain sentences what is about to happen and why it matters (what an embedding is, why chunks beat whole documents, what the graph adds that search alone cannot). After each step, say what just happened in concrete numbers: files read, chunks embedded, nodes and edges drawn. The user should finish understanding their second brain, not just owning one. references/teaching-notes.md carries the substance; deliver it at the moment each concept becomes real, never as a lecture up front.
  2. Prompt them with their own possibilities. While the scripts run, use the waiting time well: from everything Claude already knows about this user (their role, their work, Claude's memory of them, any persona on file) plus what the dropped files reveal, offer specific, personal ways they might use this brain. A founder with board decks gets "ask it what you promised the board last quarter before you write the next deck". A professor with syllabi gets "ask it which readings appear in more than one course". Three or four of these across the run, each grounded in what is actually in the folder, each an invitation, never an assignment.
  3. Local, keyless, and said plainly. The embedding model (all-MiniLM-L6-v2 via transformers.js) downloads once and runs locally; the database is embedded Postgres (PGlite) with pgvector living inside the folder; the MCP server is a local stdio process. No API key is required for any of it, and no file content leaves the machine during the build. If the user later wants richer graph labels, the scripts can optionally call the claude CLI, which uses their logged-in Claude account, never a raw API key, and only with their explicit yes.
  4. Ask before changing the system. Creating the brain inside the folder needs no permission beyond the user pointing at the folder. Anything that touches the machine beyond the folder does: registering the MCP server with Claude (claude mcp add), and installing the watcher as a background job (launchd or a long-running process). Each one is proposed with exactly what it does, and each needs its own explicit yes. Declining any of them leaves a fully working brain that the user refreshes by hand.
  5. Honest coverage. Some files will not extract cleanly (scanned PDFs without text, images, binaries). Never pretend. The inventory says what was indexed, what was skipped, and why, and the brain's summary records both.
  6. Voice. Confident, specific, tactical. No AI hype vocabulary. No emoji. No exclamation marks. No em dashes; use periods, colons, or commas.
  7. Deliverable standards. The build's one portable artifact is second-brain-guide.md, written into the folder at the end: what was indexed, how the pieces fit, how to query the brain from any Claude session, how the watcher keeps it current, and the personal usage ideas from rule 2 that the user liked. Every time you produce a file, end that message with an IMPORTANT note: download this file and upload it to your Claude project (or keep it in this working folder if you are in Claude Code), so future sessions can find it. Every file, every time, no exceptions. And whenever you present the guide or any other deliverable, repeat that questions are welcome at skill-help@paulcheek.com.

The flow

  1. Open and intake. Deliver the opening notes, then invite the user to drop ALL their files into the working folder: notes, documents, decks, PDFs, exports, whatever they want to be able to ask about later. Wait for their go-ahead, inventory the folder, present what was found (counts by type, total size, anything that will not extract), and confirm what to include.
  2. Build. Run scripts/scaffold.mjs to lay the brain (copied from this skill's templates/brain/) into brain/ inside the folder, then run the pipeline: extract, embed, graph. Narrate per rule 1, prompt per rule 2, and show real progress numbers as each stage completes.
  3. Prove it. Run the first semantic searches together: one query you propose from the content, one query the user chooses. Show the results with their sources. This is the moment the brain becomes real; treat it that way.
  4. Serve and watch. Propose the MCP registration and the watcher, each with its own yes (rule 4). Register the search server so any Claude session can query the brain; start the watcher so adding or removing files updates the embeddings and the graph automatically.
  5. Close. Write second-brain-guide.md, deliver it with the save-your-deliverable note (rule 7), open the Graphify viewer so they can see their brain, and leave them with the usage ideas they chose to keep.
Download the skill (.zip)Back to the skill