Run any Skill in Manus with one click

open-knowledge-pack-codebase-wiki

Stars1,810

Forks87

UpdatedJune 27, 2026 at 15:45

How to work in a Codebase Wiki project (the `codebase-wiki` starter pack): an agent-authored, source-grounded wiki of the surrounding codebase. Read when the project has a `wiki/` knowledge base with `architecture/`, `modules/`, `flows/`, `concepts/`, and `guides/` sections plus `wiki/OVERVIEW.md`. Carries the per-folder rules and freshness + log discipline, summarizes the audience/depth knobs and source-reference convention, and points to the `workflow({ kind: 'wiki' })` guide for the full generate/refresh procedure. Complements the platform `open-knowledge` skill; does not replace it.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

inkeep

inkeep/open-knowledge

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

SKILL.md

readonly

More from this repository

same repository

open-knowledge-discovery

inkeep/open-knowledge

Read when the user asks what OpenKnowledge is, wants to install it on a repository, wants to share an OpenKnowledge project with collaborators, or asks how `ok init` / `ok cowork` / OK Desktop set up a project. Do NOT load to perform OpenKnowledge reads/writes — the runtime guidance for editing markdown inside an initialized OK project ships as a separate project-local skill at `.claude/skills/open-knowledge/` whenever `ok init` runs. If the user appears to be editing markdown inside a `.ok/` project and this is the only OK skill loaded, advise them to re-run `ok init` to install the project-local skill.

2026-07-021.8k

open-knowledge

inkeep/open-knowledge

Authoritative agent-runtime contract for working inside an OpenKnowledge project — a markdown-CRDT knowledge base exposed over MCP. Use whenever reading, listing, searching, or editing any `.md` or `.mdx` file in the project, and before any `mcp__open-knowledge__*` tool call (`exec`, `search`, `write`, `edit`, and the rest). Installed by `ok init`, so its presence means this is an OpenKnowledge project and it governs every markdown file here. Covers the read/write tool surface, grounding and linking rules, folder/template conventions, the live browser preview, and the rule that OK's MCP tools — never native file tools — handle in-scope markdown.

2026-07-021.8k

open-knowledge-write-skill

inkeep/open-knowledge

Use when the user wants to create, author, write, or design a new Agent Skill (a SKILL.md) — for OpenKnowledge or for their editors — including requests like 'help me write a skill', 'make a skill that…', 'turn this workflow into a skill', or improving an existing skill's triggering and discipline. Also use when capturing reusable agent guidance that should live as an installable skill rather than a one-off prompt. Covers choosing scope (project vs global), the SKILL.md frontmatter contract, progressive-disclosure structure, evaluating the skill, and installing it into the user's editors.

2026-07-021.8k

open-knowledge-pack-entity-vault

inkeep/open-knowledge

How to work in an Entity vault project (the `entity-vault` starter pack, GBrain-compatible): a typed-entity vault of people, companies, meetings, and concepts, each a dossier with a rewritable summary plus an append-only timeline. Read when the project has these folders. Carries the dossier convention and entity-extraction behaviors so that guidance does not live inside template bodies or folder descriptions. Complements the platform `open-knowledge` skill; does not replace it.

2026-06-271.8k

open-knowledge-pack-knowledge-base

inkeep/open-knowledge

How to work in a Knowledge Base project (the `knowledge-base` starter pack). Read when the project has the three-layer source-grounded layout — `external-sources/` → `research/` → `articles/` — wired to the `workflow` MCP tool's ingest / research / consolidate kinds. Carries the pack's workflow, per-folder rules, status flows, and log discipline so this guidance does NOT live inside template bodies or log.md. Complements the platform `open-knowledge` skill; does not replace it.

2026-06-261.8k

open-knowledge-pack-okf

inkeep/open-knowledge

How to work in an OKF starter project (the `okf` starter pack): a knowledge base that is conformant with Google's Open Knowledge Format (OKF) from commit one — `concepts/`, `references/`, `notes/`, a reserved `index.md` navigation hub, and a reserved `log.md` change history. Read when the project has these folders + reserved files. Carries the OKF conventions (non-empty `type` on every non-reserved doc; reserved files carry no frontmatter) as guidance, not enforcement. Complements the platform `open-knowledge` skill; does not replace it.

2026-06-261.8k

name	open-knowledge-pack-codebase-wiki
version	0.18.0
description	How to work in a Codebase Wiki project (the `codebase-wiki` starter pack): an agent-authored, source-grounded wiki of the surrounding codebase. Read when the project has a `wiki/` knowledge base with `architecture/`, `modules/`, `flows/`, `concepts/`, and `guides/` sections plus `wiki/OVERVIEW.md`. Carries the per-folder rules and freshness + log discipline, summarizes the audience/depth knobs and source-reference convention, and points to the `workflow({ kind: 'wiki' })` guide for the full generate/refresh procedure. Complements the platform `open-knowledge` skill; does not replace it.
compatibility	Claude Code, Claude Desktop, Claude Cowork, Claude.ai web. Requires OpenKnowledge MCP server. Installed project-local by `ok seed --pack codebase-wiki`.
metadata	{"pack":"codebase-wiki","author":"Inkeep","repository":"https://github.com/inkeep/open-knowledge"}

Codebase Wiki pack — how to work here

