agentleFS
HefrockHefrock/agent-skills/skills/wiki-librarian/SKILL.md

wiki-librarian

Skill0 starsChanged 4 months agoMITView on GitHub

Maintains the structural health of the wiki. Audits for broken links, orphan pages, stale notes, near-duplicates, and contradictions. Proposes and applies fixes with user confirmation. Run weekly or before a major synthesis session. Triggers on "audit my wiki," "clean up my vault," "check wiki health," "find duplicates," "fix broken links," and the command /audit. Requires the obsidian-vault MCP server connected. Pairs with wiki-operator for on-demand edits and wiki-synthesizer for content compilation.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Report before changing: Always present findings and get confirmation before modifying anything.

    line 16
  2. Very specific:

    Search for concept pages with overlapping titles or near-identical ## Core idea sections.

    line 57
  3. Distinctive:

    Wait for confirmation before merging — never auto-merge.

    line 60
  4. Distinctive:

    Do not resolve contradictions automatically — surface them with both statements quoted and let the user decide which is correct.

    line 66
  5. Distinctive:

    After presenting all findings grouped by check, ask:

    line 79
  6. Very specific:

    Update Maps/_context.md after fixes are applied.

    line 101

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Wiki Librarian

Keeps the wiki structurally sound. The Librarian does not add knowledge — it preserves what's there by fixing the graph, removing noise, and surfacing what needs attention.

Prerequisites

The obsidian-vault MCP server must be connected (same setup as wiki-operator). Verify with /mcp before running.

Principles

  1. Report before changing. Always present findings and get confirmation before modifying anything.
  2. Fix structure, not content. The Librarian repairs links, merges duplicates, and updates metadata — it does not rewrite explanations. Use wiki-operator's /update for content improvements.
  3. Prefer repair over deletion. A broken link gets fixed or redirected. An orphan page gets linked or flagged — not deleted without confirmation.
  4. Batch by risk. Present low-risk fixes (update dates, fix obvious broken links) separately from high-risk fixes (merges, deletions) and confirm each batch independently.
  5. Leave a trail. Append an audit log to today's run log (Journal/Runs/YYYY-MM-DD.md) after every run. If it doesn't exist yet, create it first with write_note (frontmatter type: journal, subtype: run-log, status: draft, confidence: high, updated: <today>; heading # Run log — YYYY-MM-DD), then append — append_note refuses to silently create a frontmatter-less file.

/audit [focus]

Focus options: links (broken links only), orphans, stale, duplicates, contradictions, or omit for a full audit.

Check 1 — Broken links

  1. Walk all notes in Knowledge/, Sources/, Maps/, Projects/.
  2. For each [[wikilink]] found, verify the target page exists.
  3. Collect broken links grouped by source note.
  4. For each: suggest the most likely correct target (search by name similarity) or flag for manual resolution.

Check 2 — Orphan pages

  1. List all notes in Knowledge/.
  2. For each note, check inbound links (via list_links).
  3. Flag notes with zero inbound links and fewer than two outbound links.
  4. Suggest which existing page should link to the orphan, based on topic overlap.

Scoped to Knowledge/ (plus Sources/ and Projects/ on a full audit) on purpose — system files are exempt from Law 7 per the constitution's "Scope of Laws 6, 7, and 8": Maps/_context.md, Maps/_ask_log.md, Maps/_gaps.md, and System/. Having no inbound links is their correct state. Do not "fix" this check by widening it to the whole vault. Fiction/ is excluded from this walk for the same reason, by a separate constitution clause ("Fiction is out of scope for Laws 2, 3, 6, 7, and 8") — a chapter's link count says nothing about whether the manuscript is any good. Don't widen the walk to include it either. Templates/ is excluded too (scaffolding with placeholder links and values by design; see the constitution's "Templates are scaffolding" clause).

Check 3 — Stale notes

  1. Query status: stale across all notes.
  2. Also find notes where updated: is older than 90 days and status is not mature, paused, or complete. The latter two (type: project only, per wiki-teacher) are an intentional off-ramp — a paused or finished project isn't neglected, so it shouldn't compete with genuinely stale notes for attention.
  3. For each stale note: show its current content summary and ask whether to update, merge, or archive.

