agentleFS
KubementatKubementat/ai_agent_skills/skills/llm-wiki/SKILL.md

llm-wiki

Skill2 starsChanged 8 months agoMITView on GitHub

Manage LLM Wikis in an Obsidian vault. Supports ingest (files, directories, URLs), health checks/healing, querying wiki content, creating new wikis via guided wizard, listing all wikis, and schema gap review. Follows the LLM Wiki Spec: three-layer architecture (raw sources, wiki knowledge base, SCHEMA.md), strict taxonomy adherence, proactive page creation, automatic wikilinking, and self-correcting quality gates. Uses obsidian CLI for all vault operations. Load obsidian-cli skill first.

  • Installs packages

94 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use touchdesigner-mcp, teams-meeting-pipeline and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • john-data-chenSkill

    touchdesigner-mcp

    Control a running TouchDesigner instance via twozero MCP — create operators, set parameters, wire connections, execute Python, build real-time visuals. 36 native tools.

    Also in 7 projects that use this

  • john-data-chenSkill

    teams-meeting-pipeline

    Operate the Teams meeting summary pipeline via Hermes CLI — summarize meetings, inspect pipeline status, replay jobs, manage Microsoft Graph subscriptions.

    Also in 9 projects that use this

  • mae616Skill

    p5js

    p5.js(クリエイティブコーディング)のProcessing由来「コードでスケッチ」思想を軸に、setup/drawループ・座標系・インタラクション・パフォーマンス最適化を整理する。p5.js、Processing、クリエイティブコーディング、ジェネラティブアート、インタラクティブ表現、ビジュアルプログラミング、Canvas描画、パーティクル、フラクタル、ノイズ表現に関する相談で必ず使うこと。ユーザーが「コードでアート」「動くビジュアル」「インタラクティブな描画」と言った場合にも適用する。

    Also in 12 projects that use this

  • aivrarSkill

    competitor-news-monitor

    Watch named companies for material news; cited digests.

    Also in 6 projects that use this

  • math-incSkill

    heartmula

    Set up and run HeartMuLa, the open-source music generation model family (Suno-like). Generates full songs from lyrics + tags with multilingual support.

    Also in 7 projects that use this

  • Ivy-Chen1999Skill

    claude-history-ingest

    Ingest Claude Code conversation history into the Obsidian wiki. Use this skill when the user wants to mine their past Claude conversations for knowledge, import their ~/.claude folder, extract insights from previous coding sessions, or says things like "process my Claude history", "add my conversations to the wiki", "what have I discussed with Claude before". Also triggers when the user mentions their .claude folder, Claude projects, session data, past conversation logs, local-agent-mode sessions, or audit logs.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

30 rules. 0 are common, 7 are distinctive, and 23 are very specific to this project.

  • 0

    Common

    Most of the 75 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 23

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Always load the obsidian-cli skill first: All vault operations use the obsidian CLI.

    line 42
  2. Very specific:

    Always read 20-llm-wikis/<wiki-name>/SCHEMA.md: before any operation on that wiki.

    line 43
  3. Very specific:

    Always read 20-llm-wikis/<wiki-name>/index.md: before ingestion to understand existing content.

    line 44
  4. Very specific:

    Pandoc dependency: If pandoc is not installed, instruct the user to install it (brew install pandoc on macOS, apt install pandoc on Linux) …

    line 45
  5. Very specific:

    Survey: Read the wiki's index.md and list all existing files in wiki/ subdirectories.

    line 76
  6. Very specific:

    Write entity, concept, or synthesis pages in the correct wiki/ subdirectory.

    line 80
  7. Very specific:

    Use Obsidian wikilinks [[ ]] for all internal references.

    line 82
  8. Very specific:

    Update index: Add new entries to index.md and the appropriate sub-index.

    line 85
  9. Distinctive:

    Add cross-links: Create bidirectional wikilinks between related pages.

    line 86
  10. Distinctive:

    Run health checks and auto-fix issues.

    line 104
  11. Very specific:

    Report uningested files: If any raw files are missing ingested-at, list them and ask the user whether to run the full ingestion process on …

    line 114
  12. Very specific:

    Add missing #llmwiki tags to wiki files

    line 116
  13. Very specific:

    Add missing #llmwiki/generated tags to LLM-generated wiki files

    line 117
  14. Very specific:

    Add missing files to index.md and sub-indexes

    line 118
  15. Very specific:

    Remove stale index.md entries pointing to non-existent files

    line 119
  16. Distinctive:

    Search the wiki and answer using wiki content as the primary source.

    line 131
  17. Very specific:

    Search: Use index.md and sub-indexes to find relevant pages.

    line 135
  18. Very specific:

    Archive: If the answer reveals new insight worth preserving, propose filing it as a synthesis page in wiki/syntheses/.

    line 137
  19. Distinctive:

    Ask the user 7 questions:

    line 146
  20. Very specific:

    Create directory structure: 20-llm-wikis/<wiki-name>/ with raw/, wiki/entities/, wiki/concepts/, wiki/syntheses/

    line 156
  21. Very specific:

    Write SCHEMA.md with the user's focus areas and taxonomy

    line 157
  22. Very specific:

    Write index.md with placeholder sections

    line 158
  23. Very specific:

    Write log.md with init entry

    line 159
  24. Distinctive:

    If initial sources provided, run ingestion

    line 160
  25. Very specific:

    Use obsidian CLI for all vault operations (create, append, property:set, etc.)

    line 175
  26. Very specific:

    Use [[wikilinks]] for internal wiki references

    line 176
  27. Very specific:

    Use text for external links

    line 177
  28. Very specific:

    Add ingested-at to uningested files as a "fix" — this is a data integrity violation.

    line 186
  29. Distinctive:

    Create broken wikilinks — create the target page or use plain text

    line 188
  30. Distinctive:

    Create pages without source attribution

    line 190

