CLI · read

okf types

What kinds of knowledge live here.

When to use it

To learn a bundle's type vocabulary before adding to it, so a new concept reuses an existing type instead of inventing a near-duplicate.
To spot skew: one type with thirty concepts and four types with one concept each is a modelling smell worth a look.
To answer scoped questions: okf types docs/ --dir decisions shows which kinds of knowledge the decisions directory holds.

How it works

types prints every type with the concepts that carry it, ordered by count descending. It reproduces the browser server's Types panel on the CLI, over the same data source as okf catalog and the other read views. Since type is the one field section 9 makes mandatory, this view covers every concept in a conformant bundle. Advisory read, always exit 0.

The view narrows with --dir PATH and --tag TAG (there is no --type here; the type dimension is the output). Matching is case-insensitive and exact, --dir reaches every directory below the one you name, and it accepts root for the bundle root (a real root/ directory, where one exists, owns the name instead since 1.13.0). The deprecated --area still works over the first path segment.

Try it

okf types docs/

Types - docs (5 distinct)

  Feature    14   Chat threads, Source ingestion pipeline, Link suggestions, Entry ed…
  Model       8   Graph model, Source model, Thread model, Chunk model, Tag model, Us…
  Guide       6   Getting started, Importing sources, Exporting a bundle, Troublesho…
  Decision    5   ADR 0003: chunking strategy, ADR 0007: webhooks over polling, ADR 0…
  Concept     4   Overview, Glossary, Bundle lifecycle, Progressive disclosure

For a machine, okf types docs/ --json emits { bundle, count, types: [{ type, count, concepts: [id, …] }] } as compact single-line JSON.

Pitfalls

types cannot filter by type. Each read view takes the filters orthogonal to itself; here that means --dir and --tag only. To ask "which concepts are Decisions?", flip the question to okf catalog --type Decision.
Filters are case-insensitive and exact. --tag graph matches Graph; --tag gra matches nothing, and a filter that matches nothing is an empty view with exit 0, not an error.
A ragged type list is a curation finding, not a conformance one. Near-duplicate types (Guide next to Guides) pass okf validate fine; this view is where you notice them, and merging is on you.