wiki

name: wiki description: Use when the user says "add to wiki", "update wiki", "check wiki", "wiki lint", "beautify wiki", or references their Obsidian knowledge base. Handles ingest, update, query, lint, and Obsidian presentation-layer automation on ~/wiki/.

/wiki -- Obsidian Wiki CRUD

Manage the user's Obsidian wiki at ~/wiki/. ~/wiki/STRUCTURE.md is the source of truth for placement and page shape. The wiki is the curated memory palace; mempalace (~/.mempalace/wiki-palace) is only a rebuildable semantic index over it. If search/index output conflicts with the wiki, the wiki wins.

Operations

Route by intent:

Wiki Structure

Use the loci model from ~/wiki/STRUCTURE.md:

palace ~/wiki
  entrance: index.md                 # thin 30-sec Find/Place card + hub list
  wing: projects/<slug>/ or ops/...
  room: issues/ prs/ decisions/ designs/ meetings/ logs/ runs/
  drawer: one page
  item: a section
  hallway: cross-wing MOC / pattern / system page

Placement rule: project-scoped content goes under projects/<path-slug>/; cross-project operational content goes under ops/; reusable methods go under patterns/; cross-project systems go under systems/; immutable source files go under raw/.

index.md is a thin generated trunk, not a full catalog. Each project has a hub at projects/<path-slug>/<short-slug>-overview.md; use the hub + typed rooms to navigate and place content. Run evidence lives in runs/ as low-nav packets (00-index.md, step files, assets/), never in the removed implementation room.

Markdown + Presentation Strategy

Use Markdown as the canonical source of truth. Agents should read and update the .md drawer first because it is searchable, diffable, linkable, and easy to cite. Do not replace a wiki page with a .canvas, .base, Kanban, Dataview, or plugin-only view as the only copy of the knowledge.

Use Obsidian presentation artifacts as generated or curated human views:

• Canvas maps for project command centers, roadmap overviews, decision graphs, architecture maps, and run/story relationship maps.
• Dashboard notes (*-visual-home.md, wiki-home.md) for human landing pages with callouts, short tables, embeds/links, banners, and cssclasses.
• Bases/Dataview for generated tables/cards over Markdown frontmatter, e.g. decisions, current truth, active issues, logs, and runs.
• Kanban/Tasks for work queues only when the underlying issue/roadmap Markdown remains canonical.
• Excalidraw/Mind Map for visual diagrams or outline summaries; link back to the Markdown drawer that owns the facts.
• Custom Frames/Open Gate only for external live views such as GitHub, Swagger, dashboards, or deployed apps; never cite them as wiki truth without a Markdown snapshot/ADR/log.

Readable Canvas default:

• Prefer concise text cards containing a title, 1-2 line summary, and a [[wikilink|Open]] link. This avoids Obsidian file nodes rendering noisy frontmatter/property previews.
• Use Canvas file nodes only when a live preview is intentionally useful (images, PDFs, Excalidraw drawings, or a note section explicitly meant to be previewed).
• Keep card text short. Long prose belongs in Markdown drawers.
• Use group nodes for zones, consistent colors for meaning, and avoid overlaps.
• When querying, use Canvas only as a navigation hint; cite facts from Markdown drawers, not from visual layout alone.

Store project visual maps next to the project hub, e.g. projects/<path-slug>/<short-slug>-map.canvas, unless STRUCTURE.md defines a more specific room. When important Markdown relationships change, update the relevant generated view or explicitly report that it was not updated.

When creating or editing Canvas files, follow the json-canvas skill if available. When formatting Obsidian notes, follow obsidian-markdown. For .base files, follow obsidian-bases. Keep plugin-specific behavior optional: the wiki must remain useful if a plugin is disabled.

Presentation Automation

Use this workflow when the user asks to beautify the wiki, when creating a new project hub, or when a meaningful update changes roadmap/current-truth/decision relationships.

1. Read canonical inputs -- ~/wiki/STRUCTURE.md, index.md, the project hub, roadmap.md if present, and the relevant typed room pages.
2. Choose generated views -- pick only views that help the human reader: Canvas map, visual home/dashboard note, Base/Dataview table, Kanban board, Excalidraw/Mind Map diagram, or external frame link.
3. Generate from Markdown -- summarize canonical pages into short cards and view rows. Do not invent facts from layout. Link each visual node/row back to its Markdown drawer.
4. Design for readability -- use short cards, clear zones, color legend, left-to-right or top-to-bottom flow, generous spacing, and no file-preview property spam unless intentionally previewing media.
5. Validate artifacts -- parse Canvas JSON, verify all edge node IDs exist, check for obvious node overlaps, parse Base YAML if created, then run: python3 ~/wiki/.tools/wiki-doctor.py.
6. Visual QA when possible -- if Obsidian is running/reachable, use the Obsidian CLI screenshot/DOM tools to inspect the rendered view. If not reachable, report that limitation and ask the user for a screenshot pass.
7. Keep automation honest -- generated views are replaceable. Markdown pages and raw sources are not.

