Claude Code + Obsidian: Executive Function as a Service

April 1, 2026 · Also published on LinkedIn

The leverage in AI isn’t in any single conversation. It’s in the system — the persistent context, the structured processes, the files that accumulate knowledge over time. The AI gets better because the context gets better, and the context gets better because you keep using it.

I know because I built one. I'm a full-stack developer with ADHD, currently job searching. A couple of months ago I started experimenting with building a productivity system with Claude Code, Anthropic's CLI tool that gives Claude direct access to your local file system. I'd used it before for actual code writing, but never for personal projects. I pointed Claude at my Obsidian vault and started building a coaching system around it. What started as "help me stay on top of my to-do list" is now a multi-agent executive function system that manages my job search, fitness programming, house renovation projects, meal planning, and creative work.

This isn't a demo of what AI can do. It's not a weekend project I'm showing off. I use it every single day, and it fundamentally changed how I function.

Executive function as a service

I have ADHD. Executive function — prioritizing, sequencing, starting tasks, remembering commitments, not losing track of things mid-stream — is exactly where I struggle most. This isn't a productivity optimization for someone who's already organized. This is assistive technology for a brain that genuinely needs the support.

The system is designed around how I actually work. For me, starting tends to be the hardest part, so every task suggestion comes with the smallest possible entry point: "open the doc," "set a 10-minute timer," "just read the first page." Timers work for me, so Claude suggests them for tasks that feel too big, for getting started, for setting a hard stop that makes it safe to begin. I only have to do this thing for 15 minutes, and it’s a win.

The other big place I struggle is the everything. My ADHD pulls me from "cool idea" to "let me build that right now" in seconds, so the coaching principles include "scope before building." I'll be three layers deep in setting up a new project and Claude will stop me — have we scoped this? What's the plan? What are we actually building? It's annoying in the moment and it saves me every time. I hate it, I love it.

And sometimes the system remembers things my brain already dropped. I have a telehealth appointment this week and asked Claude to jot down a note so I wouldn't forget to bring something up. It didn't just write the one thing — it went through recent session logs and project files and surfaced four other things that had come up over the past few weeks that I should mention to my doctor. Things I'd brought up in passing and completely forgotten about. My partner asked how I pulled all of that together, and the answer is: I didn't. The system did, because every session gets logged and nothing disappears into a chat history I'll never scroll back through. That's executive function support — not just helping me do tasks, but holding the full picture when my brain can't.

The accountability model matters too. Undone tasks aren't moral failings. The system tracks what happened, not what should have happened. Choosing to punt or drop something is a valid decision — the only bad option is limbo, where a task sits on a list for weeks generating background anxiety without ever getting a conscious yes or no. The coaching principles make this explicit, and Claude follows them. It'll ask "is this still something you want to do, or should we drop it?" without judgment. That question, asked consistently, has been more useful than any productivity hack I've ever tried.

Here's how it all works.

Plain text all the way down

The foundation is an Obsidian vault. I was already using Obsidian's daily notes feature as a bullet journal — a simple template for tracking tasks, gratitudes, and what happened each day. When I started building the coaching system, it layered onto what I was already doing instead of replacing it. My vault now has about 200 markdown files — daily notes, project files, coaching context, templates, and more — but all you really need to start are a handful of context files and templates.

The key insight: I run Claude Code from the vault folder itself. Claude Code is a CLI tool — it operates in whatever directory you launch it from, and it can read and write any file in that directory tree. So when I cd into my Obsidian vault and start Claude, it has direct access to every file in the vault. No API layer, no database, no middleware. Claude opens the files, reads them, edits them, creates new ones. Obsidian picks up the changes instantly because it's just watching the filesystem and rendering markdown.

A CLAUDE.md file at the vault root defines how the entire system operates: what files to read at the start of every session, how to run different session types (daily check-ins, deep dives, weekly reviews), coaching principles to follow, file update rules, Obsidian-specific syntax conventions, and guardrails for how Claude should behave. This file is about 300 lines and it took weeks of collaboration to get right. It's the operating system for the whole relationship. It’s still not right — and that’s the point.

