agentleFS
scaccogattoscaccogatto/okf-skills/skills/okf/SKILL.md

okf

Skill444 starsChanged 32 days agoMITView on GitHub

Author, maintain, and consume Open Knowledge Format (OKF) knowledge bundles — portable markdown + YAML frontmatter that both humans and agents read. Use when capturing project knowledge (services, APIs, schemas, metrics, runbooks, decisions) into an OKF bundle, when updating one after code or docs change, or when a repository contains an `.okf/` (or other OKF) bundle that should inform the task. Triggers on: "document this in OKF", "update the knowledge bundle", "capture this as a concept", or any work in a repo that has an OKF bundle.

16 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 2 are distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 16 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Body: prefer structural markdown (headings, tables, lists, fenced code).

    line 40
  2. Very specific:

    Use human: whenever a person authored or signed off — consumers key trust tiers off that prefix.

    line 63
  3. Very specific:

    Use .okf/ at the repository root unless the project already uses another location.

    line 92
  4. Very specific:

    Starting a brand-new bundle?: Use the init fast-path instead of hand-writing the first files — it scaffolds a conformant index.md, log.md, …

    line 99
  5. Very specific:

    Write each concept from templates/concept.md: set a descriptive type, fill recommended fields, record generated and the sources you …

    line 116
  6. Very specific:

    Add/refresh index.md per directory (and okf_version: "0.2" in the root index).

    line 119
  7. Very specific:

    Update the body and generated.at (with your own actor in generated.by).

    line 128
  8. Very specific:

    Update the relevant index.md files.

    line 133
  9. Very specific:

    Read the bundle-root index.md first for progressive disclosure, then follow links only into the concepts relevant to the task.

    line 138
  10. Distinctive:

    If you learn something durable while working, switch to maintain and write it back.

    line 145
  11. Distinctive:

    Never eyeball conformance — run the deterministic checker.

    line 150

“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Open Knowledge Format (OKF) skill

OKF represents knowledge as a directory of markdown files with YAML frontmatter. It is minimal by design: no schema registry, no runtime, no SDK. Your job is to produce, maintain, and consume OKF bundles conformant with the spec, not your memory of it.

Always read the canonical spec before non-trivial work: reference/SPEC.md. It is the verbatim OKF v0.2 specification and the source of truth for every rule below.

The one hard rule

A bundle is conformant (§11) iff: every non-reserved .md file has a parseable YAML frontmatter block, and every such block has a non-empty type field. Everything else is soft guidance. Consumers MUST tolerate missing optional fields, unknown types, and broken links — never reject a bundle over them.

