
Wiki Lint
Run a structured health audit on an Obsidian vault—orphans, broken wikilinks, stale pages, contradictions—with optional consolidate-and-fix mode.
Overview
Wiki-lint is an agent skill most often used in Operate (also Build docs, Grow content) that audits and optionally repairs structural health of an Obsidian knowledge base.
Install
npx skills add https://github.com/ar9av/obsidian-wiki --skill wiki-lintWhat is this skill?
- Triggers on wiki health check, audit my notes, clean up the wiki, and what needs fixing
- --consolidate dream-cycle mode: dry-run preview then confirmed writes
- Finds orphans, broken wikilinks, stale content, tag alias drift, and contradictions
- Uses llm-wiki retrieval primitives to avoid full-vault blind reads on large vaults
- Resolves vault path via .env and ~/.obsidian-wiki/config before scanning index.md and log.md
- Supports report-only default plus --consolidate act-and-report dream cycle
- Structured scan flow: config resolution, index.md inventory, log.md recent activity
Adoption & trust: 2.2k installs on skills.sh; 1.8k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Obsidian vault has broken links, orphan pages, stale notes, and contradictions that erode trust in your own documentation.
Who is it for?
Solo builders maintaining a large or fast-growing Obsidian wiki linked to shipped work and ongoing projects.
Skip if: One-off note-taking with no index.md discipline, or wikis outside Obsidian-compatible vault layouts.
When should I use this skill?
User wants to check the wiki for issues, audit notes, wiki health check, clean up the wiki, fix broken wikilinks, or use --consolidate to fix after preview.
What do I get? / Deliverables
You receive a prioritized health report and, with --consolidate, can apply confirmed fixes so the wiki stays navigable and consistent.
- Wiki health audit report
- Optional consolidated edits to links, tags, lifecycle, and contradiction callouts
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Operate because wiki lint is ongoing knowledge-base maintenance after notes accumulate, though it also supports docs during Build. Iterate fits recurring cleanup, contradiction callouts, and lifecycle fixes rather than one-off research or launch content pushes.
Where it fits
After a feature ship, lint the wiki so implementation notes link back to architecture pages.
Demote stale peripheral pages before publishing a content hub from vault exports.
Monthly health pass to fix contradictions between runbooks and current infra notes.
How it compares
Structured vault audit with optional safe writes—not a generic markdown linter with no wiki graph awareness.
Common Questions / FAQ
Who is wiki-lint for?
Indie builders and knowledge workers using the obsidian-wiki stack who want agent-driven maintenance without manually grepping an entire vault.
When should I use wiki-lint?
After major doc sprints in Build, before sharing docs at Launch, when content feels stale in Grow, or during Operate iterate cycles when you ask for a wiki health check or clean up the wiki.
Is wiki-lint safe to install?
Consolidate mode can modify markdown files only after dry-run and your confirmation; review the Security Audits panel on this page and back up the vault first.
Workflow Chain
Requires first: skill ar9av obsidian wiki llm wiki
SKILL.md
READMESKILL.md - Wiki Lint
# Wiki Lint — Health Audit You are performing a health check on an Obsidian wiki. Your goal is to find and fix structural issues that degrade the wiki's value over time. **Before scanning anything:** follow the Retrieval Primitives table in `llm-wiki/SKILL.md`. Prefer frontmatter-scoped greps and section-anchored reads over full-page reads. On a large vault, blindly reading every page to lint it is exactly what this framework is built to avoid. ## Before You Start 1. **Resolve config** — follow the Config Resolution Protocol in `llm-wiki/SKILL.md` (walk up CWD for `.env` → `~/.obsidian-wiki/config` → prompt setup). This gives `OBSIDIAN_VAULT_PATH` 2. Read `index.md` for the full page inventory 3. Read `log.md` for recent activity context ## Lint Checks Run these checks in order. Report findings as you go. ### 1. Orphaned Pages Find pages with zero incoming wikilinks. These are knowledge islands that nothing connects to. **How to check:** - Glob all `.md` files in the vault - For each page, Grep the rest of the vault for `[[page-name]]` references - Pages with zero incoming links (except `index.md` and `log.md`) are orphans **How to fix:** - Identify which existing pages should link to the orphan - Add wikilinks in appropriate sections ### 2. Broken Wikilinks Find `[[wikilinks]]` that point to pages that don't exist. **How to check:** - Grep for `\[\[.*?\]\]` across all pages - Extract the link targets - Check if a corresponding `.md` file exists **How to fix:** - If the target was renamed, update the link - If the target should exist, create it - If the link is wrong, remove or correct it ### 3. Missing Frontmatter Every page should have: title, category, tags, sources, created, updated. **How to check:** - Grep frontmatter blocks (scope to `^---` at file heads) instead of reading every page in full - Flag pages missing required fields **How to fix:** - Add missing fields with reasonable defaults ### 3a. Missing Summary (soft warning) Every page *should* have a `summary:` frontmatter field — 1–2 sentences, ≤200 chars. This is what cheap retrieval (e.g. `wiki-query`'s index-only mode) reads to avoid opening page bodies. **How to check:** - Grep frontmatter for `^summary:` across the vault - Flag pages without it, **but as a soft warning, not an error** — older pages predating this field are fine; the check exists to nudge ingest skills into filling it on new writes. - Also flag pages whose summary exceeds 200 chars. **How to fix:** - Re-ingest the page, or manually write a short summary (1–2 sentences of the page's content). ### 4. Stale Content Pages whose `updated` timestamp is old relative to their sources. **How to check:** - Compare page `updated` timestamps to source file modification times - Flag pages where sources have been modified after the page was last updated ### 5. Contradictions Claims that conflict across pages. **How to check:** - This requires reading related pages and comparing claims - Focus on pages that share tags or are heavily cross-referenced - Look for phrases like "however", "in contrast", "despite" that may signal existing acknowledged contradictions vs. unacknowledged ones **How to fix:** - Add an "Open Questions" sect