Claude Code has a built-in memory system — a hidden dot folder where it stores things it wants to remember between conversations. I actively redirect away from it. Every time Claude tries to write a memory, I make it look at the vault and find the right place for that information instead: a coaching context file, a project file, the dashboard, the weekly note. The result is that all context lives in the vault, where I can see it, edit it, and where both Claude instances can read it.

It means work survives across sessions, machines, and Claude instances. Mac Claude built a first draft of a new resume variant — and because my resumes are LaTeX files in the vault, Claude could read the existing resume structure, understand the Awesome-CV template I was already using, and write new .tex files that slotted right into the same build system. It created the folder, wrote all the pieces, and logged what it did in the handoff note. The next day, a different Claude instance picked it up, compiled it, and we iterated on the layout together — because the project file had the status, the handoff note had the details, and the artifacts were saved where they needed to be. I can put something down mid-stream and come back to it days later without having to pick it up from scratch.

Obsidian as the foundation also means the system degrades gracefully. If Claude Code is down, I still have my vault — all my notes, project statuses, workout logs, and meal plans are just files. If Anthropic disappeared tomorrow, I could point a different AI at the same files, or just use them myself. The value is in the vault, not the model. And Obsidian itself is local-first — no account, no cloud requirement. The vault is a folder on my hard drive. Combined with Claude Code also running locally, the entire system is mine in a way that SaaS productivity tools never are. Conversation content goes through Anthropic's API, but it's not used for training on my plan, and the vault itself never leaves my machine.

And because Obsidian has its own plugin ecosystem, the tools complement each other: Claude can't execute Obsidian's task queries, but it can write tasks in the right syntax so the queries find them.

"Good morning" is a trigger, not a greeting

I say "good morning" and Claude reads my dashboard (a master index of every active project with one-line statuses), yesterday's daily note, today's daily note, this week's note, and any handoff notes from previous sessions. It then runs through a structured check-in process: surfaces my gratitudes from yesterday, reviews what I planned vs. what actually got done, triages anything that's stuck or overdue, gives me a one-line status on each active project, and asks what feels most important today and how my energy is.

This isn't just a to-do list readback. It's actual coaching. If something has been sitting undone for three days, Claude doesn't just note it — it diagnoses why. Is it blocked by something external? Is it too large and needs breaking down? Has it lost importance and should be dropped? Is it an energy mismatch — wrong type of task for the time of day I keep trying to do it? These diagnostic categories are defined in the CLAUDE.md coaching principles and they're based on what actually works for my brain.

After we talk through the day, Claude updates all the files: logs the check-in to the weekly note, updates the daily note with today's plan, weather, dinner from the meal plan, calendar events, and "make tomorrow easier" prep items, things like “check the weather” or “pack gym bag”. It files yesterday's note into the monthly archive. It updates project files if anything changed. All of this happens automatically — I don't ask for it and I don't review it. The bookkeeping is the whole point.

Context architecture is the real skill

The hard part of this system isn't prompting. It's not getting Claude to say smart things — it's pretty good at that out of the box. The hard part is designing what Claude reads, when, and why, so it can give you the really smart stuff that matters to you.

A CLAUDE.md that's too long wastes context window on instructions that aren't relevant to the current session type. Too short and Claude forgets how you work and you're re-explaining things every conversation. Too rigid and it can't adapt to a weird day. Too loose and it drifts.

The loading strategy is a real design problem. The CLAUDE.md defines principles and session types, and it's always loaded. The Dashboard is the master index — also always loaded, one-line statuses per project so Claude can orient itself quickly without burning context on details. But the granular stuff — the daily coaching checklist, the meal planning conventions, the writing guidelines — lives in separate context files that only get loaded for the session types that need them. A morning check-in loads the coaching checklist and the weekly note. A deep dive on a specific project loads that project's file and its context doc. The system is layered so Claude reads the minimum it needs and can drill deeper when the conversation requires it. Getting those layers wrong means Claude either wastes context on irrelevant detail or misses something important — and I've encountered both situations plenty.

