okf-wiki

Name: okf-wiki
Author: jamditis

336stars57forks

How to install okf-wiki?

jamditis/claude-skills-journalism/okf-wiki

$npx -y skills add jamditis/claude-skills-journalism --skill okf-wiki

Installs into the current project.

Summary

Scaffold a new Open Knowledge Format (OKF) knowledge base and populate it from existing material: a tree of small markdown concept files with YAML frontmatter, a spec, a validator, and session-start hooks that orient Claude on the knowledge base before it works. Use when the user

Files · 1

View on GitHub

SKILL.md

1	# okf-wiki: scaffold an Open Knowledge Format knowledge base
2
3	OKF (Open Knowledge Format) stores knowledge as small markdown files: one concept per
4	file, each carrying its own provenance in YAML frontmatter, with directory `index.md`
5	files for navigation and a validator that enforces the contract. It is built for
6	knowledge bases that both people and agents read and edit — newsroom institutional
7	memory, a research atlas, a team's decision log, an infrastructure map.
8
9	This skill scaffolds a conforming OKF project and validates it. The format contract is
10	in `spec/SPEC.md` (in this skill's directory) — read it before changing structure.
11
12	## When to use
13
14	- The user wants to start an OKF knowledge base, atlas, or wiki.
15	- They want docs structured as one-concept-per-file with provenance, not prose pages.
16	- They want to "initialize OKF" in a repo, optionally publishing into its GitHub wiki.
17
18	## Start here: scope the wiki with the user
19
20	Before you scaffold anything, settle four things with the user. They shape what gets created and
21	how it is published, and they are awkward to retrofit once concepts exist. Ask with `AskUserQuestion`
22	rather than in prose, in two steps: the first three questions in one call, then the publish question
23	as a follow-up call only if the audience came back public or both (it does not apply to an
24	internal-only wiki, and its relevant options depend on that answer, so it cannot share the first
25	batch). Infer the title from the repo or project and confirm it. Skip any question the user already
26	answered in their request — do not re-ask what they have told you.
27
28	1. Audience — who reads this wiki? This answer sets the others:
29	- Internal (agents and teammates): the orientation hooks earn their keep, so keep them on.
30	The bundle may hold infrastructure detail, so it usually lives in a private repo. The in-repo
31	`bundle/` is the source of truth.
32	- Public (people browsing): readability and secret-scrubbing come first; the hooks matter
33	less, since people read it and agents do not. Plan a published view (see Publish below).
34	- Both: the in-repo `bundle/` is the source of truth with hooks on for agents, plus a
35	published view for people. Default here when the user is unsure.
36	2. Title and sections — the knowledge-base title (infer it, then confirm) and the starting
37	sections. Offer sections as a use-case preset, not a blank prompt:
38	- Newsroom institutional memory: `people, orgs, sources, decisions, beats`
39	- Research atlas: `concepts, sources, methods, findings`
40	- Infrastructure or fleet map: `machines, services, networks, credentials, processes`
41	- Decision log: `decisions, context, events`
42	The chosen title and list feed `--title` and `--sections` below; the user can edit the list.
43	3. Populate now or later — author concepts now from existing material (a repo, docs, notes, or a
44	URL: gather it and enter the authoring loop after scaffolding), or scaffold an empty tree the user
45	fills in later.
46	4. Publish target — a follow-up `AskUserQuestion` call, made only after the audience comes back
47	public or both (skip it entirely for an internal-only wiki):
48	- In-repo bundle only (default): the validator and relative links work directly, with no
49	extra surface to maintain. Right for most wikis.
50	- GitHub wiki: an optional reading surface. Advanced and manual — see "Optional: publish into
51	a GitHub wiki" below, bootstrapped with `scripts/gh-wiki-bootstrap.py`.
52	- GitHub Pages: a browsable site rendered from the bundle. Not built yet — treat it as a
53	goal and keep the in-repo bundle as the source of truth.
54
55	Carry the answers into the scaffold command (the title and sections, plus `--no-hooks` if the user
56	opts out of the hooks for a public-only wiki) and into the populate step. The audience answer is
57	also the visibility decision the "Before finishing" section asks you to make deliberately — you are
58	making it here, up front, where it can steer the rest of the setup.
59
60	## What gets created
61
62	`scripts/scaffold.py` writes a project that passes its own validator by construction:
63
64	```
65	<target>/
66	SPEC.md the OKF format contract
67	README.md how to use and validate the bundle
68	scripts/validate.py the validator
69	.claude/ session hooks that orient Claude on

People who liked this also viewed

6 picks

Type

okf-wiki

336stars57forks

View on GitHub

How to install okf-wiki?

jamditis/claude-skills-journalism/okf-wiki

$npx -y skills add jamditis/claude-skills-journalism --skill okf-wiki

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# okf-wiki: scaffold an Open Knowledge Format knowledge base
2
3	OKF (Open Knowledge Format) stores knowledge as small markdown files: one concept per
4	file, each carrying its own provenance in YAML frontmatter, with directory `index.md`
5	files for navigation and a validator that enforces the contract. It is built for
6	knowledge bases that both people and agents read and edit — newsroom institutional
7	memory, a research atlas, a team's decision log, an infrastructure map.
8
9	This skill scaffolds a conforming OKF project and validates it. The format contract is
10	in `spec/SPEC.md` (in this skill's directory) — read it before changing structure.
11
12	## When to use
13
14	- The user wants to start an OKF knowledge base, atlas, or wiki.
15	- They want docs structured as one-concept-per-file with provenance, not prose pages.
16	- They want to "initialize OKF" in a repo, optionally publishing into its GitHub wiki.
17
18	## Start here: scope the wiki with the user
19
20	Before you scaffold anything, settle four things with the user. They shape what gets created and
21	how it is published, and they are awkward to retrofit once concepts exist. Ask with `AskUserQuestion`
22	rather than in prose, in two steps: the first three questions in one call, then the publish question
23	as a follow-up call only if the audience came back public or both (it does not apply to an
24	internal-only wiki, and its relevant options depend on that answer, so it cannot share the first
25	batch). Infer the title from the repo or project and confirm it. Skip any question the user already
26	answered in their request — do not re-ask what they have told you.
27
28	1. Audience — who reads this wiki? This answer sets the others:
29	- Internal (agents and teammates): the orientation hooks earn their keep, so keep them on.
30	The bundle may hold infrastructure detail, so it usually lives in a private repo. The in-repo
31	`bundle/` is the source of truth.
32	- Public (people browsing): readability and secret-scrubbing come first; the hooks matter
33	less, since people read it and agents do not. Plan a published view (see Publish below).
34	- Both: the in-repo `bundle/` is the source of truth with hooks on for agents, plus a
35	published view for people. Default here when the user is unsure.
36	2. Title and sections — the knowledge-base title (infer it, then confirm) and the starting
37	sections. Offer sections as a use-case preset, not a blank prompt:
38	- Newsroom institutional memory: `people, orgs, sources, decisions, beats`
39	- Research atlas: `concepts, sources, methods, findings`
40	- Infrastructure or fleet map: `machines, services, networks, credentials, processes`
41	- Decision log: `decisions, context, events`
42	The chosen title and list feed `--title` and `--sections` below; the user can edit the list.
43	3. Populate now or later — author concepts now from existing material (a repo, docs, notes, or a
44	URL: gather it and enter the authoring loop after scaffolding), or scaffold an empty tree the user
45	fills in later.
46	4. Publish target — a follow-up `AskUserQuestion` call, made only after the audience comes back
47	public or both (skip it entirely for an internal-only wiki):
48	- In-repo bundle only (default): the validator and relative links work directly, with no
49	extra surface to maintain. Right for most wikis.
50	- GitHub wiki: an optional reading surface. Advanced and manual — see "Optional: publish into
51	a GitHub wiki" below, bootstrapped with `scripts/gh-wiki-bootstrap.py`.
52	- GitHub Pages: a browsable site rendered from the bundle. Not built yet — treat it as a
53	goal and keep the in-repo bundle as the source of truth.
54
55	Carry the answers into the scaffold command (the title and sections, plus `--no-hooks` if the user
56	opts out of the hooks for a public-only wiki) and into the populate step. The audience answer is
57	also the visibility decision the "Before finishing" section asks you to make deliberately — you are
58	making it here, up front, where it can steer the rest of the setup.
59
60	## What gets created
61
62	`scripts/scaffold.py` writes a project that passes its own validator by construction:
63
64	```
65	<target>/
66	SPEC.md the OKF format contract
67	README.md how to use and validate the bundle
68	scripts/validate.py the validator
69	.claude/ session hooks that orient Claude on

People who liked this also viewed

6 picks

Type