DDimosthenis Avgeris

LLM Wiki Framework with Claude Code

Using Claude Code as a long-term knowledge manager: an Obsidian wiki that Claude maintains from raw source documents, plus the ticket, design, and meeting workflows built on top.

#product#business#AI

This setup was built and is maintained with Claude Code (Sonnet 4.6), which acts as both the builder and the long-term knowledge manager.

The Problem#

I have too many contexts running at the same time.

Head of Product at instacar. Personal blog. Side projects.

Each one has its own documents, decisions, meetings, and accumulated thinking. And for a long time, all of that lived in a mess: raw files, notes, random PDFs, Linear tickets I’d forget about, and a memory that’s just… not reliable enough.

The real issue isn’t that I don’t have information. It’s that I can’t find it, reuse it, or build on it.

So I built a wiki.

The Pattern: LLM Wiki#

The concept is based on Andrej Karpathy’s LLM Wiki idea: instead of using an AI as a one-off question answering machine, you use it as a long-term thinking partner that maintains a structured knowledge base on your behalf.

The idea clicked immediately.

I’m not trying to outsource my thinking. I’m trying to make sure that what I already know doesn’t get lost.

The Structure#

Everything lives in one Obsidian vault. The layout is simple:

raw/           -- source documents, never touched by Claude
wiki/          -- clean, maintained pages written by Claude
wiki/index.md  -- the table of contents, always kept current
wiki/log.md    -- append-only record of everything that changed
log/           -- daily summaries when I want them

The raw/ folder holds the source material: PRDs, meeting notes, exported CSVs, blog posts, spec docs. Nothing in raw/ ever gets modified.

The wiki/ folder is where knowledge lives in a usable form. One page per concept, company, product, or person. Every page has a standard header: summary, context, sources, last updated. Every page links to related pages using wiki-links.

The wiki/index.md is the entry point. Claude reads it first on every session before touching anything else. It’s the map.

The wiki/log.md is the changelog. Every time something gets created, updated, or deleted, it gets logged. This means I can always trace where things came from and what changed.

How Ingestion Works#

When I drop a new document into raw/ and ask Claude to ingest it, the process is consistent:

  1. Read the source document fully.
  2. Briefly discuss key takeaways with me before writing anything (I don’t want pages created I didn’t sanity-check).
  3. Create a summary page in wiki/ named after the source.
  4. Create or update concept pages for each major idea, entity, or decision in the document.
  5. Add wiki-links connecting related pages.
  6. Update wiki/index.md and wiki/log.md.

One document can touch many wiki pages. A product spec might create a new initiative page, update a product page, and add a note to the company overview. That’s the point. Knowledge should connect.

The BLUF Habit: Bottom Line Up Front#

One useful writing discipline I’ve adopted is BLUF: Bottom Line Up Front.

Every document, every update, every question should lead with the conclusion. Not “here’s the context and eventually the answer” — just the answer first, context second.

It sounds simple but it changes how you think before you write. You can’t BLUF something you haven’t figured out yet.

I write all my raw source documents this way now. It makes ingestion cleaner and the wiki pages sharper.

The Tools#

Claude Code (CLI) is the main tool. It runs in my Obsidian vault directory, reads and writes files directly, and has the full CLAUDE.md as persistent instructions. This is the part most people miss: the system prompt isn’t a one-time setup. It’s a living document that tells Claude exactly how this wiki works, what the folder structure means, how pages should be formatted, and what it’s not allowed to touch.

Linear MCP is connected so Claude can pull live ticket data from my Linear projects. When I’m updating a wiki page about an active initiative (like the kill-pipedrive migration or the UK launch), Claude can pull the current ticket status directly rather than me copying it manually. The wiki reflects what’s actually happening, not what was true when I last updated the document.

Obsidian is just the file system with a nice UI. The wiki-links ([[page-name]]) render as actual links in Obsidian’s graph view. I can see how concepts connect visually. It’s useful for navigation even if most of my actual work happens through Claude Code.

Antigravity is the second tool in the stack — agent-first, built on VS Code with Gemini 3.1 Pro. Designed for people who don’t live in the terminal: PMs, designers, solopreneurs. The key differentiator is multi-agent parallel execution: one agent writes, one tests UI, one refactors — all simultaneously. No terminal needed. For visual, browser-native agentic work, this is the right tool. Claude Code and Antigravity serve different strengths — both belong in the workflow.

Claude Code Product Skills#

Beyond the base LLM, Claude Code has pluggable “skills” that add specialized capabilities. These are invoked with the / command directly in the terminal.

Available skills in this setup:

Type / in the Claude Code terminal and select from the list, or type /skill-name directly.

What’s Actually in the Wiki Now#

After a few sessions of ingesting documents:

Personal project sections exist but are still mostly empty. That’s fine. The wiki grows when I have something worth capturing, not on a schedule.

What I’ve Learned So Far#

The index is everything. If wiki/index.md is messy or out of date, the whole system degrades. Claude reads it first every session. If it’s wrong, the session starts wrong.

Raw files should stay raw. Early on I was tempted to clean up source documents before dropping them in. Stopped doing that. The wiki is the cleaned-up version. Raw files are evidence.

The log is underrated. wiki/log.md looks like admin overhead but it’s genuinely useful. When I come back to a topic after a few weeks, the log tells me what changed and when. It’s the version history you don’t have to think about.

