A structured folder that makes every AI session start from where you actually are

I have an ADHD brain. It's full of ideas, patterns, and half-formed connections. What it's bad at is holding context across time. Remembering what I decided last Tuesday and why. Keeping the thread when I switch projects.

As an independent, my time is my most valuable asset. Admin overhead and context-switching were quietly eating it. I needed a system that worked with how I think.

For a long time I patched this with tools. Notion for admin and planning. ChatGPT Projects when I wanted an AI that remembered things. Both helped. Neither solved it.

The problem wasn't the tools. It was the format. My context was trapped inside their interfaces.

Then I came across Teresa Torres and her method for keeping AI context structured and persistent. That was the spark. I took the concept, figured out what it was actually solving for, and rebuilt it around how I think and work.

What I landed on isn't a productivity system. It's context engineering. A structured folder that holds everything an AI needs to work with me at full speed.

I build it in Obsidian and use it with Claude Code.

What the vault actually is

The vault is a context layer, the operating system around the question. It answers one question: what does an AI need to know about me to be a useful thinking partner?

The answer is quite a lot.

• Who I am and what I do
• How I write and communicate
• What I'm working on right now
• What decisions I've already made
• How I want specific types of tasks handled

Most knowledge systems stop at information. This one stores reasoning too: decisions made and why, constraints that are fixed, assumptions I'm operating on. That distinction is what makes it a thinking partner, not a filing cabinet.

When that context lives in a structured folder, and an AI can read the folder, you skip the re-explaining. Every session starts from where you actually are.

Claude Code reads plain markdown files directly in the terminal. The same files I write in Obsidian are the files it reads when I'm working. Nothing to sync, nothing to export, nothing locked in someone else's system. Plain markdown means I can take this context anywhere. If I need to work offline I can run it with Ollama. If better tools come along, the vault moves with me.

Same information. Different structure. That's the whole idea.

The structure

The vault has five layers.

Context: who I am, how I work, what I sound like. A writing style guide, brand principles, and a file that describes my values and ways of working. When I ask Claude to write on my behalf, it reads this first.

Skills: reusable instructions. Not notes. Instructions. "Here's how to run a client scoping workshop." "Here's how to structure an article." "Here's how to set up a new code repo." Skills are plain markdown. Claude reads them and follows them.

Agents: system prompts for specialized AI personas. One handles content briefs. Another handles drafting. They're not smart on their own. They're smart because they read the Context layer first.

Projects: one folder per client or project. Brief, decision log, and a context-load file: a reading list that tells Claude which files to read at the start of a session.

Planning: weekly and monthly capacity files. What I'm working on, what's blocked, what's next.

Five folders. Everything connects.

Five folders. Everything the AI needs to work with me is in here.

I have two vaults, one for work and one personal. Same structure, different context. I won't go into the personal one here.

The operational layer

The vault is the context layer. But it doesn't stand alone.

I track hours in TIM, a simple macOS app that exports JSON. Client files live in Proton Drive. Project specs live in Notion or GitHub. Each tool lives outside the vault, but the vault links to all of them.

That's the distinction: the vault isn't a file dump. It maps where things live and what they mean. It's the graph that ties everything together.

The vault itself is stored in git. Sensitive data stays out by default.

The vault used to be passive. I'd open it, Claude would read it, and we'd work from there.

Recently I started connecting it outward.

Obsidian Web Clipper now sends research, writing inspiration, and tools I want to try directly into research/inbox with tags pre-set. Nothing lingers in browser tabs. Every Friday morning a GitHub Action reads the inbox, asks Claude to summarize each clip and suggest what it connects to, and posts the digest to Slack. I open Obsidian, make the calls, clear the inbox.

The weekly plan posts to my Slack planning channel every morning at 8am. A GitHub Actions workflow reads planning/this-week.md, asks Claude to write a briefing for today, and posts it. The vault doesn't wait to be opened. It shows up.

Claude can post to Slack mid-session too, via MCP. Decisions, updates, quick notes without leaving the terminal.

Hours and project cross-referencing are still manual. That's next. But the direction is clear: the vault isn't just where context lives. It's becoming the layer that keeps things moving.

