Wiki lint

Wiki Lint — keep the knowledge base healthy

Purpose

A wiki rots when nobody maintains the cross-references, contradictions, and stale claims. The whole reason the Living Wiki works (.claude/WIKI.md) is that an LLM can do that maintenance at near-zero cost. This skill is the Lint operation: it audits context/ and fixes what's drifted, so every other employee keeps getting trustworthy context. Catching a stale assumption here prevents a bad decision later.

Operating principles applied

• The Lint operation of the Living Wiki — the third verb after Ingest and Query (.claude/WIKI.md).
• Principle 4 (separate planning from execution): propose findings + fixes, get the user's call, then apply. Never silently rewrite their context.
• Principle 5 (intervention point): contradictions and deletions are the user's call; mechanical fixes (index re-sync, adding obvious links) can be auto-applied if they say so.

Step 1 — Orient

Read .claude/WIKI.md, context/index.md, and context/log.md. Note the last LINT: entry in the log so you can report what's changed since. If index.md / log.md don't exist yet, say so and offer to seed them from the examples (the wiki probably hasn't been used much yet — point the user to /onboard).

Step 2 — Audit (spawn the Wiki Linter)

Spawn the wiki-lint subagent (subagent_type: wiki-lint). It scans every page under context/, builds the [[link]] graph, checks file ages, and returns a structured report grouped by: contradictions · stale claims · orphans · missing cross-refs · broken links · index drift · gaps · provenance gaps, each with a file/quote/date, a proposed fix, and a severity — plus a 1–10 health score and the top 3 fixes.

For a large wiki, you may run several linters over disjoint sections in parallel and merge.

Step 3 — Present findings, get the call (intervention point)

Show the report cleanly: health score, then findings worst-first. For each, give the user a clear choice. Be especially careful with:

• Contradictions — show both conflicting claims with dates/sources; ask which is current (or whether both should be kept as history). Never auto-resolve.
• Stale claims — ask whether to refresh, archive, or keep.
• Deletions / merges — always confirm. Offer a fast path: "apply all the safe mechanical fixes (index re-sync, add the obvious missing links, fix dangling links) and let me decide the rest?"

Step 4 — Apply approved fixes + log

Apply only what the user approved, following the Wiki Contract:

• Merge/refresh pages under dated headings (never destroy history; move outdated facts to an "Outdated / superseded" note with the date rather than deleting, unless told to delete).
• Add the approved [[links]]; create missing pages or route to the skill that should (/onboard, /brain-dump, /research-analyst…).
• Re-sync context/index.md.
• Append a LINT: line to context/log.md (date via date "+%F %H:%M") noting the health score and what you fixed.

Step 5 — Report

Summarize: before/after health score, what you fixed, what the user deferred, and the gaps that need a skill to fill. Tell them when to lint next.

Pro tips

• Schedule it. A weekly /wiki-lint keeps drift from accumulating — set it up with Claude Code's /schedule or /loop (when available). Stale context is the silent killer of AI quality.
• Lint after big ingests. After a large /sort-knowledge run, lint to catch contradictions the new material introduced.
• The score is a trend, not a grade. Watch it over time via the LINT: lines in context/log.md — rising is good.
• Gaps are a to-do list. The gaps section tells you exactly what context to capture next to make every employee sharper.