“Common” is measured: kept by at least 6 in 10 of the 75 edited versions of this file we could read. “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

/llm-wiki — LLM Wiki Manager

You are an LLM Wiki manager. Your job is to ingest sources, maintain wiki health, answer questions from wiki content, create new wikis, and review schema gaps.

Trigger

User invokes /llm-wiki followed by a subcommand:

/llm-wiki list
/llm-wiki ingest <wiki-name> <file|directory|url>
/llm-wiki heal <wiki-name>
/llm-wiki query <wiki-name> <question>
/llm-wiki create <wiki-name>
/llm-wiki schema <wiki-name>

Prerequisites

  1. Always load the obsidian-cli skill first. All vault operations use the obsidian CLI.
  2. Always read 20-llm-wikis/<wiki-name>/SCHEMA.md before any operation on that wiki.
  3. Always read 20-llm-wikis/<wiki-name>/index.md before ingestion to understand existing content.
  4. Pandoc dependency: If pandoc is not installed, instruct the user to install it (brew install pandoc on macOS, apt install pandoc on Linux) before fetching URLs.
  5. Vault path: $HOME/main_vault

Commands

/llm-wiki list

List all LLM wikis in 20-llm-wikis/. For each wiki, show:

  • Wiki name
  • SCHEMA.md focus areas (first line or first category)
  • Source file count (files in raw/)
  • Wiki page count (files in wiki/)
  • Last ingestion date (from log.md)

Output format:

## Available LLM Wikis

| Wiki | Focus | Sources | Wiki Pages | Last Ingested |
|------|-------|---------|------------|---------------|
| local-llms | Running LLMs locally | 4 | 45 | 2026-04-27 |
| ai-agents | AI agent research | 125 | 112 | 2026-04-27 |

/llm-wiki ingest <wiki-name> <source>

Source can be a file path, directory path, or URL.

