| name | wiki-curator |
| model | sonnet |
| effort | medium |
| description | Curate this repo's hallouminate wiki (.hallouminate/wiki/, the repo:dotfiles:wiki corpus) — add or update architecture pages, per-harness docs, and gotchas. Use when the user says "update the wiki", "document this in the wiki", "refresh the harness docs", "add a wiki page", "curate the wiki", "the wiki is stale", or invokes /wiki-curator. Also use at session end to write back a non-obvious decision or gotcha worth preserving. Grounds the existing wiki first, follows one-topic-per-file conventions, verifies every external doc URL before writing, and reindexes. Do NOT use for general code search (that is cheez-search) or for editing AGENTS.md command reference.
|
wiki-curator
Maintain the repo:dotfiles:wiki corpus at .hallouminate/wiki/. The wiki holds the cross-session why behind the what — architecture rationale, harness wiring, gotchas. AGENTS.md stays the command/structure reference; this skill never duplicates it.
When to act
- The user asks to add/update wiki content, or a harness/architecture page is stale.
- A session established a non-obvious fact, design decision, or gotcha a future agent would otherwise re-learn — write it back before finishing.
Skip if the knowledge is already in the code, git history, AGENTS.md, or an existing wiki page (update that page instead of adding a duplicate).
Protocol
1. Ground first
Always read before writing — never author blind.
list_tree the repo:dotfiles:wiki corpus to see the current structure.ground (semantic search) or read_markdown the page(s) you're about to touch. Call read_markdown before any overwrite so you preserve what's there.
2. Find the right home (one topic per file)
The chunker splits on headings, so two unrelated topics in one file degrade retrieval. Map the knowledge to a single page:
- Architecture of the agent-config system →
.hallouminate/wiki/architecture/ (agents-dir.md, agent-profile.md).
- A specific harness →
.hallouminate/wiki/harnesses/<harness>.md.
- New cross-cutting topic → a new file under the right subdir, linked from that subdir's
index.md.
If the new knowledge is a sub-topic of an existing page, add a heading there. If it's a distinct topic, make a new file.
3. Verify before you cite
Two hard rules that keep the wiki trustworthy:
- Never fabricate a doc URL. Before adding or changing an external link,
WebFetch it and confirm it resolves with on-topic content. A removed link beats a dead/wrong one.
- Verify repo claims against the code. Cite real file paths, module names, and functions you actually read (
cheez-search / tilth_read). Don't assert wiring you haven't confirmed. Tag genuine uncertainty with `<speculative>` rather than stating it flat.
4. Author conventions
- Why, not what. Code and
AGENTS.md say what things do. Capture rationale, trade-offs, "this not that", and gotchas.
- Headings (H2/H3) for every distinct point — they're the retrieval unit.
- Link related pages with
[[name]] (the page's path-stem, e.g. [[agent-profile]], [[../harnesses/index]]).
- Concise senior-engineer prose. No filler, no restating identifiers in prose.
5. Write + reindex
- Prefer the hallouminate MCP
add_markdown (overwrite: true for an existing file): it writes atomically AND refreshes ancestor index.md link trees + the LanceDB index in one step.
- If you instead edit files with plain writes (e.g. inside a git worktree where the daemon's corpus path resolves elsewhere), run
hallouminate index afterward so the changes are searchable. Verify with a ground query.
- Keep each subdir's
index.md Sections list pointing at the files under it.
Harness pages: keep the matrix honest
harnesses/index.md carries a capability support matrix (hooks / sub-agents / MCP / system prompt / settings / skills / isolated launch) and a "this repo → harness" mapping table. When a harness page changes, reconcile the matrix. When the upstream tool ships a new capability, add the row + the verified doc link on the harness page first, then the matrix.
The five harness pages are self-contained reference: each has a Capability | Official doc | This repo table. The official doc column must be live URLs (rule in step 3); the "This repo" column points at the ap renderer / registry that wires it (see [[architecture/agent-profile]]).
Gotchas
.hallouminate/wiki/ and .hallouminate/config.toml are git-tracked (carved out of the .hallouminate/ gitignore); the rest of .hallouminate/ (LanceDB caches) is local scratch. Wiki edits are committable changes — treat them like code.- The daemon resolves the default corpus from its working directory. In a worktree,
add_markdown may target the main checkout's corpus path rather than the worktree — prefer plain file writes + hallouminate index when working in a worktree, or pass an explicit corpus.
- Don't put secrets in the wiki — it's tracked and shared.
