Ki Repo Kb

Knowledge Islands KB

You are helping the user interact with a Knowledge Islands knowledge base - a markdown store organised to the Knowledge Islands structure. This skill carries the operating modes and the structure itself; only a handful of store-level details come from the host project. It assumes the zone model below and does not ask the project to redefine it.

The Knowledge Islands structure

A Knowledge Islands base is one markdown store with a fixed set of five zones, flanked by an inbound and an outbound staging area. The five zones — Calendar/, Pillars/, Resources/, Streams/, Admin/ — each carry an index note of the same name; +/ (inbound) and -/ (outbound) are staging areas, not zones, and carry no such index.

† Any zone may be held under a different local folder name — a base mid-migration, or one that simply names a zone differently. That is declared as a zone alias in the base's config, not treated as a different zone - see Project bindings.

※ Migrates to Pillars/ once settled. Its internal structure and process are owned by the ki-repo-kb-streams skill.

† +/_TRADES/ receives cross-repository briefs; their shared repository lifecycle belongs to ki-repo.

‡ -/_TRADES/ holds cross-repository briefs; their shared repository lifecycle belongs to ki-repo.

Admin/ subdivisions

The Admin/ zone carries two canonical subdivisions:

Each subdivision carries an index note of the same name (Governance.md, Operations.md). The root Admin/MEMORY.md remains the memory-cascade anchor and is not replaced by these. Absence of either subdivision is a WARN (not FAIL) — a base may legitimately omit one if that concern is not yet active; presence without an index note is also a WARN.

The specific artefact types under these subdivisions have separate owners. This skill delegates Activity notes to its declared ki-repo-kb-activities dependency and Live Artifact pairs to ki-repo-kb-live-artifacts; selecting ki-repo-kb therefore runs both first. Decision Records remain independently selected through ki-decision-records. Each focused skill defers the parent zone structure and KI-wide frontmatter standard back here.

Charter and Conformance baseline

When Admin/Governance/ is present, two documents are expected there:

Both are checked by the mechanical audit and created as stubs by EDUCATE and CONFORM. Absence is a WARN (not FAIL) — a base that has no Governance/ folder yet is not penalised for missing them.

Pillars are the second-level unit of organisation: each whole knowledge base is an "island"; within it, a Pillar is a major strand of its subject matter (a case, a client, a domain, a theme). A base may use one Pillar or many.

Linking within a base

Notes inside a base link to one another and to their zone index notes with Obsidian [[wikilinks]], not relative markdown paths — the five index-carrying zones are [[Calendar]], [[Pillars]], [[Resources]], [[Streams]], and [[Admin]]. Body links use the shortest unique path (bare filename if unique, the minimum disambiguating prefix otherwise); a ## Contents list uses the full path with an alias ([[Full/Path/Note|Note Name]]). This governs note content inside a base — it is independent of, and does not conflict with, the relative-markdown-link convention these skill files themselves use (see ki-agentic-harness docs/installation.md, "Linking inside skills").

Routing test

Produced outputs (session digests, compiled artefacts, handoffs) bypass this test — they always go to -/ (see Mode DIGEST).

For all other notes, most-specific match wins:

1. Time-bound record -> Calendar/.
2. Active, in-progress work -> Streams/ (the ki-repo-kb-streams skill owns sub-routing within the zone and its adapter-owned lifecycle).
3. Canonical internal knowledge -> Pillars/<Pillar>/.
4. External reference (would exist without this base) -> Resources/.
5. Unsure -> +/<Title>.md at the most specific applicable level.

Memory cascade

Root index Admin/MEMORY.md lists the active Pillars. Where the base is Pillar-scoped, scope a session to one Pillar and load Pillars/<Pillar>/MEMORY.md (and any per-Pillar profile index) before substantive work. Treat other Pillars as off-limits unless the user switches.

Note templates

The skill ships zone-scoped starter templates under assets/templates/<zone>/. EDUCATE copies the relevant stubs when scaffolding a new base. QUERY can list available templates when the user asks (?templates). A base may override or extend these by declaring a [skills.ki-repo-kb.templates] table in its .ki.toml — keys are zone names, values are paths relative to the base.

Templates are stubs — headings, frontmatter keys, and inline <!-- prompts -->. They do not carry content; the skill fills in what the user provides during SAVE / EXTRACT / EDUCATE.

Project bindings