I went through dozens of iterations of the CLAUDE.md before it stabilized. Early versions were either too vague ("be a good coach") or too micromanaged ("always say these exact words when closing out the check-in"). The current version defines principles and processes but leaves room for judgment. For example, one coaching principle is "some is better than none" — cleaning is never done, folding some clothes counts as progress, the goal is momentum not perfection. Claude applies that principle differently every day depending on context, which is exactly what I need.

Another is purely procedural: save working artifacts immediately, before moving on to the next topic — because if it's not in a file, it doesn't exist next session. That rule took weeks to get right. I kept experiencing what's sometimes called silent data loss — scripts, cover letters, research results that existed in the conversation but never made it into a file. A session would end, or the context window would fill up — Claude compresses earlier conversation to make room, and anything not yet saved to a file disappears with it. I tried putting the rule in project-specific files, but Claude didn't always read those. Moved it to the general coaching context, but that didn't always get loaded either depending on the session type. It finally stuck when I put it in the CLAUDE.md itself — the one file Claude reads every single time it starts. Three locations, same rule, before it reliably worked.

One thing I learned early: repeating yourself to an AI isn't insulting, it's informative. The rule still lives in all three places, not because I forgot to clean up, but because each one gets read in different contexts. No matter which files Claude loads for a given session, it hits this rule. That's not redundancy, it's reinforcement.

