I’ve been using Claude Code a lot. And like everyone else, my CLAUDE.md files kept growing. More context, more instructions, more rules. At some point you’re feeding thousands of tokens on every turn just so the agent knows about your project. Most of it irrelevant to the task at hand.

There’s a concept floating around - the LLM Wiki. A personal knowledge base where the agent maintains pages, indexes them, logs operations, even does periodic lint passes to find contradictions. Index plus pages, ingest pipeline, dream cycles for consolidation. Pretty compelling idea.

But I looked at it and thought - what do I actually need from this? The index-plus-pages pattern, yes. The two-tier loading, absolutely. The rest - logs, lint, ingest operations - felt like machinery I’d build and then not maintain. I wanted the distilled version. The minimum that actually works.

What a card is

A card is a markdown file. No frontmatter, no schema, no special format. A heading, a one-liner, and a body. That’s it. They live in a flat cards/ directory.

cards/
  auth.md
  billing.md
  search-index.md
  magic-link-login.md
  postgres-over-mongo.md

Each card is self-contained. No “see also card X” links. If two cards share context, hoist it into a third card. The point is that loading one card never forces you to load another.

The two-tier trick

This is the core of the LLM Wiki that survived the distillation. An always-loaded surface and lazy-loaded details.

The CLAUDE.md stays slim. A two-line overview of the project and an index of cards. Each index entry is one line - the card name and a trigger describing when to load it.

# My Project

Widget platform for enterprise dashboards.

## Cards
- [auth](cards/auth.md) — when touching login, sessions, or permissions
- [billing](cards/billing.md) — when touching payments, subscriptions, invoicing
- [search-index](cards/search-index.md) — when touching search or indexing pipeline
- [postgres-over-mongo](cards/postgres-over-mongo.md) — when questioning the database choice

The agent reads the index on every turn. Costs maybe 10 lines. Then it matches triggers to whatever task it’s working on and loads only the relevant card. One card, maybe two. Not the whole knowledge base.

That’s the whole trick. A cheap index that’s always in context, and self-contained cards that are loaded on demand. Two tiers.

Why natural language is enough

I spent some time thinking about whether cards need structure. Types, categories, required fields. Then I realized - they don’t. The agent reads natural language just fine. A card that says “this feature expects a user_id in the session and writes to the audit_log table” is as effective as a typed schema. Probably more effective, because you can add the why.

There are three rough kinds of cards - domain cards (a bounded slice of the system), feature cards (a specific capability), and decision cards (why we chose X over Y). But that’s a guideline, not a format. The card doesn’t need to declare what type it is. The content makes it obvious.

The only real rule is self-containment. One card, one load, no chains.

The rocket launch mindset

There’s a way of working with AI agents where you build up context slowly. Prompt by prompt. “Here’s the project.” “Now here’s the module.” “Now here’s the function I want you to change.” Feeding it pieces until it has enough to act.

I don’t think that’s the right approach. I think the project should be ready before the agent starts. Like a rocket launch - everything is prepared, checked, in place. Then you give the agent a task and it executes. No warmup, no hand-holding, no five prompts of context building.

Cards are part of that. The project is pre-documented. The contracts are written. The index is there. When the agent gets a task, it reads the index, loads the relevant card, and has everything it needs to act. First prompt, real work.

It’s two different modes of working. Preparation mode and execution mode. The agent can help in both - writing cards, updating the index, keeping things current. But the point is that a well-prepared project needs very little preparation. Duh. You sit down, give it a task, and it goes.

What it actually looks like

The CLAUDE.md is maybe 15 lines. The agent loads it instantly. On most turns, it doesn’t need any cards - the overview is enough to stay oriented. When it does need context, it loads one card. Maybe 50-80 lines. Then it’s done.

Compare that to a 400-line CLAUDE.md loaded on every single turn. Or a wiki where the agent follows three links before it even starts working. Cards sit in between - structured enough to stay organized, minimal enough to stay cheap.

Can cards go stale? Sure. But the agent can maintain them too - updating the index, keeping cards current as it works. That’s the preparation mode thing. Next time you sit down, the project is already ready.

Sometimes the distilled version is the one you actually use. There’s an example project on GitHub if you want to see the pattern in action.

Want to try it? Tell your agent:

Add cards as described here https://ai.memention.net/cards