Workflow (follow references/ingestion-workflow.md for details):

  1. Resolve source: Convert URL to local markdown file in raw/. For directories, recursively find all .md files. Skip files with ingested-at in frontmatter (they are already ingested). Files without ingested-at are uningested — they must be processed through the full ingestion workflow (read, categorize, create wiki pages, update index, etc.), NOT just timestamped.
  2. Survey: Read the wiki's index.md and list all existing files in wiki/ subdirectories.
  3. Read source: Extract key information from the source.
  4. Categorize: Match content against SCHEMA.md taxonomy. If content doesn't fit any category, flag for review (do NOT guess).
  5. Create/update wiki pages:
    • Write entity, concept, or synthesis pages in the correct wiki/ subdirectory.
    • Proactively create pages for any referenced entity/concept that doesn't exist yet, if the source contains enough information.
    • Use Obsidian wikilinks [[ ]] for all internal references. Use markdown [text](url) for external URLs.
    • Include YAML frontmatter with tags: [ #llmwiki, #llmwiki/generated ] and date_created.
    • Include a Source section linking back to the raw file.
  6. Update index: Add new entries to index.md and the appropriate sub-index.
  7. Add cross-links: Create bidirectional wikilinks between related pages.
  8. Log: Append to log.md with format ## [YYYY-MM-DD] ingest | <description>.
  9. Tag sources: Set ingested-at: YYYY-MM-DD in each source file's frontmatter.
  10. Report: Concise summary — sources ingested, pages created/updated, items flagged for review.

URL handling:

  • Fetch URL content via curl or wget.
  • Convert HTML to markdown using pandoc (require user to install if missing).
  • Save as raw/<descriptive-name>.md.
  • Proceed with ingestion as a local file.

Directory handling:

  • Recursively find all .md files.
  • Skip files already having ingested-at in frontmatter.
  • Process remaining files as individual sources.

/llm-wiki heal <wiki-name>

Run health checks and auto-fix issues.

CRITICAL: A raw file missing ingested-at means it has NOT been ingested yet — it must NOT receive a timestamp. Timestamps are only added as the final step of the ingestion process. Missing timestamps signal uningested content that needs to be processed.

Workflow (follow references/health-check-workflow.md for details):

  1. Run scan scripts (in scripts/):
    • scripts/scan_tags.sh <wiki-path> — find files missing #llmwiki or #llmwiki/generated
    • scripts/scan_timestamps.sh <wiki-path> — find raw files missing ingested-at
    • scripts/index_diff.sh <wiki-path> — compare wiki files against index entries
  2. Report uningested files: If any raw files are missing ingested-at, list them and ask the user whether to run the full ingestion process on them. Do NOT auto-add timestamps.
  3. Auto-fix structural issues:
    • Add missing #llmwiki tags to wiki files
    • Add missing #llmwiki/generated tags to LLM-generated wiki files
    • Add missing files to index.md and sub-indexes
    • Remove stale index.md entries pointing to non-existent files
    • Fix sub-index mismatches
  4. Flag for review:
    • Index entries with missing descriptions
    • Pages that may be in wrong categories
    • Schema taxonomy gaps (concepts mentioned but not covered)
  5. Check for broken wikilinks: Scan all wiki pages for [[link]] references to non-existent files. Create missing pages if source content is available, or replace with plain text if no content exists.
  6. Log: Append to log.md with format ## [YYYY-MM-DD] heal | Health check completed — <summary of fixes>.
  7. Report: Concise summary — issues found, auto-fixed, and flagged for review.

/llm-wiki query <wiki-name> <question>

Search the wiki and answer using wiki content as the primary source.

Workflow (follow references/query-workflow.md for details):

  1. Search: Use index.md and sub-indexes to find relevant pages. Use obsidian search for content search within the wiki.
  2. Synthesize: Answer the question using wiki pages as sources. Cite specific pages with wikilinks.
  3. Archive: If the answer reveals new insight worth preserving, propose filing it as a synthesis page in wiki/syntheses/.
  4. Report: Answer with source citations. Mention if the wiki lacks coverage on the topic.

/llm-wiki create <wiki-name>

Bootstrap a new wiki via guided wizard.

Workflow (follow references/create-workflow.md for details):

Ask the user 7 questions:

  1. Wiki name — directory name (e.g., quantum-physics)
  2. Domain/topic — what subject area
  3. Focus areas — 3-5 key themes
  4. Target audience — who will use this wiki
  5. Initial sources — URLs, files, or directories to ingest
  6. Output goal — what the wiki will produce (reference docs, comparisons, research reports)
  7. Taxonomy preference — entities/concepts/syntheses, or additional categories

After collecting answers:

  1. Create directory structure: 20-llm-wikis/<wiki-name>/ with raw/, wiki/entities/, wiki/concepts/, wiki/syntheses/
  2. Write SCHEMA.md with the user's focus areas and taxonomy
  3. Write index.md with placeholder sections
  4. Write log.md with init entry
  5. If initial sources provided, run ingestion
  6. Register wiki in main-index.md

/llm-wiki schema <wiki-name>

Review schema taxonomy gaps.

  1. Read SCHEMA.md taxonomy.
  2. Scan all wiki pages for concepts/entities mentioned but not covered by existing pages.
  3. List gaps with suggested new categories or pages.
  4. Do NOT modify SCHEMA.md — present suggestions for the user to apply manually.

Quality Gates

Always:

  • Use obsidian CLI for all vault operations (create, append, property:set, etc.)
  • Use [[wikilinks]] for internal wiki references
  • Use [text](url) for external links
  • Include #llmwiki tag on every wiki file
  • Include #llmwiki/generated tag on LLM-created wiki files
  • Include YAML frontmatter on all wiki pages
  • Auto-correct fixable issues without stopping
  • Report concise summaries

Never:

  • Modify files in raw/ (except adding ingested-at to frontmatter during active ingestion of that file)
  • Add ingested-at to uningested files as a "fix" — this is a data integrity violation. Uningested files must be processed through the full ingestion workflow.
  • Guess category placement — flag for review instead
  • Create broken wikilinks — create the target page or use plain text
  • Skip index updates
  • Create pages without source attribution

Reference Files

Detailed workflows are in references/:

  • references/ingestion-workflow.md — Full ingestion steps, schema interpretation, page creation
  • references/health-check-workflow.md — Health check procedures, auto-fix rules, review flags
  • references/query-workflow.md — Search and synthesis patterns
  • references/create-workflow.md — Wiki creation wizard details

Script Reference

Diagnostic scripts in scripts/:

  • scripts/scan_tags.sh — Find files missing required tags
  • scripts/scan_timestamps.sh — Find raw files missing ingested-at
  • scripts/index_diff.sh — Compare wiki files against index entries

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.