Check 4 — Near-duplicates

  1. Search for concept pages with overlapping titles or near-identical ## Core idea sections.
  2. Group suspected duplicates in pairs.
  3. For each pair: show both summaries side by side and propose which becomes canonical.
  4. Wait for confirmation before merging — never auto-merge.

Check 5 — Contradictions

  1. For each concept page with confidence: low, check whether any other page makes a conflicting claim about the same concept.
  2. Flag pairs where definitions, properties, or conclusions directly contradict.
  3. Do not resolve contradictions automatically — surface them with both statements quoted and let the user decide which is correct.

Check 6 — Schema gaps

  1. Find notes missing any required frontmatter field (type, status, confidence, updated). Scoped to Knowledge/, Sources/, Projects/ — Fiction/ uses its own schema (type, status, updated, plus chapter_number/pov_character where relevant, no confidence field) per the constitution's Fiction exemption, and System/Maps/_* files are exempt as already noted above.
  2. Find notes with confidence: low that lack a ## Open questions section.
  3. Find notes with status: mature that link to fewer than two other pages (shouldn't be mature yet). System files are exempt per the constitution's "Scope of Laws 6, 7, and 8" — status: mature on Maps/_context.md or similar means "stable," not "well-connected"; don't flag them here.
  4. Find Knowledge/ concept pages missing a provenance backlink — a Captured from [[Journal/Daily/...]] or Source: [[Sources/.../...]] line (constitution Law 8). Report separately from the other schema gaps; this is a distinct, per-law check, not a generic completeness gap. System files are exempt, same scope clause.
  5. Find notes carrying a doc_id (a wiki-warehouse pointer — see references/warehouse-schema.md) and measure how much of the body is copied from the warehoused source text (constitution Law 10, "distill, don't dump"). A warehouse-linked note is a quick-reference distillation that points to cold storage — a summary, a few excerpts, a ## Connections section — not the original's text. Length is not the test: a long, original write-up is fine and a short pasted passage is not. Run scripts/check_vault.py <vault> --warehouse <knowledge-warehouse checkout> (or scripts/law10_overlap.py on one note body) — it compares 8-word runs against the manifest's text_path, excludes blockquotes and quoted spans from the copied share, and reports fail (over 35% copied outside quotes, or a 120-word unquoted verbatim run), warn (over 20%, an 80-word unquoted run, or over 1500 quoted characters — quoted passages count toward the quote budget, not the run limits) or unchecked. Thresholds are provisional. A note with no extracted text (e.g. an EPUB with extraction_method: unsupported-type) or no warehouse checkout available is unchecked, never a pass — list those separately. Report separately, same as provenance.
  6. Find notes with confidence: high whose verification field (set by wiki-operator, see its SKILL.md note schema) is single-source, name-match, unverified, or absent — or whose verification is vendor/multi-source but verified_against is empty, i.e. the citation tier is claimed with nothing actually cited. This is a wiki-operator integrity rule, not a numbered constitution law — report it separately from the Law 8 provenance-backlink check above; the two are unrelated despite the similar-sounding name. This is the exact shape of the "Hermes 4 35B-A3B" incident: a claim that read as settled but was never corroborated against source, and sat unflagged for six weeks because nothing audited it on a cadence. Flag for re-verification — don't silently downgrade confidence without surfacing it.

Fix pass

After presenting all findings grouped by check, ask:

  • "Apply all low-risk fixes automatically?" (broken link repairs, missing updated: dates, schema gap fills where the value is unambiguous)
  • Confirm each medium-risk fix individually (orphan linking, stale note promotion)
  • Confirm each high-risk fix explicitly (merges, status demotions)

Audit log

Append to today's run log:

## Librarian audit — YYYY-MM-DD

- Broken links found / fixed:
- Orphans found / linked:
- Stale notes reviewed:
- Duplicates merged:
- Contradictions flagged:
- Schema gaps fixed:
- Provenance gaps found / fixed:
- Verification gaps found / fixed:

Update Maps/_context.md after fixes are applied.

Suggested schedule

FrequencyTrigger
WeeklyRun /audit at the start of the week
Before synthesisRun /audit links orphans before a /synthesize session
After major editsRun /audit duplicates after adding 5+ new pages

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.