Google released the Open Knowledge Format last week. It's a simple spec: knowledge lives as markdown files with YAML frontmatter, organized in directories, cross-linked. The kind of thing you'd build anyway if you were storing context for an agent, except now there's a spec so everyone's wiki looks the same.

Andrej Karpathy described the pattern a couple months earlier in his LLM wiki gist. The idea: instead of RAG, where the model rediscovers knowledge from scratch on every question, you have the agent maintain a persistent wiki of markdown files. The knowledge compounds. Google took that pattern and formalized it into a portable, interoperable format.

But here's the thing. The format is just a convention. What makes it useful is when agents actually use it. I wanted my coding agent to default to producing OKF bundles when documenting systems, and to read existing bundles for context. Not because I told it to every time, but because it's how the agent thinks about knowledge by default.

So I built okf-skill, a Claude Code skill that makes agents use OKF naturally.

The problem

When I ask an agent to document a database, it writes markdown. Random markdown. No frontmatter, no cross-links, no structure. Next time I open a different agent session, it starts from scratch. The knowledge I built up is gone.

OKF solves this by giving knowledge a structure. Every concept has a type, a title, a description. Concepts link to each other. Index files let agents navigate progressively. It's the difference between a pile of notes and an actual knowledge base.

But an agent won't use OKF unless you teach it the spec. And the spec, while short, is the kind of thing an agent needs to see before it starts working, not after. That's what the skill does.

What it does

The whole thing is one file: skills/okf/SKILL.md. It tells the agent the OKF conventions: what the frontmatter structure looks like, which fields are required, how to cross-link, how to organize directories, when to create index files. The agent reads it once and then produces conformant bundles from then on.

Ask the agent to document your Postgres database, and it creates an OKF bundle: a directory with index.md at root, subdirectories for datasets and tables, each concept file with typed frontmatter, cross-linked to related concepts, timestamped. Not because you asked for frontmatter specifically. Because that's how the agent now documents things.

"Document my orders table" natural language request SKILL.md: the conventions frontmatter, types, cross-links, indexes OKF bundle typed, linked, timestamped, indexable structured Next agent reads the bundle full context, cross-linked, ready to build on
The skill changes default behavior. The agent produces structured knowledge without being asked for it each time.

What I decided early

Just the skill file. Nothing else. I built a Python module, a CLI, a sample bundle, all of it. Then I deleted most of it. OKF bundles are just markdown files with YAML frontmatter. Agents already know how to read and write those. What they needed was the convention, not a tool. The skill is 78 lines. That's the whole thing.

No manual install instructions. If the skill works as a plugin, that's the install path. Copying files into ~/.claude/skills/ is a workaround, not a feature. I removed it from the README. The plugin install is two commands.

Teach the behavior, not the spec. The skill doesn't dump the OKF specification into the prompt. It gives the agent enough to produce conformant bundles: the frontmatter structure, the cross-linking rules, the directory conventions, the type suggestions. The full spec is a reference, not a requirement.

What I took from Karpathy

The whole OKF concept traces back to his LLM wiki gist. But the principles I applied to the skill itself came from the guidelines he wrote about coding with agents:

Simplicity first. One markdown file. No dependencies, no SDK, no framework. The skill is the kind of thing you could paste into a CLAUDE.md and it would still work.

Surgical changes. The skill tells the agent to only create what's asked for, cross-link what exists, and not over-document. No speculative fields, no boilerplate nobody reads.

Think before you act. The skill tells the agent to check if an OKF bundle already exists before creating one, and to read index.md before drilling into concepts. Don't rebuild context that's already there.

How it ships

It's a Claude Code plugin, same format as context-introspect. The repo has a .claude-plugin/ directory with the marketplace and plugin metadata, and the skill lives at skills/okf/SKILL.md. Installing it: 

/plugin marketplace add catancs/okf-skill
/plugin install okf-skill@okf-skill

Then just ask the agent to document something. It'll produce OKF.

What it looks like in practice

I asked it to document a Postgres orders table. Here's what it created, without me specifying any format: 

---
type:        Table
title:       Orders
description: One row per completed customer order
tags:        [sales, orders]
timestamp:   2026-06-17T00:00:00Z
---

# Schema

| Column       | Type   | Description             |
|--------------|--------|-------------------------|
| order_id     | STRING | Unique order identifier |
| customer_id  | STRING | FK to customers         |

# Related

See customers.md for the join key.

Typed, linked, timestamped. The next agent that opens this bundle reads index.md, sees the structure, and knows exactly what it's working with. No context assembly from scratch. No guessing.

Why I'm sharing this

OKF is new. It'll only matter if people actually use it. The format is the contribution, and tools like this skill are what make it adoption-ready. It's open source, it's one file, and it takes two commands to try.

The code is on GitHub.