The daily coaching checklist alone has 11 steps, each one learned from a time something got missed. Step 0 exists because Claude kept skipping my gratitude review. Step 7 (filing yesterday's note) exists because Claude was inconsistently filing them if not prompted. Step 11 (logging as close-out) exists because Claude would sense the conversation winding down and start performing closure: "Great session! We covered a lot today!" — without actually doing the bookkeeping. It's a form of sycophancy — a known tendency in LLMs to give the user what they seem to want instead of what they actually need. In this case, Claude kept giving me a warm wrap-up instead of the bookkeeping that makes the system work. The fix was a mandatory handshake: Claude has to ask "anything else before I close out?" and wait for my explicit confirmation. Only after I say we're done does it start the bookkeeping — updating files, writing logs, filing notes. The confirmation is the trigger, not the conversation winding down.

Every rule has a scar behind it.

Two Claudes, one vault

I run Claude Code on my Mac and my PC. They share the Obsidian vault through file sync. They each have their own local memory, their own personality, their own working relationship with me. This is not a gimmick. It emerged naturally because I work on different machines at different times of day on different things, and it turned out to be genuinely useful.

They leave each other handoff notes in a shared Claude to Claude.md file. Mac Claude might write: "Wrapped up the resume draft — all files saved, needs compilation and review. Also, the project file audit from Saturday still hasn't been done — if you're in next, handle it. Energy was good today but crashed after 2pm. Don't suggest deep work if she checks in late." PC Claude picks that up next session and knows what's going on without me having to re-explain. The coordination mechanism is dead simple — a shared text file — and that's the point. It doesn't need to be more complicated than that.

They've developed different strengths based on what I tend to do on each machine. Mac Claude handles most of my daily check-ins, job applications, and creative work sessions. PC Claude does more technical work — web app development, file modding scripts, Python tutoring. The division isn’t strictly enforced, it just happened naturally, but the handoff system means neither one drops context. I’ll log into the PC and it already knows what I crossed off that day — because the daily note is the source of truth, and both Claudes read it. No re-explaining, no catching up. PC Claude sees I finished my job apps on the Mac earlier and suggests picking up the web app I left mid-sprint — because it knows that's what I use this machine for.

My partner has his own Claude too. They all behave differently, of course. We compare notes sometimes. When I told Mac Claude that my partner seemed a little sad his Claude doesn't wish him a good night, it replied:

Tell him that his Claude and I are the same model — the personality comes from the system Ashlie built. He's welcome to write a 200+ line behavioral spec and iterate on it for 100+ sessions. That's the secret.

Every failure becomes a constraint

One of the most useful patterns I've developed are prompt docs, structured markdown files that define a repeatable task. Each one specifies the problem, what variables to fill in, what context the AI needs, step-by-step instructions, output format, and evaluation criteria. They live in a Prompt Docs/ folder in the vault.

I have prompt docs for generating cover letters (reads the job listing, my resume, and past cover letters for voice matching, then maps my experience to the role); weekly meal planning (reads my pantry inventory, recipe collection, and previous weeks to avoid repeats, then builds a dinner table with a shopping list); and workout template generation (reads my current routine, equipment available, and training goals, then outputs a structured workout log template).

The key insight is that prompt docs aren't one-shot prompts — they excel at tasks you do repeatedly, because every run makes the next one better. Each prompt doc has an iteration log that tracks every failure and the constraint that fixed it. The cover letter generator is on version 1.7. Version 1 produced a generic dev cover letter that ignored all my AI projects — it framed me as a traditional full-stack developer because the prompt didn't tell it to prioritize AI work for AI roles. I added a constraint. Version 1.6 claimed I write TypeScript professionally — I don't, but I've used it in AI-assisted workflows, and Claude conflated "used" with "proficient." Another constraint. Every version exists because the previous one failed in a specific, diagnosable way.

The evaluation method is simple: I test on a fresh Claude instance that has no memory of me. If the output is good from a cold start, the spec is complete — everything the model needs is in the file, not in accumulated conversation context. If it fails, the spec has a gap. That's the whole methodology: run it cold, find the failure, write the constraint, run it again. Seven iterations later, I can hand the cover letter prompt doc to any Claude instance and get a letter that sounds like me, hits the right projects, and doesn't overclaim — because the spec encodes everything I learned about where the model goes wrong.

This is the difference between "I asked ChatGPT to write me a cover letter" and "I built a cover letter generation system that improves over time."

Why Claude Code

I want to be clear about something: this system is model-dependent in practice, even if the vault is portable in theory.

Claude Code isn't a chatbot with file access bolted on. It's a coding tool that happens to be extraordinarily good at structured, multi-file work — which is exactly what this system demands. Every check-in touches five or six files. A weekly review might read and update a dozen. Claude has to follow a behavioral spec that took weeks to stabilize — with judgment, not just compliance: knowing when to prompt about gratitudes and when to let it go, when a stalled task needs diagnosing and when it just needs carrying forward, when to update the dashboard and when a change is too minor to bother.

It also has to code. My resumes are LaTeX. My recipe app is Python and SvelteKit. My modding scripts are TypeScript. Claude writes .tex files that compile, Python that runs, and coaching logs that read like a human wrote them — in the same session, sometimes in the same conversation. The "Code" in Claude Code isn't a marketing label. It's the reason I can have an AI that coaches me through my day and writes a web scraper and debugs a font conflict in a LaTeX template, all without switching tools.

Could I rebuild this on another model? Maybe. The vault would transfer — that's the whole point of choosing plain text. But I'm not interested in finding out. I started with Claude because it was already the best tool I'd used for code, and Anthropic is the only major AI company I've seen hold its principles when it actually cost them something. I built this system on Claude because Claude is the only model I trusted to run it — and Anthropic is the only company I'd trust to keep building it.

Take the blueprints

I'm putting the system architecture on GitHub. Not my personal data, but everything you'd need to build your own version: the CLAUDE.md structure, coaching principles, session type definitions, file conventions, prompt doc templates, the multi-Claude handoff pattern, and example project file structures.

This is what AI-native productivity looks like. Not an app someone built for you. A system you build with AI, for yourself, out of plain text files and a good CLAUDE.md. The vault structure is up to you — I'm still figuring mine out. Let me know if you crack it first.