This project holds an agent-authored wiki of a codebase — DeepWiki, but living in the repo. A coding agent reads the source and writes a navigable, diagram-rich, source-grounded wiki as markdown under wiki/. It is version-controlled and diffable, private by default, human+agent co-editable, renders in OK's live preview, and doubles as durable grounding context for future agent sessions. There is no separate Q&A surface — Q&A is "the OK-grounded agent + search".

This is pack guidance. The platform open-knowledge skill still governs every markdown operation (read/write/preview/linking/grounding). This layers the wiki workflow on top.

The shape

wiki/
  OVERVIEW.md     hub: what it is, a big-picture architecture diagram, a nav map to every section.
                  Frontmatter carries `profile` (audience/depth) + `source_commit` (freshness anchor).
  log.md          append-only generation / refresh audit trail
  architecture/   system boundaries, layers, subsystems, cross-cutting concerns + diagrams
  modules/        one page per package / module: purpose, entry points, key files, deps
  flows/          key end-to-end flows as sequence / flow diagrams + narrative
  concepts/       glossary: atomic pages for domain terms / core abstractions
  guides/         task-oriented "how / where do I change X" (filled at depth >= standard)

Generating + refreshing

Don't free-hand it — call workflow({ kind: "wiki" }) and follow the phased, STOP-gated guide. It auto-detects mode: a stubbed OVERVIEW.md (empty source_commit) → generate (survey → overview → architecture → modules → flows → concepts → link-graph audit); a stamped source_commit → refresh (diff source_commit..HEAD, update only affected pages, re-stamp).

Two toolsets. Read source code with NATIVE tools (Read/Grep/Glob/Bash) — OK MCP does not index non-markdown source. Author and audit the wiki with OK MCP verbs (write/edit for pages, links/search for the graph). Never hand-write wiki markdown with native Write/Edit.

The two knobs

Two natural-language knobs, read from the user's request (e.g. "build the wiki, public and exhaustive") and recorded in OVERVIEW.md frontmatter (profile: <audience>/<depth>) so refreshes stay consistent:

audience — internal (default) or public. public means polished prose, no secrets / internal infra / ticket numbers, and GitHub-URL source references.
depth — tour | standard (default) | exhaustive. Scales coverage from OVERVIEW + architecture + top flows up through per-package module pages, concepts, and task guides.

The workflow({ kind: "wiki" }) guide is the authoritative source for exactly how each knob shapes the output — invoke it before generating.

Source-reference convention

Intra-wiki navigation → OK doc links — they build the backlink / hub / orphan graph, so link liberally; density is how the wiki stays navigable.
Code references → relative links + symbol code-spans (internal) or GitHub blob URLs (public). Source-file links stay out of the navigation graph (links tracks only .md/.mdx edges, so they never show as graph dead-links or orphans) — but a wrong-depth path still surfaces in the write/edit brokenLinks response (no-such-file, or unresolvable if it overshoots the content root), so count the ../ hops from the page's folder. Never invent paths — reference only files you actually read.

The full rules — the GitHub-URL / relative fallback, the #Lxx caveat, and the exact code-span shape — live in the workflow({ kind: "wiki" }) guide.

Per-folder rules

architecture/ — One page per architectural area (boundaries, layers, subsystems, cross-cutting concerns). Each: a mermaid system-context or component diagram, key components (with source refs), and the design decisions behind them. Uses the architecture-page template. At depth: tour, modules fold in here.

modules/ — One page per package / module: purpose, responsibilities, public API / entry points, key files (linked per the convention), dependencies, and flows it participates in. Uses the module-page template. Skipped at tour; sub-module depth scales with the knob.

flows/ — Key end-to-end sequences as mermaid sequence / flow diagrams + narrative. Uses the flow-page template; add a Failure modes section at exhaustive. Link every module and concept the flow crosses.

concepts/ — Atomic glossary pages (one term each): definition, why it matters, where it lives in the code. Uses the concept-page template. Keep small and densely cross-linked so each concept becomes a hub.

guides/ — Task-oriented "how / where do I change X" walkthroughs: goal, steps, relevant code, gotchas. Uses the guide-page template. Populated at standard, rich at exhaustive, thin/empty at tour.

Freshness discipline (MUST)

OVERVIEW.md frontmatter carries source_commit — the git HEAD the wiki was last generated/refreshed against. It is the freshness anchor: refresh mode diffs source_commit..HEAD to update only the affected pages, then re-stamps it. Always re-stamp source_commit after a generate or refresh run — a stale anchor silently breaks incremental refresh.

Log discipline (MUST)

wiki/log.md is an append-only audit trail. Append one dated entry per generation or refresh run — one per run, not per page. Reference touched pages as markdown links ([Server](./modules/server.md)) so they register in the backlink graph. Entry shape:

## YYYY-MM-DD: <generate | refresh>

- Profile: <audience>/<depth>
- source_commit: <short-sha> (was <prev-sha> on refresh)
- Coverage: <sections / packages written or updated>
- Pages: [Overview](./OVERVIEW.md), [Server](./modules/server.md), ...

Templates

Each folder ships a starter template (architecture-page, module-page, flow-page, concept-page, guide-page). Create with write({ document: { path, template: "<name>" } }). Templates carry only structure (headings + frontmatter scaffold); what each section is for is described above and in the workflow({ kind: "wiki" }) guide, not repeated inside document bodies.