How I started

Starting was simpler than I expected.

I used Claude to help me migrate my existing context. I dumped my ChatGPT history, scattered notes, and half-formed prompts from wherever they lived. We structured it together. What had value went into the vault. What didn't got cut.

That process alone was useful. It forced me to articulate things I'd been keeping in my head.

The vault has been improving ever since. Every time I come across something useful from someone else, a framework, a workflow, a way of structuring context, I bring it to Claude. We look at it together. If it amplifies how I work, it goes in. If it doesn't fit, it gets skipped.

Samar Vir Singh's Shannon framework shaped how I think about structuring skills. Stian Selland, a system architect I share office space with, has deepened my understanding of what Claude can actually do. I learn from people around me constantly. I don't copy wholesale. Everything gets filtered through what actually works for my setup.

More recently, David Szabo-Stuban's Alfred has been shaping where I want to take this. Fully agentic personal infrastructure that reasons, not just retrieves. I'm not there yet. But it's showing me what the next layer looks like.

The result is a vault that gets sharper the more I use it. Every skill I add means one less repeated instruction. Every project brief means one less catch-up session.

What it actually changes

Same model. Different context. Radically different capability.

Before: open a chat with an AI, start explaining. "I'm a product designer. I work with early-stage founders. Here's the project..." Ten minutes of setup before you can do any real work.

Now: open Claude Code, point it at the vault, and it already knows. It reads the context layer. It knows the project. It knows what decisions were made last session. We start from where I am.

The ADHD piece matters here, more than I expected.

The old model of working was linear. One task, finish it, move to the next. AI doesn't work that way. You launch something, check the output, correct it, start another while the first runs. You're not executing. You're orchestrating.

ADHD brains do this naturally. The parallel threads, the context-switching, the jumping: not a deficit. It fits.

The harder side is decisions. Too many open variables and I lock up.

The vault handles both. External structure for the things my brain drops. Documented decisions so I don't re-decide what I already decided. The context is there. I just have to move.

Not cured of decision paralysis. But I spend less time in it.

I'm not fighting my brain anymore. It turns out AI caught up to it.

What to steal

You don't need to build the full system. Start with three files.

context.md: who you are, what you do, what you're working on right now. One or two pages. Update when things change.

CLAUDE.md: a config file that tells Claude Code how to read your vault. What the folders mean. How you want it to behave.

A projects folder: one file per active project. Brief, status, key decisions. Keep it current.

Three files is enough to start. Everything else comes later.

That's enough. Claude can read those three files and be a significantly better thinking partner than one that knows nothing about you.

One more thing: you probably have context scattered across ChatGPT history, Notion pages, old notes. Start there. Give it to Claude and ask it to help you structure it. You'll throw a lot away. What remains is your first vault.

Add skills when you find yourself repeating the same instructions. Add agents when a workflow gets complex enough to need a specialized persona. Connect your operational tools when you're ready.

The meta moment

This article was written from inside the vault.

The idea had been there for weeks, but a Claude Code meetup changed that. I met Yook Shee and we spent the evening comparing notes on how we each use AI day-to-day. He went home and built his own version, and more people asked about my setup after that.

When I sat down to write, I opened Claude Code, loaded the vault context, and started working through the draft.

Claude knows my writing voice. It knows the angle I'd already mapped out. We didn't start from zero. We picked up the thread.

In 2021, I wrote an article called "Designing for Data Journeys." The core idea was simple: designers know how to map user journeys, and we can apply the same methods to data. Treat data like users. Map how it flows, where it breaks, where it gets duplicated or lost. Design the journey, not just the interface.

That article was about a gap I kept seeing in organisations. Teams cared about user experience but had no visibility into how their data actually moved. Design thinking was the tool to fix that.

I'm seeing the same gap now, but with AI.

The speed problem

Vibe coding is fast. Tools like Lovable, Cursor, and Claude Code let you go from idea to working prototype in hours, not weeks. You describe what you want, the AI builds it, and you iterate from there. For someone like me who works across design and engineering, this has been transformative. I can test ideas, build MVPs, and validate approaches at a speed that wasn't possible two years ago.

