Ki Repo Kb Streams

Knowledge Islands Streams

You are operating the Streams zone of a Knowledge Islands base. Streams/ is the KB equivalent of a project repository's operational docs/ surface: it contains named change-management areas, rather than a second hierarchy of attention or lifecycle folders. Its initial areas are Streams/Roadmap/ for flat forward-work records and Streams/Housekeeping/ for recurring-work templates. A future Streams/Trades/ area may be added when the trade model needs a KB-specific placement.

The governing change-management skills own the records and lifecycle inside those areas: ki-work-roadmap owns roadmap work, ki-work-housekeeping owns templates, and ki-trades owns trade records. This skill owns the KB container and its routing only. Nothing reaches a canonical zone (Admin/ — the base's own operating model — Pillars/, and Resources/) except through approved forward work under the applicable adapter.

The companion ki-repo-kb skill owns the five-zone model and note CRUD / routing, and delegates the inside of Streams/ here; load it for anything outside this zone. This skill carries the structure and process as fixed knowledge; only a couple of store-level bindings come from the host base.

The full detail lives in the references (progressive disclosure): the structure in the Streams structure standard, the shared lifecycle boundary in the Enactment Process standard, and worked shapes in the exemplars. The line-by-line checkable items live in the rubric; ki repo audit --skill ki-repo-kb-streams runs their mechanical evidence and ki repo conform --skill ki-repo-kb-streams applies its safe declared repairs.

The Streams zone at a glance

Streams/
  Roadmap/       # flat roadmap work records and its _ISSUES.md ledger
  Housekeeping/  # recurring-work templates
  Trades/        # reserved for a future KB trade placement, if adopted

Roadmap/ and Housekeeping/ are named operational areas, not horizons. Roadmap work keeps its horizon and lifecycle in frontmatter, exactly as a project roadmap does; it is not moved between Now, Next, Soon, or other folders. Housekeeping/ contains templates, not a backlog of live delivery work. A base may add topical metadata to a record when its owning adapter supports it, but the shared Streams container does not prescribe topical folders or a group vocabulary.

Legacy Active, Background, Dormant, and Focus-style folders are migration inputs, not parts of the target structure. The receiving Knowledge Base chooses how to reconcile each retained record into the appropriate operational area and its owning adapter's format.

Status lifecycle

A roadmap item's status is its position in the shared delivery lifecycle:

Order: draft → ready → in-progress → awaiting-review → done.

Record ownership

Each adapter owns its record shape. A roadmap item is a flat working record in Streams/Roadmap/; its ID, lifecycle, horizon, dependencies, and durable _ISSUES.md allocation ledger follow the roadmap standard. A housekeeping template in Streams/Housekeeping/ follows the housekeeping standard. Neither record type is a knowledge store; its durable outputs belong in a canonical zone.

Use the owning adapter's standard rather than retaining a generic Streams record shape.

Project bindings

Almost everything is fixed above. Only these come from the host base — take declarative overrides from the base's .ki.toml [skills.ki-repo-kb-streams] table (the shared-file contract is owned by ki-repo; validate your own table, warn on an unrecognised key, never read another skill's), otherwise from the auto-loaded CLAUDE.md.

• Process note — the base's local change-process note: a thin pointer to the shared change-management skills plus base-specific authority and routing. Default: Enactment Process. A base may host it under a non-default name or location (e.g. kit-legal keeps it under Admin/Operations/Processes/); declare it as process_note = "Admin/Operations/Processes/Enactment Process" where needed.
• Area bindings — Roadmap/ and Housekeeping/ are the initial fixed areas. A future Trades/ area is explicit work, not an implicit folder a base creates ad hoc.
• Canonical zones — the zones the gate protects, where a record's durable output lands. The knowledge stores a settled stream migrates into are Pillars/ (internal; a base that holds it under a legacy folder name resolves it via the ki-repo-kb zone alias) and Resources/ (external knowledge). Admin/ — the base's operating model (its processes, conventions, configuration) — is equally canonical and equally gated, but receives operating-model changes rather than migrated subject-knowledge.

Step 1 — Load context

1. Resolve the bindings: read the base's .ki.toml [skills.ki-repo-kb-streams] table and CLAUDE.md. Load the base's bound process note if it has one, for local authority and routing.
2. For roadmap work, load the relevant flat work item and Streams/Roadmap/_ISSUES.md fresh; for housekeeping, load the relevant template. Never act on a cached record.

Operating modes

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 operational areas, lifecycle, bindings, Step 1, and Working rules — 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. This carries the universal AUDIT · CONFORM · EDUCATE · REFRESH. EDUCATE explains the canonical Streams model and routes creation of the parent zone to ki-repo-kb; it ships no standalone scaffold or runner. Its adapter modes are ITERATE · PROPOSE · READY · ROLLOUT. Common review and closure belong to ki-accept. Modes are named and alphabetical.

The Working rules apply on every fire, before any mode procedure loads — ROLLOUT in particular must not begin without explicit user authorisation.

Working rules

These apply to every change (the discipline that keeps the workspace trustworthy):

• Name and identity-confirmation gate. Before creating or renaming a roadmap record, propose the name, resulting path, and explicitly allocated ID and wait for confirmation — renames ripple through links, while IDs do not.
• Keep the owned record current. Update immediately on a decision or status change; the canonical state must never lag.
• Load before editing. Reload the work item or template and its ledger before resuming work.
• No ready while a prerequisite is below done. No rollout without explicit authorisation.
• Re-verify each rollout item against the live file before making the edit.
• Retain done work records until an explicit prune selection removes their reviewed evidence.
• Out of scope (no forward-work record needed): trivial typo / formatting fixes, time-bound Calendar/ entries, person-file auto-appends, inbound +/ triage — though when in doubt, prefer a lightweight record: the cost is low, while an unauthorised change to canonical content is high.

Change-management gate

The rule that substantive canonical changes use approved forward work must be anchored in the base's always-loaded CLAUDE.md / AGENTS.md. The directive routes roadmap work through Streams/Roadmap/ and the relevant shared change-management skill; this container skill does not invent a second work lifecycle.

Notes

• This skill governs the inside of the Streams/ zone. For the five-zone model, routing into the zones, note CRUD, and session digests, use the ki-repo-kb skill — it knows Streams is a zone and delegates its internals here.
• When a material decision in a roadmap record warrants a durable, standalone Decision Record rather than an inline note, author it with the ki-decision-records skill and reference it from the record.
• If a base does not follow this structure, or a binding cannot be resolved and no default fits, ask rather than guess.