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

Writing profile: Before drafting or rewriting natural-language Markdown, read and apply the Writing Profile Resolution section in llm-wiki/SKILL.md. Framework schema, provenance, safety, and operation-specific requirements take precedence. Apply WRITING.md preferences only to generated consolidation reports; deterministic findings and fixes keep their existing formats.

1. Resolve config — follow the Config Resolution Protocol in llm-wiki/SKILL.md (inline @name override → walk up CWD for .env → global config → prompt setup). This gives OBSIDIAN_VAULT_PATH plus any OBSIDIAN_ALLOWED_LIFECYCLES, OBSIDIAN_ALLOWED_RELATIONSHIP_TYPES, OBSIDIAN_REQUIRED_TRUST_FIELDS, and OBSIDIAN_SCHEMA_SOURCE values.
2. Read owner rules — if $OBSIDIAN_VAULT_PATH/AGENTS.md exists, read it before interpreting any schema. Owner rules override framework defaults.
3. Form the effective schema — record the schema source locator plus effective required/optional frontmatter, lifecycle values, relationship types, and provenance markers. Framework values are defaults; preserve owner extensions and relaxed requiredness exactly. Never coerce an owner type to a framework type.
4. Read index.md for the full page inventory
5. Read log.md for recent activity context

Pass the effective schema to deterministic checks explicitly. For example, add each owner extension with --allow-lifecycle / --allow-relationship-type, replace trust requiredness with repeatable --required-trust-field, and identify the authority with --schema-source "$OBSIDIAN_VAULT_PATH/AGENTS.md". The JSON report's schema block must match the schema you formed before findings are accepted.

Schema precedence is CLI flags > resolved environment/config values > framework defaults; lifecycle and relationship extensions remain additive. Strip every override before use. An explicitly configured empty or whitespace-only value—and any empty comma-separated list entry—fails closed; never treat it as a valid lifecycle, relationship type, required field, or authority locator. Remove the variable instead when defaults are intended.

Lint Checks

Run these checks in order. Report findings as you go.

Scope: skip _archives/, _raw/, _readouts/, and .obsidian/ in every check. These hold frozen snapshots, unprocessed staging drafts, and derived readouts (saved by wiki-narrate) — they are not knowledge-graph pages, so orphan, frontmatter, and link checks don't apply to them.

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 target: drop everything from the first | (alias) or # (heading/block anchor), and strip a trailing backslash left by an escaped \| inside a table cell
• Skip a target whose extension is an attachment type (.png, .jpg, .gif, .svg, .webp, .pdf, .canvas, .base, audio and video): it's an embed, not a page link, and has no entry in the .md inventory this check compares against
• Do not treat every dot as an extension — [[Node.js]], [[Next.js]], and [[v1.2 release notes]] are page links whose names happen to contain a dot, and dropping them would both miss real broken links and make the target page look like an orphan
• Strip an explicit .md suffix from what remains, then 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" section noting the contradiction
• Reference both sources and their claims

6. Index Consistency

Verify index.md matches the actual page inventory.

How to check:

• Compare pages listed in index.md to actual files on disk
• Check that summaries in index.md still match page content

7. Provenance Drift

Check whether pages are being honest about how much of their content is inferred vs extracted. See the Provenance Markers section in llm-wiki for the convention.

How to check:

• For each page with a provenance: block or any ^[inferred]/^[ambiguous] markers, count sentences/bullets and how many end with each marker
• Compute rough fractions (extracted, inferred, ambiguous)
• Apply these thresholds:
• AMBIGUOUS > 15%: flag as "speculation-heavy" — even 1-in-7 claims being genuinely uncertain is a signal the page needs tighter sourcing or should be moved to synthesis/
• INFERRED > 40% with no `sources:` in frontmatter: flag as "unsourced synthesis" — the page is making connections but has nothing to cite
• Hub pages (top 10 by incoming wikilink count) with INFERRED > 20%: flag as "high-traffic page with questionable provenance" — errors on hub pages propagate to every page that links to them
• Drift: if the page has a provenance: frontmatter block, flag it when any field is more than 0.20 off from the recomputed value
• Skip pages with no provenance: frontmatter and no markers — treated as fully extracted by convention

How to fix:

• For ambiguous-heavy: re-ingest from sources, resolve the uncertain claims, or split speculative content into a synthesis/ page
• For unsourced synthesis: add sources: to frontmatter or clearly label the page as synthesis
• For hub pages with INFERRED > 20%: prioritize for re-ingestion — errors here have the widest blast radius