codebase-wiki

Name: codebase-wiki
Author: inkeep

3.1kstars191forks

How to install codebase-wiki?

inkeep/open-knowledge/codebase-wiki

$npx -y skills add inkeep/open-knowledge --skill codebase-wiki

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Codebase Wiki pack — how to work here
2
3	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`".
4
5	> 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.
6
7	## The shape
8
9	```
10	wiki/
11	OVERVIEW.md hub: what it is, a big-picture architecture diagram, a nav map to every section.
12	Frontmatter carries `profile` (audience/depth) + `source_commit` (freshness anchor).
13	log.md append-only generation / refresh audit trail
14	architecture/ system boundaries, layers, subsystems, cross-cutting concerns + diagrams
15	modules/ one page per package / module: purpose, entry points, key files, deps
16	flows/ key end-to-end flows as sequence / flow diagrams + narrative
17	concepts/ glossary: atomic pages for domain terms / core abstractions
18	guides/ task-oriented "how / where do I change X" (filled at depth >= standard)
19	```
20
21	## Generating + refreshing
22
23	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).
24
25	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`.
26
27	## The two knobs
28
29	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:
30
31	- `audience` — `internal` (default) or `public`. `public` means polished prose, no secrets / internal infra / ticket numbers, and GitHub-URL source references.
32	- `depth` — `tour` \| `standard` (default) \| `exhaustive`. Scales coverage from OVERVIEW + architecture + top flows up through per-package module pages, concepts, and task guides.
33
34	The `workflow({ kind: "wiki" })` guide is the authoritative source for exactly how each knob shapes the output — invoke it before generating.
35
36	## Source-reference convention
37
38	- Intra-wiki navigation → OK doc links — they build the backlink / hub / orphan graph, so link liberally; density is how the wiki stays navigable.
39	- 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.
40
41	The full rules — the GitHub-URL / relative fallback, the `#Lxx` caveat, and the exact code-span shape — live in the `workflow({ kind: "wiki" })` guide.
42
43	## Per-folder rules
44
45	`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.
46
47	`modules/` — One page pe

People who liked this also viewed

6 picks

Type

codebase-wiki

3.1kstars191forks

View on GitHub

How to install codebase-wiki?

inkeep/open-knowledge/codebase-wiki

$npx -y skills add inkeep/open-knowledge --skill codebase-wiki

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Codebase Wiki pack — how to work here
2
3	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`".
4
5	> 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.
6
7	## The shape
8
9	```
10	wiki/
11	OVERVIEW.md hub: what it is, a big-picture architecture diagram, a nav map to every section.
12	Frontmatter carries `profile` (audience/depth) + `source_commit` (freshness anchor).
13	log.md append-only generation / refresh audit trail
14	architecture/ system boundaries, layers, subsystems, cross-cutting concerns + diagrams
15	modules/ one page per package / module: purpose, entry points, key files, deps
16	flows/ key end-to-end flows as sequence / flow diagrams + narrative
17	concepts/ glossary: atomic pages for domain terms / core abstractions
18	guides/ task-oriented "how / where do I change X" (filled at depth >= standard)
19	```
20
21	## Generating + refreshing
22
23	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).
24
25	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`.
26
27	## The two knobs
28
29	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:
30
31	- `audience` — `internal` (default) or `public`. `public` means polished prose, no secrets / internal infra / ticket numbers, and GitHub-URL source references.
32	- `depth` — `tour` \| `standard` (default) \| `exhaustive`. Scales coverage from OVERVIEW + architecture + top flows up through per-package module pages, concepts, and task guides.
33
34	The `workflow({ kind: "wiki" })` guide is the authoritative source for exactly how each knob shapes the output — invoke it before generating.
35
36	## Source-reference convention
37
38	- Intra-wiki navigation → OK doc links — they build the backlink / hub / orphan graph, so link liberally; density is how the wiki stays navigable.
39	- 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.
40
41	The full rules — the GitHub-URL / relative fallback, the `#Lxx` caveat, and the exact code-span shape — live in the `workflow({ kind: "wiki" })` guide.
42
43	## Per-folder rules
44
45	`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.
46
47	`modules/` — One page pe

People who liked this also viewed

6 picks

Type