But speed creates its own problems.

The cost of "good enough" has collapsed. You can generate competent UI, functional code, decent copy. The floor has risen dramatically. That's genuinely useful. But it also means everyone can reach good enough. And when everyone can ship, the bottleneck shifts.

It's no longer "can we build this?" It's "should we build this, and in what order?" The tool handles execution. What it doesn't handle is structure, sequencing, and decisions about what matters.

That's where things fall apart. I've seen it in my own work and in teams I advise. The AI generates code quickly, but without clear constraints, you end up with something that looks finished but isn't. Features no one asked for. Inconsistent patterns. Logic that works until it doesn't.

Two ways to build with AI

There are really two modes of working with AI tools.

The first is conversational. Chat with the tool, give it a short list, let it propose a plan. This works when you're still figuring things out. Exploring an idea, testing a concept, seeing what's possible. Low stakes, low structure, and that's fine.

The second is structured. You come in with a product definition, user flows, a data model, design constraints, references. You know what you're building and you feed the AI the full context so it can execute with precision.

Same tools, two modes. One starts with a sentence, the other starts with a definition.

Most people start in the first mode and never switch to the second. They keep chatting, keep iterating, keep adding. And the AI keeps generating. The result is a product that grew organically from a conversation instead of being built from a plan.

The first mode is great for exploration. But if you're building something real, something that needs to hold up, you need the second. And that's where design thinking comes in.

What design thinking actually solves here

Design thinking, in the way I use it, isn't about aesthetics or wireframes. It's about asking the right questions before you start building. It's the work that turns mode one into mode two.

Scoping. What's the actual problem? What's the smallest version that tests whether this idea works? Vibe coding makes it tempting to build everything at once because you can. But "you can" is not a reason.

Sequencing. What order should things be built in? Which decisions block other decisions? AI doesn't know your constraints. It doesn't know that the authentication model affects everything downstream, or that the data structure you pick now will be painful to change later.

Constraints. What are the hard boundaries? Privacy requirements, accessibility standards, performance targets. AI will happily generate code that ignores all of these unless you tell it not to.

Journey mapping. Just like I mapped data journeys in 2021, you can map AI workflows. Where does the AI help? Where does it introduce risk? Where do you need a human to make a decision? Understanding this flow is the difference between using AI intentionally and just letting it run.

How I actually work with this

My workflow has shifted significantly. I work in the terminal, in markdown, and with AI tools that fit into that flow. Not because I'm against fancy UIs, but because the closer I am to the actual structure, the better my prompts are and the better the output is.

Skeleton, then data, then polish. Changing that order is where it breaks.

When I start a project, whether it's a client MVP or a Tuesday hackday with my nephew, the process is the same:

1. Define the problem in plain language
2. Set constraints before writing a single prompt
3. Build in a clear sequence: structure first, then content and data, then design
4. Review what the AI produces against the constraints, not just whether it "works"

Step 3 is where speed and care meet. The structure phase is where AI gives you speed. Let it generate layouts, routes, page shells. That's the obvious stuff. The content and data phase is where you slow down. Data models, user flows, state management. These are the decisions that compound. Get them wrong early and everything downstream is expensive to fix. Design comes last, applied to a working structure, not painted onto a broken one.

Being fast where it doesn't matter and slow where it does. That's not a contradiction. That's the whole method.

In practice, most people skip steps 1-3 and go straight to prompting. The result is fast output with no foundation. It's the equivalent of building a house by starting with the furniture.

Where this breaks down without structure

A few patterns I keep seeing:

Prompting without context. People write prompts that describe features without explaining the problem. The AI delivers exactly what was asked for, which turns out to be the wrong thing.

No constraints, no quality. When you don't specify accessibility, performance, or security requirements, the AI doesn't add them. It optimises for "looks like it works," not "works well."

Iteration without direction. Vibe coding encourages rapid iteration. But iteration without a clear goal is just wandering. Each cycle should test a specific assumption, not just add another feature.

Skipping the map. Teams jump into AI-assisted building without understanding what they're building or why. The same problem I saw with data journeys: no visibility into the flow, no understanding of where things break.