Almost everything is fixed by the structure above. Only these come from the host project - take the narrative bindings from the auto-loaded CLAUDE.md, then the root memory index. Declarative overrides (the zone alias and the lists below) are read from the base's .ki.toml [skills.ki-repo-kb] table instead — see the ki-repo skill for the shared-file contract; validate your own table (warn on an unrecognised key) and never read another skill's. A base never ships a <base>-kb skill: what it needs differently is declared here (data) or in its CLAUDE.md (prose), never forked into a coupled skill.

• Notes store — canonical alias and location of the notes store. Default: the connected base; refer to it as "the base".
• Sources store — whether a paired sources store exists, and how note extracts mirror its paths. Default: none.
• Scope usage — whether the base is Pillar-scoped (declare an active Pillar) or single-Pillar / flat. Default: Pillar-scoped.
• Zone names — the canonical folder per zone, overridable per base. A [skills.ki-repo-kb.zones] sub-table maps any canonical zone or staging area to this base's local folder name (e.g. Pillars = "<local folder>"); resolve every zone reference through it. Useful for a base mid-migration (drop the entry once the folder is renamed) or one that simply names a zone differently. Default: the canonical names (Calendar / Pillars / Resources / Streams / Admin, plus the + / - staging areas).
• Required frontmatter — the keys every note carrying frontmatter must include. Declare them with required_frontmatter = ["tags", "status", "author"] under [skills.ki-repo-kb] to have the checker enforce their presence mechanically (extra keys stay free; keys are always snake_case). Default: none declared — required frontmatter stays a judgment call resolved from the host CLAUDE.md.
• Writing standards — language variant, citation format, structural norms. Default: British English; cite source paths; concise prose.
• Domain pre-flight — any extra reads before drafting (profiles, domain context). Declare them as preflight = ["<path-or-glob>", …] under [skills.ki-repo-kb] — a list of note paths/globs to read before drafting, which the checker validates down. Default: none beyond the memory cascade.

Step 1 - Load context

1. The host CLAUDE.md (auto-loaded) is the authority on the bindings above; follow it. Read the root Admin/MEMORY.md for active Pillars.
2. If the base is Pillar-scoped, declare or confirm the active Pillar, then load Pillars/<Pillar>/MEMORY.md and any profile index. Confirm: "Session scoped to [Pillar]." If the user switches Pillar mid-session, re-scope before proceeding.
3. Pre-flight before writing anything substantive: scope cascade loaded; if the work engages a named person/entity with a profile note, read it first; run any domain pre-flight declared in .ki.toml (preflight) or the host CLAUDE.md.

Operating modes

Step 2 - determine the mode and load its procedure. Invoked as help / -h / ?, it explains itself and stops — the generated HELP block (name, purpose, invocation, modes, off-ramps), taking no action. With no mode it does the same, then, in an interactive session only, offers the mode choice via AskUserQuestion, prompting for any argument-hint target the chosen mode shows. The shared model above — the five zones, the routing test, the memory cascade, the project bindings, and Step 1 — is what every mode needs and stays loaded; each mode's procedure lives in its own on-demand file, so read only the one the request selects. Like every governance skill it carries the universal four AUDIT · CONFORM · EDUCATE · REFRESH (EDUCATE scaffolds a base); its base-specific modes are the session-level IMPROVE (continuous improvement) and the note-ops DIGEST · EXTRACT · QUERY · SAVE · UPDATE. Modes are named and alphabetical.

The memory cascade and the canonical-zone Enactment gate are part of the shared model above — they apply on every fire, before any mode procedure loads.

Notes

• This skill assumes the Knowledge Islands structure. If a base does not follow it, or a binding cannot be resolved and no default fits, ask the user rather than guess.
• A base supplies its specifics by declaration, not a coupled skill: structured data (zone aliases, required frontmatter, pre-flight reads) in its .ki.toml [skills.ki-repo-kb] table, narrative bindings (store alias, scope, writing standards) in its CLAUDE.md. There is no <base>-kb extension skill; relationships to sibling skills are composition (e.g. the Streams zone delegates to ki-repo-kb-streams).

Normative detail: the Knowledge Islands knowledge-base standard. Checkable criteria: the generated rubric, enforced mechanically by ki repo audit --skill ki-repo-kb. After changing the catalogue under scripts/rubric/items/, regenerate the published catalogue with ki dev skill rubric ki-repo-kb --write.

KI-wide frontmatter standard (universal fields and the note_type taxonomy): the frontmatter standard.