Conventions to apply

  • One concept = one file. The file path (minus .md) is the concept ID.
  • Frontmatter: type is required. Add title, description, tags when they aid consumption; add resource (a canonical URI) only for concepts bound to a real asset — omit it for abstract concepts.
  • Body: prefer structural markdown (headings, tables, lists, fenced code). Conventional headings: # Schema, # Examples, # Computation.
  • Cross-links: standard markdown links; prefer absolute bundle-relative form (/services/auth-api.md). A link asserts a relationship; its kind lives in the surrounding prose, not the link.
  • Reserved files: index.md (directory listing, no frontmatter, except the bundle-root index, which may carry okf_version and this plugin's upkeep: enforced opt-in flag, plus recursive: true (or a depth n: levels below the root, true is 6) to make the hook watch nested git repos) and log.md (ISO-dated history, newest first). Never use these names for concepts.
  • What goes in log.md: lifecycle events only, written in the bundle-root log.md: a bundle created, a concept deprecated or retired, one concept superseding another, concepts regenerated after their source changed, a verification pass. Routine edits to a concept do not get an entry: its generated and git already record them. A log is append-only, so never rewrite or drop an existing entry.

The v0.2 families (all optional, all worth filling)

  • Trust (§5.2): generated: { by, at } — who produced the current content and when. verified: [{ by, at }] — who confirmed it since (a bare mapping is one entry). Write by in the actor convention (§7): <producer>/<version> for an agent, human:<id> for a person, process:<id> for an automated job. Use human: whenever a person authored or signed off — consumers key trust tiers off that prefix.
  • Lifecycle (§5.4–5.5): status: draft|stable|deprecated (absent means stable) and stale_after, an absolute ISO 8601 datetime (a bare date is tolerated), not a TTL.
  • Provenance (§5.1): sources: [{ id, resource, title, author, usage_count, last_modified }] plus a usage_window: { from, to } sibling of sources framing every usage_count (an entry may carry its own to override it); a usage_count without a window warns. resource is required per entry and may be a URL, a bundle path, or a scope descriptor. Attribute a specific claim with a markdown footnote whose label is the source's id: …sharded daily.[^ga4-schema] plus a [^ga4-schema]: … definition. The label is the join key, it must match a sources[].id.
  • Attestation (§10): a sanctioned computation is its own concept, type: Attested Computation, carrying runtime (required), parameters, executor, attester, and the computation itself under # Computation (or a computation: path). Concepts that need the value link to it. Never inline a number's SQL into the concept that narrates it.

Reading a v0.1 bundle? Two constructs were superseded (§13.1): timestamp is now generated.at, and a body # Citations list is now sources. Read both, write v0.2 — and when you touch a legacy concept in maintain mode, migrate its frontmatter as part of the edit. The validator warns on both.

Templates to copy: concept, index, log.

Default bundle location

Use .okf/ at the repository root unless the project already uses another location. Commit it alongside the code it describes — knowledge as code.

Modes

produce — create or extend a bundle

Starting a brand-new bundle? Use the init fast-path instead of hand-writing the first files — it scaffolds a conformant index.md, log.md, and a getting-started.md concept with full recommended frontmatter in one shot:

uv run "${CLAUDE_SKILL_DIR}/scripts/okf_init.py" <target-dir> [--title "..."]

It refuses to touch a directory that already has .md files unless --force is given. Then extend it:

  1. Read reference/SPEC.md.
  2. Pick the source(s): code (derive concepts from source, READMEs, docstrings, config), docs/wiki (distill pages into concepts, record the originals in sources), manual (decisions, playbooks, metrics).
  3. Choose a directory layout by domain (e.g. services/, datasets/, decisions/). One concept per file.
  4. Write each concept from templates/concept.md: set a descriptive type, fill recommended fields, record generated and the sources you actually read, cross-link related concepts.
  5. Add/refresh index.md per directory (and okf_version: "0.2" in the root index). A new bundle gets a dated Creation entry in log.md. Extending an existing one does not.
  6. Validate (see below). Fix every error before finishing.

maintain — keep a bundle in sync with reality

  1. Identify which concepts the change affects (search by resource, path, or topic). This bookkeeping is exactly what agents are good at — touch every affected file in one pass.
  2. Update the body and generated.at (with your own actor in generated.by); fix or add cross-links; create new concepts for new assets; mark removed assets status: deprecated and note the deprecation in log.md rather than silently deleting context. Facing a whole v0.1 bundle rather than a stray field? Do not hand-edit it — run the validator's --migrate once.
  3. Update the relevant index.md files. Append a dated log.md entry only if the change is a lifecycle event (see What goes in log.md).
  4. Validate.

consume — use a bundle as context

  1. Read the bundle-root index.md first for progressive disclosure, then follow links only into the concepts relevant to the task.
  2. Weigh what you read: status: draft/deprecated, a stale_after already past, or no verified entry all mean "check before relying on this". Treat broken links as not-yet-written knowledge, not errors.
  3. Need a number an Attested Computation covers? Run its computation with values bound to the declared parameters — never write your own query.
  4. If you learn something durable while working, switch to maintain and write it back.

Validation (do this before declaring done)

Never eyeball conformance — run the deterministic checker. Invoke the companion validate skill (/okf:validate <bundle-dir> --strict), which ships the checker. If that skill is not installed, run it directly:

uv run "${CLAUDE_SKILL_DIR}/../validate/scripts/okf_validate.py" <bundle-dir> --strict

Resolve every ERROR (hard §11 failures). Under --strict warnings also fail the run (exit 1), so clear them too; drop --strict (or use --max-warnings N) if you only want §11 conformance gated.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.