Turn a Karpathy-Style Wiki into a Reusable Skill

The past couple of days have been a real struggle to get this skill working.

I started with Opus 4.6. I burned through more than $20. Still couldn’t get it to work. I even wondered if the new model that dropped on the morning of April 8, 2026 had sucked up all their compute. Otherwise, how could it understand one moment and then go off track the next?

Later I switched to Codex, and I did manage to build it.

But a new problem emerged: building it doesn’t mean it works reliably.

Especially when you start testing it seriously, it would occasionally ignore instructions and make changes on its own, which drove me crazy.

So in this article, I don’t just want to say “I built a skill, feel free to download it.”

I want to make something else clear: how to actually implement the LLM Wiki method Karpathy proposed in an Obsidian vault.

The previous chapter covered the method. This chapter is about practice.

If you want to download the current sanitized version of my skill, here’s the link:

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

I’ve already removed the API keys, local paths, etc. But let me say this upfront: don’t copy it verbatim.

You can learn from this method. You can also modify this skill. But don’t expect it to work out of the box. Everyone’s note vault is too different.

What I built is not “AI organizing my notes,” but “AI doing my bookkeeping”

Let’s first revisit Karpathy’s Gist.

Original link:

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

The core idea is actually simple:

Most people currently use LLMs for document processing via RAG: dump a bunch of files in, and when querying, retrieve and generate answers on the fly.

That works, of course.

But the problem is that it’s all ad hoc.

Ask once, assemble once. Ask again, start from scratch. No accumulation.

So he proposed an intermediate layer: instead of assembling answers on the fly for each query, continuously maintain a Wiki.

When I read this, my first reaction wasn’t “this is cool.”

It was: isn’t this exactly the kind of task Obsidian is best suited for?

Because Obsidian is inherently a local Markdown file vault.

The Wiki Karpathy describes is essentially a collection of Markdown files.

The underlying format is almost identical.

The difference is:

Previously, you manually maintained backlinks, topic pages, and structure pages
Now AI helps you with this “bookkeeping” work

Note: bookkeeping, not thinking.

I increasingly agree with this.

Reading articles, making judgments, writing your own opinions—these are still for you to do.

But tasks like completing backlinks, normalizing author names, checking formatting, and refreshing derived pages are essentially grunt work. AI can handle them.

How I Implemented Karpathy’s Three-Layer Structure in Obsidian

The most important part of Karpathy’s method is the three layers:

Raw Sources
The Wiki
The Schema

My obsidian-wiki skill is also built around these three layers.

First Layer: Raw Sources

In my vault, this layer consists of:

01-Notes/
04-Output/

That is, raw collections, raw notes, and articles I’ve written.

I keep this layer very restrained.

Its only responsibility is to preserve the original content.

I don’t let it take on extra functions.

I don’t mix in derived content.

I don’t let a raw article become half topic page, half index page.

Because once mixed, it becomes hard to maintain.

This is one of the deepest lessons I learned while building this skill: the cleaner the raw layer, the easier everything else becomes.

Second Layer: The Wiki

This layer is separate in my vault:

01-Notes/wiki/

This holds the structural layer derived by AI, such as:

Author pages
Topic pages
Index
Log
Backlink directory

In other words, the original text remains the original text.

The Wiki is the Wiki.

The two layers are separate.

This sounds trivial, but it’s actually very important.

Because if you don’t separate layers, every time AI organizes, it tends to make the original text messier.

Today it adds a topic block.

Tomorrow it inserts an index.

The day after, it adds an auto-generated summary.

Eventually, the whole vault looks like a room that’s constantly being tidied but gets messier.

Third Layer: The Schema

Many people overlook this layer.

Karpathy mentions schema in his original post. My understanding is: you need to tell AI what the vault should look like.

In my case, this includes:

SKILL.md
A bunch of scripts/
Frontmatter conventions
Constraints on how authors and topics are written
Process constraints for lint and ingest

For example, I now enforce:

Authors must be in backlink format
Topics must be a backlink list
Author pages and topic pages can only go in 01-Notes/wiki/
00-Inbox/ is only a processing inbox, not directly mixed into the Wiki
Raw articles no longer contain derived paragraphs

You’ll find that what makes the skill work isn’t how beautifully the prompt is written. The real key is that these constraints are established first.

Translating the Three Actions into Runnable Workflows

Karpathy also has three core actions:

Ingest
Query
Lint

I followed the same approach.

In terms of the actual workflow in this skill, it looks like this:

Ingest: wiki_lint.py --preflight + ob_shuanglian.py suggest/apply + wiki_ingest.py
Query: First read wiki/index.md, authors/*.md, topics/*.md, then go back to original text for details
Lint: wiki_lint.py, wiki_migrate.py, wiki_build_skeleton.py

Ingest: Check new content before adding it to the vault

I don’t let AI “see an article and improvise” right away.

My current workflow starts with a preflight check.

First check if the frontmatter is correct.

Then check for historical contamination.

Then make backlink suggestions.

After user confirmation, actually apply.

Finally, refresh the Wiki derived layer.

Why go through all this trouble?

Because the models have taught me many times.

If you don’t add these guardrails, it will eagerly “make decisions” for you.

The problem is, its decisions may not be what you want.

So I added strong confirmation gates.

Don’t let it write topics arbitrarily.

Don’t let it apply backlinks directly.

Don’t let it decide on author aliases on its own.

Give suggestions, I confirm, then write.

This may seem less efficient.

But with a knowledge base, the biggest fear isn’t slowness; it’s quietly writing something wrong.

Query: Not fishing in the sea of original text, but reading the Wiki layer first

For queries, my approach is not “search the entire vault and hand it to AI for summarization.”

Instead, it first goes through:

wiki/index.md
authors/*.md
topics/*.md

Let AI look at the structured layer first.

When necessary, go back to specific articles for details.

The benefits are clear:

It doesn’t have to reassemble from scattered original text every time.

Instead, it answers from an already organized layer.

This is closer to what Karpathy means by “accumulation.”

Lint: The most important and most underestimated step

Many people focus on Query when they see LLM Wiki.

But the more I work on it, the more I feel that Lint is where the real value lies.

Because once the knowledge base grows, your biggest headache isn’t “can’t get answers,” but:

Frontmatter is messy
Author names are inconsistent
Topics are scattered
Historical structures remain in original text
Derived pages grow increasingly distorted
The same concept appears under several different names

If you try to maintain these manually, it’s maddening.

And you won’t be able to keep it up.

This is exactly what AI is best at.

Not understanding the world for you.

But patrolling the vault, reconciling, finding dirty data, and filling in cross-references.

That’s why Karpathy’s term is so apt: bookkeeping.

The Real Pitfall Isn’t the Model, It’s My Old Note Vault

This is also what I most want to warn everyone about.

Many people read an article like this and instinctively think:

“Oh, I can just download the skill, install it, and AI will manage my knowledge base.”

That’s not the case.

The biggest challenge with this skill isn’t the prompt, the scripts, or even the model.

It’s that I have too many old notes, and their formats are inconsistent.

When I run lint now, here’s the scale I see:

Article-type Raw Sources: 457
Total Raw files: 833
Pending queue: 249
The backlink directory already has 471 topics

Think about that volume.

This is no longer about “organizing a few notes.”

It’s more like taking over an old system with a long history and no consistent standards.

Some articles have full author names.

Some have aliases.

Some topics are very detailed.

Some are very scattered.

Some old files still contain remnants of previous structures.

So I became increasingly certain of one thing:

If you want to build an LLM Wiki, the first step isn’t to let AI take over. The first step is to clean up your vault to a state “worth taking over.”

Otherwise, the more diligent AI is, the more it spreads the mess.

So What Extra Things Does This Skill Actually Do?

If you only read Karpathy’s original post, you’d think it’s a very elegant methodology.

But when actually building it, I found many engineering details to fill in.

For example:

Frontmatter standardization
Author alias normalization
Enforcing backlink format for topics
Completely separating raw and derived layers
Using 00-Inbox/ as a processing inbox
Adding user confirmation gates at key steps
Breaking down the workflow with scripts like lint, migrate, ingest

It’s not that Karpathy didn’t think of these.

It’s that his Gist describes a pattern, not the specific implementation for your vault.

When actually implementing, you must fill in this layer yourself.

My current obsidian-wiki skill is essentially doing this:

Translating an abstract pattern into a workflow that runs on my own Obsidian vault.

So if you download it, the most important thing to learn isn’t “copy my directory structure.”

It’s to understand why I layered things this way, why confirmation is needed here, why lint is done here, why auto-apply isn’t used here.

If You Want to Do This Too, Modify These Things First

I’ve put the sanitized version on my blog’s download page:

https://blog.discoverlabs.ac.cn/downloads/obsidian-wiki-skill/

But after downloading, the first thing isn’t to run it.

It’s to modify it.

At least check these things:

Is your vault path the same as mine?
Is your 01-Notes/, 04-Output/, 00-Inbox/ structure the same?
Are your frontmatter fields consistent with mine?
Are your author names and topic names already fairly consistent?
Do you want to keep my “suggest, confirm, then write” workflow?
If the scripts involve APIs, have you replaced them with your own keys?

The version I released has already sanitized API keys and local paths.

After you get it, you must adapt it to your own environment.

And I still recommend: don’t treat my method as a template, just as a reference.

If your vault is mainly reading notes, the rules may differ from mine.

If your vault is mainly project notes, the granularity of topics will differ.

If your vault is still in the “collect first, organize later” phase, you probably shouldn’t focus on Query first, but should get Lint and Ingest running smoothly.

So don’t copy verbatim.

Modify based on the approach, that’s more reliable.

Summary

By the end of this article, my own feeling has become clearer.

Karpathy’s proposal is not just an idea that “AI can help you organize your knowledge base.”

Its real value is that it redefines the division of labor between humans and AI in knowledge management.

Humans handle judgment.

AI handles bookkeeping.

The more I work on this, the more I believe in that statement.

What I learned today:

The key to Karpathy’s LLM Wiki is the three-layer structure and three operations, not a single prompt
The key to skills like obsidian-wiki isn’t “can it summarize,” but whether it can separate Raw Sources, Wiki, and Schema
In practice, Lint is often more important than Query, because historical data cleanup is the bulk of the work
The more old notes and the messier the format, the less you should directly copy someone else’s skill
Downloading a skill is easy; the real challenge is adapting it to fit your own knowledge base

Key takeaways:

AI is best suited for bookkeeping, not thinking for you
Raw and derived layers must be separated, otherwise the knowledge base gets messier the more you organize
User confirmation gates are not extra steps; they are necessary guardrails to prevent AI from acting on its own
Standardize formats first, then talk about automation; if you reverse the order, you’ll suffer later
This skill can be modified, but it’s not recommended to copy it as-is