Context scoping matters. The CLAUDE.md instructions tell Claude which folder to read based on what I’m asking about. If I ask an instacar question, it doesn’t load blog pages. This keeps sessions focused and prevents the model from mixing contexts it shouldn’t.

Workflow Impact: First Week Data#

I’ve been using this system for one week. Here’s what’s changed:

Time savings:

Cognitive load & context switching:

(These metrics align with research from knowledge worker studies: Atlassian found that the average knowledge worker spends 9.3 hours/week searching for information or dealing with its absence. Zappi’s survey found context switching costs 40% of productive time. This system attacks both.)

Knowledge reuse:

System health:

The biggest win: I stopped re-discovering the same insights. The wiki became a second brain that I actually trust to remember things I’ve already figured out.

Meeting Digestion Workflow#

One of the highest-ROI use cases I’ve found is turning meeting notes into structured, context-rich Linear tickets.

The process:

  1. Capture the meeting — I record meetings using Otter.ai (auto-transcription) or paste meeting notes directly into a raw file if it’s a quick sync.
  2. Ask Claude to digest — I drop the transcript or notes into raw/meetings/ and ask Claude Code to:
    • Summarize the key discussion points
    • Extract action items and decisions
    • Identify which existing wiki pages are relevant (linking them)
    • Flag which items are QA/small improvements vs. structural work
  3. Claude creates Linear tickets — For each action item, Claude creates a ticket with:
    • Clear title based on the action, not the meeting
    • Description that includes context: why this was discussed, what problem it solves, who needs it
    • Links to related wiki pages and existing Linear issues
    • Initial estimation (if it’s small triage work)
    • Proper labeling (QA, triage, feature, etc.)
  4. Context is everything — This is the key difference. A ticket created from a meeting usually loses the “why.” With Claude’s digestion, the ticket includes:
    • What led to this discussion (linked wiki pages about the product or user segment)
    • What the decision was and alternatives considered
    • Who should be involved (inferred from attendees and wiki knowledge)

Use cases:

Result: Tickets that actually have context make it through implementation correctly. I spend less time in back-and-forth asking “why is this a priority?” because Claude already added that to the description.

The Ticket Template#

Every ticket created through this system is a complete document, not a placeholder. The standard structure:

The template is not aspirational. Claude fills it from wiki context + the MCP Linear connection. Ticket quality is determined by how well the wiki is maintained.

Live Example: INS-4808#

From a vague ask to a fully specified ticket.

The ask: “We need calendar links in the ARM service appointment email”

The output (INS-4808):

The ask was two sentences. The ticket was two pages. This is what wiki context + PM skills + ticket template produces together.

Design System: From Figma to Machine-Readable#

The design system becomes an instruction manual for AI when you structure it as a file Claude can read.

The process:

  1. Export design tokens from Figma (instafleet design system)
  2. Structure them into a DESIGN.md file
  3. Drop DESIGN.md into the project root
  4. Claude reads it before generating any UI

What DESIGN.md contains (real example from instafleet, 877 lines):

Why it matters:

Without DESIGN.md: Claude has no Figma access. Engineer looks up the wrong screenshot. Email gets #2563EB instead of #3B82F6. Inconsistency compounds across every module.

With DESIGN.md: Colors, typography, and component specs are atomic and reproducible. New designers onboard by reading one file instead of reverse-engineering Figma. Engineers stop guessing. QA stops flagging “button color wrong” issues.

This is about making consistency a system property, not a willpower problem.

The Full Stack#

LayerToolReal Example
Agentic IDEClaude Code (terminal + VS Code extension)Terminal edit → git commit → test
Visual IDEAntigravityMulti-agent parallel UI/test/refactor
TicketsLinear + MCPRead INS-4808, update status, link related issues
PM Frameworks/user-story /prd-development /jobs-to-be-doneTurn one idea into acceptance criteria
DesignFigma tokens → DESIGN.md → wireframesColors #3B82F6, typography M 14, buttons via token lookup
Knowledgeraw/ → wiki/ → daily logsbooking.md links → subscriptions.md links → arm.md

How Knowledge Compounds#

The system gets smarter the more you use it.

First ask takes research time. Next ask is instant.

What’s Next#

Adoption path — four phases, start small:

  1. Install — Claude Code + VS Code extension. Set up raw/ + wiki/.
  2. Ingest — Add first project source. Run first ticket.
  3. Design — Extract Figma tokens. Create DESIGN.md. Generate first wireframe.
  4. Scale — Add Antigravity for visual agentic work. Add PM skills.

Pick one project, add one source, run one ticket session. The compounding effect only shows up after month two — so the goal is just to start.

Longer term: consistent daily logs in log/, a dashboard view for wiki health (orphan pages, most-linked concepts, pages updated today), and team-wide adoption.

TL;DR#

Source documents go in raw/. Claude turns them into connected wiki pages in wiki/. wiki/index.md is the map. wiki/log.md is the changelog. Claude Code runs the whole thing from the terminal with a persistent CLAUDE.md as the system prompt.

The goal isn’t a perfect wiki. It’s a wiki that’s good enough to make my thinking compound instead of reset.

Keep iterating and stay curious.

License

CC BY-NC-SA 4.0 This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Related Posts