Skip to the rows

agentsclimarketplace

Obsidian wiki linter

Skill richfrem/agent-plugins-skills/plugins/obsidian-wiki-engine/skills/obsidian-wiki-linter

repo for reusable plugins and skills

Install

npx -y skills add richfrem/agent-plugins-skills --skill obsidian-wiki-linter

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Runs a semantic health check over the Obsidian LLM wiki using the cheapest available LLM CLI. Finds inconsistencies, missing concepts, stale articles, connection candidates, and new article suggestions. Writes a structured report to meta/lint-report.md. Use when the wiki is large enough to have quality drift, or as a periodic maintenance step.

SKILL.md

3.7 KB, as published. Nobody here has run it

Dependencies

Requires Python 3.8+ and at least one CLI installed: copilot, claude, or gemini.

pip install -r requirements.txt

Obsidian Wiki Linter

Status: Active Author: Richard Fremmerlid Domain: Obsidian Wiki Engine

Purpose

Performs a semantic health check over the LLM wiki — the step Karpathy calls "linting." Unlike audit.py (which checks structural coverage: orphans, missing summaries, broken wikilinks), this skill uses an LLM to analyze semantic quality: contradictions, knowledge gaps, and connection opportunities that only emerge once the wiki is large enough to have internal consistency requirements.

What It Checks

Category	What it finds
Inconsistencies	Contradicting claims between two concept pages
Missing Concepts	Topics implied by existing articles but not yet written
Stale Articles	Pages with vague, outdated, or thin content
Connection Candidates	Concept pairs that should have wikilinks but don't
New Article Suggestions	Topics the wiki should cover based on its current scope

Usage

Run semantic health check (default engine)

python ./scripts/lint_wiki.py --wiki-root /path/to/wiki-root

Sample more pages for larger wikis

python ./scripts/lint_wiki.py --wiki-root /path/to/wiki-root --sample 30

Force engine

python ./scripts/lint_wiki.py --wiki-root /path/to/wiki-root --engine claude

Dry run (print prompt without calling LLM)

python ./scripts/lint_wiki.py --wiki-root /path/to/wiki-root --dry-run

Engine Fallback Chain

Same strict cheap-model chain as obsidian-rlm-distiller:

1. copilot  → gpt-5-mini        (Paid, AI Credits)
2. claude   → claude-haiku-4-5  (fallback, Paid)
3. gemini   → gemini-3-flash-preview (final fallback, Paid)

Output

Report is written to {wiki-root}/meta/lint-report.md with YAML frontmatter:

generated_at: "2026-04-16T..."
engine: "claude"
model: "claude-haiku-4-5"

Followed by five sections:

Inconsistencies — conflicting claims between articles
Missing Concepts — implied but not yet written
Stale or Weak Articles — need richer content
Connection Candidates — wikilinks to add
New Article Suggestions — fresh topics to write

When to Use

After the wiki reaches ~20+ concept nodes (semantic quality starts to matter)
As a weekly maintenance step before a major query session
When you notice the wiki feels inconsistent or fragmented
Before filing --save-as outputs back — lint first to know what gaps to fill
As the final step in /wiki-rebuild (after ingest, distill, build)

Audit vs. Lint

`audit.py`	`lint_wiki.py`
Structural: missing summaries, broken links, orphans	Semantic: contradictions, gaps, stale content
Always fast, no LLM needed	Requires LLM call
Run before every `/wiki-query`	Run periodically (weekly or post-rebuild)
Exit code 1 on critical issues	Always exits 0 (report-only)

Related Scripts

lint_wiki.py — semantic health check orchestrator
audit.py — structural coverage checker (complementary)
distill_wiki.py — shares engine detection logic

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.