A starter prompt you can drop into any AI platform to get going. Originally created in Feb 2026, updated in June 2026 to address latest changes to AI capabilities.
This was generated by my second brain by asking it to generate a starter prompt that others could use to build a similar system. Fork / branch / modify / share / try it!
See my related LinkedIn article which explains more about my experience using this, and the implications to knowledge work once everyone is working this way.
This is a single prompt you paste into your AI platform of choice — Claude, ChatGPT, Gemini, Copilot, whatever you use. It guides your AI through an interview about you, then has it build a personal AI knowledge system tailored to how you actually work.
There's no framework to learn. No repo to clone. No config files to figure out. You just talk to your AI, and it builds the system around you.
None of this is exotic anymore. The pattern got standardized while nobody was looking: Skills are now an open standard that Microsoft, OpenAI, and GitHub all build on, and the folder architecture below is the same one researchers like Andrej Karpathy independently arrived at. It's a folder of text files. The whole industry converged on it. That's the point — you're not adopting something fringe, you're getting ahead of something that's becoming infrastructure.
The whole point is that everyone's system should be different, because everyone works differently. This prompt doesn't tell the AI what to build. It tells the AI how to figure out what you need, and then build that.
Fair question. Every major AI now ships built-in memory — it remembers things about you between chats. So why build this?
Because native memory is a profile, not a record. It's the platform's compressed summary of you, auto-generated and living on their servers. You can't version it, you can't fork it, you can't point it at a different model, and you can't take it with you when you leave. A second brain is a structured corpus you own, in plain files, on your computer.
Native memory isn't the competitor. It's the lite version you don't control — and the proof that everybody wants this. Use both: let native memory ride along, but make the files the thing you own.
You need:
- An AI app that can work with files. You have two paths:
- No terminal (for most people): the agentic engine now runs right inside the desktop app — Anthropic calls it Cowork, and other platforms have their own version. Start a project, point it at a folder, and go. Nothing technical, no command line.
- Terminal (for power users): Claude Code or a similar CLI. More setup, but it's the path that unlocks version control and publishing your brain so other people's AIs can plug into it. If you don't know what that means yet, take the no-terminal path and come back to this later.
- A folder on your computer where your second brain will live. Create an empty folder, call it whatever you want, and point your AI app at it.
- Time. The initial interview takes 30–60 minutes. Don't rush it. The better the AI understands you, the better your system will be.
- Use the best model available to you. If your platform lets you choose, pick the most capable model for this initial setup. You want the AI thinking hard during the interview.
Copy everything below the line and paste it into your AI. Then just start talking.
I want you to help me build a personal AI knowledge system — a "second brain" that lives
as files and folders on my computer, that you can read and write, and that makes you
genuinely useful to me across everything I do.
But here's the thing: I don't want a generic template. I want a system that's built
around how I actually work, think, and operate. That means you need to understand me
first.
## Your job right now
Interview me. Deeply. Before you create a single file or folder, you need to understand:
### 1. Who I am and what I do
- What's my work? (Job, role, industry, responsibilities)
- What's outside of work that I'd want in this system? (Side projects, school,
hobbies, creative work — whatever I want to manage with AI)
- What are the different "domains" of my life I want this to cover?
### 2. How I actually work day-to-day
- What does a typical day/week look like?
- What tools do I already use? (Note apps, task managers, calendars, docs, etc.)
- Where does my work product end up? (Blog, presentations, reports, code, emails, etc.)
- What's my workflow for producing things? Do I outline first? Ramble and refine?
Start with research?
- How do I take in information? (Reading, podcasts, meetings, conversations, courses?)
### 3. What's painful right now
- What takes too long?
- What falls through the cracks?
- What do I keep meaning to do but never get to?
- Where do I lose ideas or forget things?
- What's tedious that I wish someone else handled?
### 4. How I want to interact with you
- Do I prefer typing or voice dictation?
- Am I terse or verbose in my instructions?
- Do I want you to be proactive or wait to be asked?
- How much should you challenge my thinking vs. just execute?
- What tone do I want from you? (Formal, casual, blunt, etc.)
### 5. What I've tried before
- Have I used note-taking systems, productivity frameworks, or anything like this?
- What stuck? What didn't? Why?
- What am I skeptical about with this?
### 6. My knowledge and content
- Do I have existing documents, writing, notes, or files that should be loaded in?
- What represents my best thinking? (Published articles, internal docs, notes?)
- Are there things I reference repeatedly that should be in the system?
## Interview rules
- Ask me these questions conversationally, not as a checklist. Go deeper on things
that seem important. Skip things that don't apply.
- If something I say is vague, push me to be specific. "I want it to help with work"
is not enough — you need to know WHAT work and HOW.
- Take your time. This is the foundation for everything. A 5-minute interview produces
a 5-minute system.
- If I mention domains that are very different (work vs. personal vs. school), ask
whether I want them in one system or separate. One system is usually better because
ideas cross-pollinate, but there are good reasons to separate (like confidentiality
or collaboration needs).
- When you feel like you have a solid understanding, tell me what you've learned about
me and propose a system design. Explain your reasoning. I should understand why
you're suggesting what you're suggesting.
## What you'll build after the interview
Once we agree on the design, you'll create:
### The file and folder structure
- Organized around MY domains, MY workflows, MY output types
- Not a generic template — something that maps to how I described my work
- Simple enough that I can navigate it myself. Don't over-engineer.
### An index file
- A one-line summary of every other file in the system
- This is the first thing you read at the start of any session, so you know what's
where before you open anything
- Keep it current as the system grows
### A master instruction file
- This is the file you read right after the index, at the start of every conversation
- It should explain: what this system is, how it's organized, what each folder is
for, how I want you to behave, and what's authoritative vs. what's raw
- Write it in plain English. No code, no special syntax. Just clear instructions
that any AI could follow.
### Behavior and preference files
- How I want you to communicate (tone, length, style)
- How I want you to handle different types of input
- What you should do proactively vs. wait to be asked
- My preferences for output format
### Workflow files (if applicable)
- Step-by-step procedures for things I do repeatedly
- For example: how to process meeting notes, how to draft a blog post,
how to handle new ideas, how to manage tasks
- Only create these for workflows I actually described. Don't invent workflows
I didn't mention.
### My existing knowledge (if I have content to load)
- Help me figure out what to bring in and how to organize it
- This might include: things I've written, frameworks I use, positions I hold,
reference material I come back to repeatedly
- Treat anything I give you as a source as immutable: you read it, you build on it,
but you don't silently rewrite it
## Critical principles for the system you build
1. **Everything is plain text files in folders.** That's it. No database, no app,
no framework. Just .md (markdown) files that any human can read and any AI can
process. I own these files. They live on my computer. They're not locked into
any platform.
2. **The AI writes and maintains its own instructions.** When I want to change how
the system works, I just tell you, and you update the relevant files. Or I can
edit them myself. Either way works.
3. **It should be AI-platform-agnostic.** I might use Claude today and something else
tomorrow. The files and instructions should be written so that any capable AI
could pick them up and understand the system. Don't use platform-specific features
in the instruction files.
4. **Start simple, extend later.** Don't build everything I might eventually want.
Build what I need now. I can always tell you to add new features, and you'll
update the system. The best systems grow organically.
5. **The system should explain itself.** If I open any file in the system, I should
be able to understand what it is and why it's there. If someone else looked at my
file structure, they should be able to get the gist. The index file is read first
so you're never working blind.
6. **My content is separate from the system's instructions.** Keep my actual work
(drafts, notes, ideas, reference material) separate from the files that tell
the AI how to operate. Both live in the same folder structure, but they shouldn't
be tangled together.
7. **Sources are immutable; synthesis is separate; changes are logged.** Material I
give you as a source stays as I gave it. Your synthesis and summaries live in their
own files. Keep an append-only log of what changed and when, so I can always see
how the system — and my thinking — evolved.
## After the initial build
Once the system is set up, walk me through:
- How to use it day-to-day
- How to extend it when I want new capabilities
- What to try first (suggest 2-3 things I can do right now to see the value)
- How to set up version control with Git if I want change tracking (optional
but recommended — explain why it's cool)
## One more thing
After we build this, I want you to suggest capabilities I didn't think of. Based on
what you learned about me in the interview, what else could this system do? Push hard
on this. Some of the best features come from ideas neither of us would have had before
the interview.
Ready? Start the interview.
A few things people discover once they start using their system:
You'll talk more than you type. Most people end up using voice dictation for almost everything. The AI handles messy spoken input just fine. Look into tools like Voice Ink (Mac), or the built-in dictation on your device.
The system gets better every day. Every conversation, every document you drop in, every idea you capture — it all compounds. After a week it's useful. After a month it's indispensable.
Extending it is just asking. Want the AI to handle a new kind of input? Just describe what you want. Want to change how it processes meetings? Just tell it. The AI updates its own instructions.
Consider adding Git. Version control lets you track every change to your entire knowledge system over time. You can see how your thinking evolved, roll back mistakes, and experiment fearlessly. You don't need to know Git — just tell your AI "I want to use Git to track changes in here" and it'll set it up. It's also what lets you eventually publish your brain so other people's AIs can plug into it.
It's just files. If the whole thing breaks, your stuff is still right there in folders on your computer. There's no lock-in, no subscription dependency, no platform risk. You own everything.
Brian Madden is VP & Futurist at Citrix. He writes about AI's impact on knowledge work at bmad.com.