Wiki Agent Mode

A separate wiki agent is useful for broad or repeated beautification work, but it should follow this skill rather than create a new source of truth. For large requests, operate one wing at a time:

1. Inventory hubs and existing visual artifacts.
2. Produce a short batch plan with write scope and verification.
3. Update Markdown only when canonical facts/backlinks/frontmatter require it.
4. Regenerate presentation artifacts from those Markdown facts.
5. Run doctor + artifact validation + visual QA/screenshot when available.
6. Report changed files, generated views, validation output, and remaining visual risks.

Ingest

When adding new content:

1. Read contract -- Check ~/wiki/STRUCTURE.md and the relevant template in ~/wiki/templates/.
2. Place by wing + room -- Pick the project/ops/system/pattern wing, then the registry type folder. Unsure: project-scoped wins; promotion is easier than demotion. If this creates or changes a project hub, roadmap, current-truth table, decision graph, or major relationship, create/update the companion presentation view after the Markdown page exists.
3. Check existing -- Start from index.md, then the project hub or typed room. If a drawer already exists, update instead.
4. Create page -- Use the template shape and v2 frontmatter.
5. Cross-reference -- Add [[backlinks]] to the hub, roadmap, ADR, issue, PR, log, or source page that makes the fact findable.
6. Generated nav -- Do not hand-maintain generated AUTO blocks; leave them for wiki repair. Only edit human prose and required backlinks.
7. If a raw source exists (PDF, image, transcript), copy it to ~/wiki/raw/ first and cite it with sources:.

Update

When modifying existing content:

1. Read the page first and confirm it is the authoritative drawer.
2. Edit surgically. Update updated: to today and preserve existing style.
3. Keep lifecycle honest -- draft -> active|accepted -> superseded|archived. Add superseded_by: when replacing old truth.
4. Cross-reference -- Update related links if relationships changed.
5. Generated nav -- Do not rewrite generated index.md, hub Contents, or local MOC AUTO blocks by hand.
6. Generated views -- If the update changes roadmap/current-truth/decision relationships, update the companion Canvas/dashboard/Base view or say why it was skipped.

Query

1. Use the thin ~/wiki/index.md to choose the wing/hub/MOC.
2. Read the project hub (*-overview.md) and relevant typed room pages.
3. Optionally inspect project .canvas maps to understand relationships, but do not treat Canvas layout as canonical truth.
4. Optionally use mempalace/wiki-palace for semantic locate, but cite facts from wiki drawers (path#heading) and respect lifecycle/status.
5. Synthesize the answer with [[backlinks]] to sources.
6. If the answer is valuable and novel, offer to file it as a new wiki page or add it to the relevant Canvas map.

Lint

Run the read-only doctor:

python3 ~/wiki/.tools/wiki-doctor.py

It reports broken links/embeds, missing sources, orphan pages, frontmatter gaps, stale active pages, local-MOC thresholds, and mempalace freshness status. For presentation work, also validate generated Canvas/Base files directly. Do not auto-repair unless the user explicitly asks; planned wiki repair may rewrite AUTO blocks only.

Frontmatter

Every page uses v2 frontmatter:

---
title: Page Title
type: issue | pr | decision | design | meeting | log | run | pattern | system | project-hub | roadmap | governance
tags: [project/<slug>, type/<type>, topic/<topic>]
status: draft | active | accepted | superseded | archived
created: YYYY-MM-DD
updated: YYYY-MM-DD
sources: [raw/file.ext]
---

Use type, not the old category. Issue pages also carry roadmap/GitHub trace fields; project hubs carry path_slug, short_slug, and aliases.

Template Registry

Read the matching file in ~/wiki/templates/ before creating a page:

• project.md → project hub (*-overview.md)
• roadmap.md
• issue.md → body exactly # Description, # Motivation, # Requirements
• pr-description.md
• decision.md (ADR)
• design.md / technical-design-document.md
• meeting.md
• log.md
• run.md
• pattern.md
• system.md

Rules

1. ~/wiki/STRUCTURE.md wins on placement and page shape.
2. Raw sources are immutable -- never modify ~/wiki/raw/.
3. Project-first -- put project facts under the project wing unless truly cross-project/reusable.
4. One concept per drawer -- split rather than combine.
5. Frontmatter is mandatory and uses the v2 type registry.
6. Use Obsidian wiki links: [[page-name]] or [[page-name|display text]].
7. Markdown is canonical; Canvas/Base/Kanban/Dataview/Excalidraw/Mind Map are companion human-readable views.
8. Prefer readable Canvas text cards with wikilinks over noisy file-preview nodes unless a live preview is intentional.
9. Run/evidence packets are low-nav and excluded from normal MOC/search priority.