In the previous article I described how AI lowers the barrier to trying new things. It ended on a sentence I'm cashing in here: for that to hold up over time, it needs one constant – context.
Anyone working with several projects and an AI assistant knows the problem: in every repo I explain anew how I name things, what my layer architecture looks like, why I deliberately don't use this one library. The decisions were made long ago. But they live in my head, scattered across repos, and the assistant only ever knows the slice it currently sees.
So I started putting that knowledge in one place where both I and Claude can find it.
Why Outline – and why self-hosted
The choice fell on Outline, self-hosted on its own subdomain. Three reasons tipped the scales.
First: I want to keep my data with me and not depend on a vendor. A knowledge store that all my decisions flow into over the years is exactly the kind of asset you don't want in someone else's hands.
Second: full data export, any time. If I want to move to a different system tomorrow, I take everything with me. No lock-in, no hostage situation.
Third: self-hosting opens up better options later – for instance my own RAG, should I ever want to go deeper into searching across my own body of knowledge. I don't need it right now. But the door is open, and that's worth the effort to me.
The cookbook – the heart of it
Separate from the individual projects sits its own collection: the cookbook. Cross-project, generic, and that's exactly what makes it valuable. This is where it says how I build, regardless of which product I'm sitting at right now.
Roughly, it's split into a few areas:
- Conventions – naming, code style, docblocks, git commits, markdown, package manager, writing style. The boring but decisive things you'd otherwise re-discuss three times per project.
- Backend – layer architecture, a unified API error format, test strategy, migrations and indexes, i18n, async jobs and idempotency.
- Frontend / mobile – feature-first architecture (
core/,shared/,features/), design system, forms, networking, state, routing, storage, styling, testing. - Deployment – my standard setup with Caddy as the edge and a Hetzner VPS.
- Templates – an ADR template and a
RULES.mdas a project starting point.
Two entries I particularly like. One is roughly titled "deliberate non-decisions": documented things I intentionally don't do or don't use, including the reasoning. That's often more valuable than the positive list – it stops an assistant (or myself in six months) from digging up an idea I discarded long ago.
The other is an "AI workflow" area with a pattern I call "spec-as-outline": the spec lives in the wiki, not as a loose prompt fragment.
What an entry looks like
The entries are short, opinionated, and come with reasoning. Not a textbook, but decisions. Here's an example harmless enough to show – the rule on non-null assertions in TypeScript:
At the top, the essence as a single rule. Below it, a small decision table: when do I use optional chaining (?.), when an assertion (!.), when an explicit guard helper instead. And then two or three examples, cleanly split into "legitimate" and "smell".
// legitimate: value is guaranteed present by prior logic
const user = users.find(u => u.id === id)!
// smell: the assertion hides an unchecked nullable
const name = response.data!.user!.name
That's the level the cookbook operates at: granular enough that a concrete decision comes out, brief enough to read in ten seconds.
One collection per project
Alongside the cookbook, every project gets its own collection. At least one is fully maintained right now. The structure is deliberately always the same:
"About the product", "concepts & fundamentals" for the domain knowledge, "architecture & tech" for authorization, API and tech stack, project-specific "conventions", a "data model" organized by sub-domains, "processes & workflows", and "roadmap & decisions" – the latter including ADRs for the deliberate architectural choices.
What matters to me here is only the structural level: a clearly organized place where the knowledge about one product lives completely. What it says in terms of content stays between me, the team and the product.
How Claude accesses it – and why it saves tokens
Access runs through the official Outline MCP server. Set up, wired in, done. What pleasantly surprised me: token consumption doesn't rise noticeably from it. Claude doesn't constantly fetch half the wiki, but targets what it needs.
A pattern I built for myself in one project helps here – and I'm describing it only as a concept, not as a template to copy. A small, config-driven docs-sync tool pulls a local snapshot from the Outline wiki into the repo: a few markdown files like cookbook.md, conventions.md or models.md under spec/. That keeps the most important info available locally, so it doesn't have to be fetched fresh via MCP on every question.
Only when I really need details on a specific entry does it load one document via MCP on demand. The local snapshot is the fast-access layer, MCP the depth when needed. As a bonus, the tool can generate a Mermaid ER diagram from the data-model docs and pull a backup via ZIP export.
That's the pragmatic variant. The obvious next step – eventually adding RAG via a custom MCP – is in the back of my mind, but I've deliberately not built it. I don't need it right now, and the simplest system that works wins.
The moment it got magical
The real payoff came with the first screen designs for one of my products.
I had design drafts generated, with a prompt that – I know for certain – did not contain certain ideas. Yet they showed up in the result. Detailed considerations I'd jotted down in the wiki at some point and had long lost from active memory found their way into the designs. Not because I'd prompted them, but because the MCP context brought them along.
My first thought, honestly, was just: magical.
And that's exactly the point of this whole setup. It's not about the assistant transcribing my notes. It's about it bringing in knowledge that I forgot or left out of the prompt. The wiki becomes a second memory the AI accesses directly – and that compensates for precisely the human weakness of not thinking of everything in a given moment.
This isn't a finished system, and it isn't for everyone. It only starts to pay off once you make the same decisions across several projects and grow tired of explaining them over and over. From that point on, though, every entry you write down cleanly once pays in again and again – in consistency, in speed, and in the oddly reassuring certainty that the AI knows more about my product than fits into the current prompt.
I write the cookbook for myself. That Claude reads along is the actual trick.