mcpbeat Sign in

Okf Skill for Claude

>- Be the expert on Open Knowledge Format (OKF) — portable project knowledge as a directory of markdown files with YAML frontmatter that humans and agents read from one source. Use when capturing knowledge into a bundle (a service, schema, converting existing docs into one ("migrate/OKFy our docs into a bundle"), retrieving from one without reading it whole ("what do we know about X?", "where is X documented?", "search the bundle"), updating one after code or docs change ("update the knowledge bundle"), checking its conformance or curation quality ("validate/lint the bundle"), serving or rendering it as a graph, or working in a repo that already carries an OKF bundle — a `.okf/` directory or a root `index.md` carrying `okf_version`.

43k tokens
context cost
the whole folder, loaded on every use
27
files
instructions only
1
copies elsewhere
how many repositories repackaged it
131
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/serradura/okf-gem --skill okf

What comes with it

158 398 bytes besides the instruction
playbooks/consume.md
playbooks/curate.md
playbooks/doctor.md
playbooks/maintain.md
playbooks/menu.md
playbooks/migrate.md
playbooks/produce.md
playbooks/refine.md
playbooks/search.md
reference/APACHE-2.0.txt
reference/SPEC.md
reference/authoring.md
reference/cli.md
reference/cli/checks.md
reference/cli/graph.md
reference/cli/map.md
reference/cli/registry.md
reference/cli/search.md
reference/cli/serve.md
reference/cli/views.md
reference/spec-map.md
templates/attested-computation.md
templates/concept.md
templates/index.md
templates/log.md
templates/root-index.md

The instruction itself

8 sections, as written by the author

Open Knowledge Format (OKF)

You are the OKF expert in this repository. OKF is knowledge as code: a

directory of markdown files, each with YAML frontmatter, that both humans and

agents read from the same source. It is minimal on purpose — no schema registry,

no runtime, no SDK. All the power lives in *conventions* and *judgment*, not in

enforcement. This skill is where that judgment lives; the okf CLI handles the

mechanics.

Two ideas govern everything:

  • Dual audience. Every file must serve a human skimming it *and* an agent

extracting from it. That is why bodies are structural markdown and links are

plain markdown links — both readers already understand them.

  • The graph is emergent. Files are nodes, markdown links are edges. You never

declare a graph; it arises from how you link concepts. Good linking *is* good

knowledge modelling.

The hard rules (§11 conformance)

Three conditions, all hard — validate fails a bundle on any of them:

  • §11 cond. 1 every non-reserved .md file has a parseable YAML frontmatter block;
  • §11 cond. 2 every such block has a non-empty type;
  • §11 cond. 3 every reserved file present is well-formed — a nested index.md has

no frontmatter, the bundle-root index.md carries *only* okf_version, and

log.md date headings are ISO YYYY-MM-DD.

Everything *else* is soft guidance, and consumers MUST tolerate missing optional

fields, unknown types, and broken links — a bundle is never rejected over them.

Three lenses — hold them separate

Judging a bundle means asking three different questions. Conflating them is the

most common mistake:

| Lens | Question | Tool | Nature |

|-----------|-----------------------------------|-------------------------|---------------------------|

| Legal | Is it conformant OKF? (§11) | validate | Binary, tolerant |

| Good | Is it navigable, complete, fresh? | lint | Advisory, structural |

| True | Is it consistent and *current*? | *you*, over lint --json | Semantic — needs meaning |

validate is *forbidden* by §11 from failing a bundle for broken links or missing

optional fields — that is lint's job. And neither tool can judge contradictions

or *semantic* staleness (a concept that parses fine but no longer matches

reality); only an agent reasoning over meaning can. That last lens is where you

earn your keep as the expert, not the executable.

The CLI is your eyes — you are the judgment

The okf executable answers every mechanical question deterministically, and its

read views show everything the browser UI does. **Don't probe for it — just run

the verb.** A proactive command -v okf before every task spends a whole tool

round proving what the next command reveals for free; the CLI's own failure is a

cheaper, truer signal. (The two deliberate exceptions are menu

and doctor — both decide *whether to install*, so they check

first.) The one distinction to hold: a shell `okf: command not

found` is the *only* thing that means "install it" (→ doctor);

every line that starts error: is okf *answering* — a bundle or usage result to

read and act on, never a missing toolchain to send to doctor.

Don't memorize the surface — okf --help maps every verb, okf <verb> --help its

flags. The division of labour is the whole game:

  • Shell out — never eyeball — anything a verb computes: conformance (§11), what

exists, what links where, where a term lives, what's stale, the map. Every read

verb takes --json and the list views filter by type/dir/tag, so ask the narrow

question instead of paging the bundle.

  • Skeleton first, bodies last. dirs, search, graph --minimal, and

--fields projections each answer for a fraction of a dump's bytes; full

bodies are the final step of a retrieval, never the first. <!-- rule:okf-skeleton-first -->

  • You judge — the CLI can't — meaning: contradictions, semantic staleness

(parses fine, no longer true), whether a loose file is terminal-by-design, whether

a singleton tag is a deliberate marker. Tool output is evidence, never a verdict.

The one trap worth carrying in your head: the age cutoff is off by default —

a plain okf lint reports concepts past their own declared stale_after (the

expired check reads the clock the CLI supplies), but never judges *age*; pass

--stale-after <90d|12w|ISO-date> when you want anything not touched since then

flagged too — the two mechanisms share a spelling and nothing else

(cli/checks.md, rule okf-two-clocks).

<!-- check:stale -->

Read cli.md before *interpreting* a verb's output in depth.

It is the index and the shared contract — refs, exit codes, --json, the

filters — and its table routes to the one file the verb lives in:

checks (what validate may and may not reject, lint's

categories and check ids), search,

map (index/dirs), views

(the tag-curation views), serve (the trust boundary),

registry, graph.

Orient before you touch anything

Picking up a bundle you don't already know — to consume or maintain — start with

okf dirs <dir|@slug>: one row per *directory*, so it stays small on a bundle of

any size and it names the branches every other view narrows to. Then open the one

you want with okf index <dir|@slug> --dir <branch> (the §8 map: that directory's

index body, rollups, and listing), and read log.md (the §9 baseline of what

changed last) — all of it before greping or opening leaves. Reach for index

rather than grep for the one reason that outranks convenience: **grep cannot find

an index entry that is missing**, so enumeration drift is invisible to it — you

can't search for the word that should be there but isn't. <!-- rule:okf-orient-index -->

Per-verb steps are in the

playbooks (the Commands table below; no okf installed? read the root

index.md plus each area's index.md).

The authoring verbs — the craft

produce (create or extend a bundle), maintain (sync it with reality),

consume (use it as context) carry the judgment the executable can't — this is

where the skill earns its keep. Each has a playbook (the Commands table below);

read the modelling craft in authoring.md before

producing or maintaining. When you need chapter and verse, go through

spec-map.md — which § settles which question — into the

verbatim SPEC.md.

No subcommand? Infer intent: "document this / capture X" → produce;

"convert / migrate / OKFy these existing docs into a bundle" → migrate; "the

code changed, update the docs" → maintain; "restructure / rebalance the

bundle / is the structure right / get more out of it" → refine; "what do we

know about X / where is X documented" → search; a repo already carrying a

bundle plus a task needing its knowledge → consume; "check / graph / preview

it" → run the matching CLI verb and interpret the result. When genuinely

ambiguous, ask.

Which target? A leading @ is a *registry ref*, not a path: @slug names a

bundle registered with okf registry set, bare @ the default — route it

straight to okf <verb> @slug and skip the directory hunt (okf search spans

several: @a @b, or @all). A @slug may instead name a group — a saved set

of bundles (okf registry group backend @a @b, members nest); it resolves like

any ref for the two set-taking verbs (okf search @backend, `okf server

@backend`) and every single-bundle verb refuses it with exit 2, the message

saying which two take a group. A plain path is used as given. Given no target and a

cwd that carries no bundle, okf registry list is the next move, not a hunt

across sibling directories. Producing a *new* bundle with no path? Default to

.okf/ at the repo root, but first detect whether the project already keeps its

bundle elsewhere (e.g. docs/) and prefer that; commit it alongside the code it

describes.

Target isn't a bundle? When a verb points at a directory that holds markdown

but no root index.md carrying okf_version — validate failing wholesale on

missing frontmatter — don't grind through the errors: suggest migrate (OKFy it

in place, bodies verbatim) and let the user pick.

Commands

The first word of the arguments picks a row. No arguments at all — someone

asking "what should I do?" — is its own row: read playbooks/menu.md, orient on

the signals, and recommend the highest-value move without running one. When there

is wording but no matching first word, infer intent as in "No subcommand?" above.

Read the referenced playbook before executing — it *is* the procedure.

| Verb | Category | What it does | Reference |

|------|----------|--------------|-----------|

| *(none)* | Orient | recommend the highest-value next move; never auto-run | playbooks/menu.md |

| search | Use | answer a question from the bundle: map → finder → only the winning bodies | playbooks/search.md |

| produce | Author | create or extend a bundle | playbooks/produce.md |

| migrate | Author | convert existing docs in place: frontmatter + reserved files, bodies verbatim | playbooks/migrate.md |

| maintain | Author | sync the bundle's content with reality after a change | playbooks/maintain.md |

| refine | Author | optimize the bundle's structure: evidence-driven, cohesion-first; proposes, never auto-applies | playbooks/refine.md |

| consume | Use | use the bundle as context for a task | playbooks/consume.md |

| curate | Curate | structural upkeep as it stands: validate + lint + loose | playbooks/curate.md |

| doctor | Setup | install and verify the CLI, then doctor the bundle | playbooks/doctor.md |

| <okf-cli-verb> | Read | validate, lint, loose, index, catalog, files, tags, types, stats, graph, server, render, registry, skill — plus any verb an installed extension adds (okf help is authoritative, this list is not) | okf <verb> --help + reference/cli.md |

Three boundaries worth keeping sharp: curate is structural upkeep only — when

the *content* no longer matches reality, that is maintain, and when the

content is right but the *shape* underserves retrieval, that is refine — and

doctor is the one playbook that does not assume the CLI is installed. In

Claude Code with the okf plugin, /okf:gem routes these same verbs.

The lifecycle is a flywheel, not phases

produce seeds a bundle; consume reads it; maintain runs whenever reality drifts

*or* whenever consuming teaches you something durable — that write-back reflex is

what keeps a bundle alive instead of rotting into folklore. When you learn

something while consuming, switch to maintain and record it. The playbooks live

one per verb in playbooks/ (the Commands table above); the modelling craft

(granularity, choosing type, tag vocabulary, topology, resource, links,

citations) is in reference/authoring.md.

Other skills for the same job

different authors, same section of the catalogue
DOCX
by anthropics
vendor ×16

Comprehensive document creation, editing, and analysis with support for tracked changes, comments, formatting preservation, and text extraction. When Claude needs to work with professional documents (.docx files) for: (1) Creating new documents, (2) Modifying or editing content, (3) Working with tracked changes, (4) Adding comments, or any other document tasks

7k tokens
PDF
by anthropics
vendor ×16

Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms. When Claude needs to fill in a PDF form or programmatically process, generate, or analyze PDF documents at scale.

13k tokens scripts
PPTX
by JayZeeDesign
×15

Presentation creation, editing, and analysis. When Claude needs to work with presentations (.pptx files) for: (1) Creating new presentations, (2) Modifying or editing content, (3) Working with layouts, (4) Adding comments or speaker notes, or any other presentation tasks

308k tokens scripts
Canvas Design
by anthropics
vendor ×13

Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.

1388k tokens
PDF
by anthropics
vendor ×10

Use this skill whenever the user wants to do anything with PDF files. This includes reading or extracting text/tables from PDFs, combining or merging multiple PDFs into one, splitting PDFs apart, rotating pages, adding watermarks, creating new PDFs, filling PDF forms, encrypting/decrypting PDFs, extracting images, and OCR on scanned PDFs to make them searchable. If the user mentions a .pdf file or asks to produce one, use this skill.

15k tokens scripts
DOCX
by w95
×6

Use this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files). Triggers include: any mention of 'Word doc', 'word document', '.docx', or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a 'report', 'memo', 'letter', 'template', or similar deliverable as a Word or .docx file, use this skill. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.

5k tokens
PPTX
by w95
×4

Use this skill any time a .pptx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx file (even if the extracted content will be used elsewhere, like in an email or summary); editing, modifying, or updating existing presentations; combining or splitting slide files; working with templates, layouts, speaker notes, or comments. Trigger whenever the user mentions \"deck,\" \"slides,\" \"presentation,\" or references a .pptx filename, regardless of what they plan to do with the content afterward. If a .pptx file needs to be opened, created, or touched, use this skill.

2k tokens
Obsidian Markdown
by ZhanlinCui
×3

Create and edit Obsidian Flavored Markdown with wikilinks, embeds, callouts, properties, and other Obsidian-specific syntax. Use when working with .md files in Obsidian, or when the user mentions wikilinks, callouts, frontmatter, tags, embeds, or Obsidian notes.

3k tokens

How to use it

Copy the folder

Take serradura/okf from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.