The design layer AI needs

AI tools will keep getting faster and more capable. The gap isn't going to be in execution. It's going to be in the thinking that happens before and around that execution.

Design thinking on one side, AI output on the other. The layer in between is the work.

Designers and people who think like designers are well-positioned here. Not because we make things look good, but because we know how to:

• Frame problems before solving them
• Map journeys and flows
• Work with constraints
• Sequence decisions
• Ask "for whom?" before "how?"

In 2021, I argued that designers should help organisations understand their data. Now I'd say the same about AI. Not as hype, not as a trend to chase, but as a practical layer that needs the same structured, intentional thinking we've always brought to complex problems.

The tools have changed. The thinking hasn't. And now that everyone can ship good enough, the difference between good enough and something people actually want to use comes down to knowing what to build, what to cut, and where to care.

That's not a new skill. Designers have always done this. The tools just made it more visible.

Design methodologies are perhaps most commonly associated with mapping consumer and user journeys and getting user insights. However, we can use these methods for more than that and in contexts that don't necessarily focus on people. Data and data liberation is one of them. Just like mapping the journey of a person who is going through a process to reach a goal, the journey of data can also be mapped out and visualised.

What is a data journey?

Journey maps are a common design tool. They come in all shapes, sizes, and formats. Depending on the context, we can use them in a variety of ways. As designers, we are naturally user-focused, but we look at it in a slightly different way when it comes to data. Instead of mapping the touch points with a user, we focus on the journey of the data itself. In other words — we treat data like users. We can't interview the data, but we can instead observe the data flow to understand how and where it goes.

By mapping this out, we can understand the current state and the pain points in relation to data sources, system owners, target systems, how it is being transferred, where it is being manipulated, duplicated, or enriched. Questions we ask can be: is it API driven and adhering to cybersecurity guidelines? Does it exist in the cloud or on-premise?

This helps us understand the opportunities for data optimisation and improvements in terms of quality and accessibility. We also retrieve insights by interviewing the owner of the data or other stakeholders to understand how they use, manipulate, enrich or distribute the data.

When mapping out data flows, we start with the broad picture and then narrow it down. We look at how data interacts with each other and other systems and applications. By drawing out data flows, we can see if the data is fully optimised, accessible, and in the correct format for users, if it can be decoupled from an application, and if it causes any process bottlenecks.

What's the purpose of designing data journeys?

In today's organisations, there are immense amounts of data floating around. No matter if we're talking about big corporations, B2B, consumer market, or public institutions — they all generate and handle large amounts of data. This data can be a great asset and provide organisations and businesses with valuable information, both commercially and from a more extensive, societal perspective. However, this requires that there is confidence in that data. For there to be confidence, we have to ensure that the data is available in high quality, that it's reliable, and optimised for interpretation and modelling.

By mapping, we can uncover cost-saving opportunities through the removal of redundant, incomplete, or duplicated data, as well as presenting it in an indexed and user-friendly format.

Apart from providing useful information, there are also safety reasons for managing data. When we have complete control and overview of our data, it allows us to eliminate cybersecurity issues, as well as help us comply with GDPR.

By understanding how and what data flows through your application, we can make it safer and more accessible. When mapping data, we can iterate on the design by examining both internal and external data movements. We can design for removing data redundancy, limiting data to be moved or manipulated, and removing any unnecessary steps that data has to pass through.

Unleashing the potential in data

As a society, we're only seeing the beginning of the digital transformation, including data journeys. The data we're producing has an enormous potential that we're only beginning to take advantage of. Much like the industrial revolution changed our world, we're now living the data revolution, which is happening extremely fast and simultaneously across all parts of society.

There are already examples of companies who build their entire business model around data systems — Tesla and Amazon. Data will be at the heart of all business going forward.

It will be in every organisation's interest to learn how to manage complex digital product portfolios and to formulate strategies for data handling that is robust, secure, and cost-effective. Design and designers can, and should, help with this.

And most importantly — it's up to us to make data do good, and to do good for everyone. Dealing better with data is our window into tackling business challenges and social challenges. It can help on the way to make companies, customers, societies, and people thrive.