OpenKnowledge

Supporting the Open Knowledge Format

Start a knowledge base that already follows Google's Open Knowledge Format, so any OKF tool can read it later. You get the right setup out of the box, and you're still free to write however you like.

OpenKnowledge ships a starter pack named okf that scaffolds a knowledge base conformant with Google's Open Knowledge Format (OKF) from the first commit — without enforcing anything. You get a portable, OKF-ready bundle out of the box, and you stay free to author however you like.

OKF here means Google's Open Knowledge Format — a vendor-neutral file-format spec (a directory of markdown files with YAML frontmatter), announced by Google Cloud in June 2026. Read the OKF v0.1 spec.

The point is portability from day one: a knowledge base you can hand to any tool that reads Google's Open Knowledge Format, already conformant so indexing, exporting, or sharing with an OKF-aware consumer later is never a migration project. And the discipline is pre-populated, not enforced — you get conformance without the editor linting or blocking you.

What the pack seeds

In an initialized project (ok init first), pick Open Knowledge Format in the starter-pack picker (behind Show more), or run ok seed --pack okf. It scaffolds:

PathPurposeTemplate
concepts/Durable ideas and definitionsconcept
references/External sources and citationsreference
notes/Working notes and observationsnote
welcome.mdA real typed document (type: Document), so a strict OKF consumer has something to accept— (seeded file)
index.mdReserved OKF navigation hub— (reserved)
log.mdReserved OKF change history— (reserved)

Each of the three content folders (concepts/, references/, notes/) ships its own template, so new docs start with the right type and section skeleton already in place — you never hand-set the frontmatter. The conventions also ship as a project-local skill (okf-knowledge-base) installed alongside the seed, so your agent learns the pack's discipline without a hand-written CLAUDE.md. Like every seeded file, that SKILL.md is committed to your repo and editable; see Skills and what OpenKnowledge writes to disk.

Conformance is pre-populated, not enforced

This is the key design decision. OKF asks exactly one thing of every non-reserved document: a non-empty type in its frontmatter. Reserved index.md / log.md stay frontmatter-free, and links are standard markdown.

The pack bakes those habits into the seeded content and documents them — but it changes nothing about how OpenKnowledge itself behaves:

  • OpenKnowledge's native frontmatter schema stays open-shaped.
  • Nothing is linted for OKF conformance.

So three habits are all it takes to keep the KB handable to a strict OKF consumer as it grows:

  1. Every non-reserved doc carries a non-empty type.
  2. index.md / log.md stay lowercase and frontmatter-free.
  3. Links use standard markdown ([text](./path.md)).

OpenKnowledge also accepts [[wiki-link]] shorthand as a native superset, but nothing normalizes it to standard links — seeded content uses standard links so the bundle is conformant as-is.

Cadence

Three habits keep the bundle handable to a strict OKF consumer as it grows. The seeded templates already do the first; the rest is light discipline, not enforcement.

WhenDo
Creating a docUse New from template — it sets type for you
Reserved filesKeep index.md / log.md lowercase and frontmatter-free
LinksUse standard markdown links; [[wiki-link]] shorthand stays as written
Handing it offNothing special — the bundle is conformant as you go

Further reading