llm-wiki-skills

Six agent skills for building and maintaining a personal knowledge wiki using Markdown files, wikilinks, and filesystem access. Developed on Claude with GUI install support; works on Claude Code, Gemini CLI, Codex CLI, and GitHub Copilot.

What this is

A set of agent skills for incrementally building and maintaining a structured, interlinked knowledge base on your local filesystem. You add sources; the agent reads, synthesises, and files them into wiki pages. You ask questions; the agent reads the wiki and answers with citations. The wiki compounds over time - each source and each good question makes it richer.

This is my personal implementation of the LLM wiki pattern (see below). It is not a product. It has no backend, no API, no cloud sync (unless you provide one), and no dependencies beyond your agent and filesystem access. Everything lives in Markdown files on your disk. If you can read .md files, you can use this in Obsidian, Logseq, VS Code, iA Writer, or a plain folder.

I built this on Claude, but the underlying skill instructions follow the agentskills.io open standard and work on Gemini CLI, Claude Code, OpenAI Codex CLI, and GitHub Copilot. The .skill packaging and Claude Desktop GUI install are Claude-specific; other agents install skills as folders. See Installation.

The skills are (hopefully) honest about what they are: structured instructions to a language model, not code. They are good at their job but not infallible. The wiki is only as good as the sources you feed it and the questions you ask.

Background

This implementation grows out of my own history of working with Obsidian and learning LLM capabilities (and their restrictions!) over time. I started with local markdown files, downloading them, struggling with diffs, and generally being too lazy to do the bookkeeping needed to keep everything connected, coherent, and above all fresh. MCPs changed that game significantly for me, once I was able to add file system access. Now I could use LLM agents to read, write, and maintain notes directly on disk, without intermediaries. Editing was way faster now, bootstrapping new agents became a lot easier, but the discipline required to not keep drowning in hundreds semi-connected markdown files (plus their legacy versions) was still a drag.

What changed all this for me, was Andrej Karpathy's llm-wiki gist, which describes using an LLM to maintain a persistent, compounding wiki rather than doing one-shot RAG retrieval (and I had barely learned what that even was, before I read about the pattern). The core insight, that the wiki is a compiled artefact that gets richer with every source and query, rather than a pile of documents to retrieve from (which I had up to this point) is wholly Karpathy's and is well worth reading in full. And perhaps even just implementing yourself. I had never pushed anything to GitHub before this little project. I learned so much from just trying this out. It's a little shocking to me that a) I could just do this and b) how incredibly well this pattern actually works.

What I am adding to it is just my own preferences in workflow (while keeping the skills generic): packaging, configuration, a source-tracing convention, and a few architectural choices that emerged from real sustained use.

What I figured out along the way

Aspect	The pattern (intentionally open-ended)	This implementation
Raw sources	Immutable permanent store	Flat queue; moving to ingested/ is the commit - filesystem is the state
State tracking	log.md records what's processed	Presence in ingested/ is the record; log.md is audit-only (no reading of what has already been ingested, re-ingestion accidental or not works well enough)
Query compounding	"Good answers can be filed back" (noted as a tip)	/crystallize as a first-class operation - primary mechanism for accumulating chat knowledge, every long session, every major change, archiving a heavy chat -> it compounds and enriches the next bootstrap.
Session bootstrap	Schema document	The wiki and domain home pages are the bootstrap - the wiki is the persistent context
Configuration	Suggestions for structure	wiki-config.md read by all six skills; configure once
Source attribution	Not specified	source: frontmatter field traces each wiki page to its origin in ingested/. reliability: (high/medium/low, agent-assessed at ingest time) captures source trust. Pages from lower-confidence sources get a ## Pending Review section flagging specific claims to corroborate.
Page structure	Not specified	13 vault-side templates (one per page type) deployed by wiki-config on init. Writing skills read the matching template when creating new pages. User-editable without touching skill code; changes take effect immediately for new pages.

The most satisfying thing that emerged from looking at other implementations and attempting to build this myself was /crystallize. Karpathy observes that query answers are valuable and shouldn't disappear into chat history. This isn't about a fully automated self-maintaining archival machine either. He stresses that staying involved is important, asking questions and learning from the answers is the whole point. The LLM is the previously absent bookkeeper, the flagger of stale content, conflicting information and orphaned treasures in a sea of markdown. I had already been prompting summaries of heavy chats, and cycling them out for a fresh instance. Now distilling a long working session into a wiki page became the primary way my projects accumulate knowledge from conversations. Domain home pages (think wiki hubs) serve as structured session bootstraps - previously that context lived in manually written summaries. Now the wiki itself is the persistent context across sessions.

One thing worth knowing before you see it for the first time: the ## Pending Review section that appears on some ingested pages is not an error. It is a quality signal written by the ingest skill when a page is created from a single lower-confidence source - it flags specific claims that would benefit from a stronger source. When you have one, drop it in raw/ and re-ingest; the skill will update the trust assessment and remove the section if the gap is resolved.

The other thing I worked out, which took longer than it should have, is how to make session cycling actually comfortable. Agents lose their working memory. The context window fills, things slow down, and you start a fresh chat. Without the wiki, you spend the next twenty minutes re-explaining where you left off.

What I found is that there are three layers that work together to make this nearly seamless, and the wiki is only one of them.

The first layer is whatever your platform calls permanent instructions - Personal Preferences in Claude, system prompt elsewhere. These fire on every conversation automatically. They carry who you are: working style, preferences, hard constraints, tool habits. They do not change by domain.

The second layer is per-project or per-domain instructions - Claude calls these Project Instructions, and similar mechanisms exist on other providers. You attach them to a project and they inject automatically into every chat in that project. I use these to tell the agent which domain it's working in and to direct it to read the relevant domain home before doing anything else.

The third layer is the domain home itself. The agent reads it at session start and knows: what is being worked on, what was decided last session, what is open. No briefing required.

Together: the permanent instructions carry who you are. The project instructions say which domain and point to the home. The domain home carries where you left off. A fresh agent with an empty context window is equipped in the first minute.

This is, I think, the most underappreciated part of the pattern as applied to ongoing work rather than a one-shot task. The wiki is the memory that survives session cycling. The instruction layers are what put a fresh agent on the right track before it even reads the wiki. Both matter, and they are designed to work together.

The six skills

Skill	What it does
wiki-config	Sets up, validates, and reconfigures your wiki. On first run: deploys wiki-config.md, wiki-schema.md, wiki-help.md, Home.md, Overview.md, index.md, log.md, the raw/ and ingested/ folder structure, and 13 page templates. Ongoing: guided schema editor, template management (view, repair, reset), and repair flows for anything that goes missing. Start here.
wiki-ingest	Processes files from raw/ into wiki pages; classifies, synthesises, cross-references, and moves each file to ingested/ as an atomic commit
wiki-query	Answers questions by reading the wiki index and relevant pages; cites sources; can file valuable answers as new wiki pages
wiki-lint	Health-checks the wiki: broken links, orphaned pages, missing index entries, unreferenced sources in ingested/
wiki-integrate	Weaves a new or updated page into the knowledge graph by adding backlinks and index entries
wiki-crystallize	The session management mechanism. Distils durable signal from a working session - decisions, findings, open questions - into a structured wiki page. Biased toward updating existing domain homes and Overview.md rather than creating new pages. Close every heavy chat with this; the next session picks up from the wiki page, not from scrollback.

Use them individually or together. A minimal setup is wiki-config (once) plus wiki-ingest and wiki-query. Add the others as your wiki grows.

Requirements

An agent with filesystem access. These skills read and write files on your local disk. How you get filesystem access depends on your platform:

• Claude Desktop has no native filesystem access. You need a filesystem MCP - Desktop Commander or the official Anthropic filesystem MCP, both installable via Customize → Connectors.
• Claude Code, Gemini CLI, OpenAI Codex CLI, and GitHub Copilot have filesystem access built in. No MCP required.
• Claude.ai web and mobile cannot reach files on your disk. The skills work with severe limitations and are not recommended for primary use.

A Markdown wiki directory. Any folder of .md files with a consistent wikilink convention works. The skills were developed in Obsidian but the files themselves are plain Markdown - nothing is Obsidian-specific.

Installation

Claude Desktop

Download from the latest release and upload each .skill file under Customize → Skills:

Skill	Download
wiki-config	wiki-config.skill
wiki-ingest	wiki-ingest.skill
wiki-query	wiki-query.skill
wiki-lint	wiki-lint.skill
wiki-integrate	wiki-integrate.skill
wiki-crystallize	wiki-crystallize.skill

Skills activate automatically when relevant, or via slash commands (/wiki-config, /wiki-ingest, /wiki-query, /wiki-lint, /wiki-integrate, /wiki-crystallize). After a few cycles, the LLM learns to suggest them organically.

If you are comfortable with Git, you can also clone the repo and upload the .skill files directly from the repo root - they are kept in sync with each release.

Other agents (Claude Code, Gemini CLI, Codex CLI, GitHub Copilot, and more)

Use the skills CLI to install all six skills at once across any compatible agent:

npx skills add vanillaflava/llm-wiki-skills --all

This installs to ~/.agents/skills/ and symlinks to each agent's native directory automatically. No manual path configuration needed.

If you prefer to install manually, copy the skill folder you want into your agent's skills directory:

Claude Code:     ~/.claude/skills/<skill-name>/
Codex CLI:       ~/.codex/skills/<skill-name>/
Gemini CLI:      ~/.gemini/skills/<skill-name>/
GitHub Copilot:  configure via chat.agentSkillsLocations in VS Code

Copy the entire skill folder, not just SKILL.md - skills bundle reference files in references/ and templates in assets/ that they read at runtime.

Activate with /wiki-config or your agent's equivalent slash command. Conversational triggering varies by agent; slash commands are reliable across all tested platforms.

To update, re-run the install command - it always fetches the latest version from master. npx skills update exists but has known issues with remote change detection.

Getting started

1. Set up your wiki

Easiest way: run /wiki-config. It asks where your wiki should live, then creates the full scaffold in one guided step - config, schema, a user guide (wiki-help.md), starter navigation pages (Home.md, Overview.md), an index, an operation log, the raw/ and ingested/ folder structure, and 13 page templates (one per page type). Takes about a minute. You'll then want to replace the placeholder values in wiki-config.md's blacklist field with the actual folders you want to keep off-limits to wiki writes.

wiki-help.md lands in your wiki root alongside the config files. It covers fields, page types, write discipline, naming conventions, customisation, and tips - the reference you reach for when something is unexpected. Open it in your notes app; it is a plain Markdown file.

The directory containing wiki-config.md is your wiki root. Skills derive it at runtime from the file's location; you never write a path anywhere. If you relocate the wiki, move wiki-config.md with it and everything still works.

If /wiki-config is not installed, the other skills can help - each bundles the same templates as read-only references and will offer to get you set up when you run them. Manual setup works too if you prefer to work with files directly; the config and schema YAML are below, along with field explanations.

If you prefer to set things up by hand, create wiki-config.md at your intended wiki root with this content:

---
blacklist:
  - Folder(s) where the wiki should not write
  - You can edit these

index_excludes:
  - raw\
  - archive\
  - ingested\

ingested_folder: ingested

ingested_subdirs:
  - clippings
  - documentation
  - papers
  - articles
  - data
  - notes

templates_folder: templates\

log_format: "## [YYYY-MM-DD] {type} | {subject}"
---

Path style note: examples use Windows backslash (\). On Mac or Linux, use forward slash (/) instead; YAML itself is agnostic.

Then add this body below the closing --- (the skill generates this automatically, but it's useful to have when editing manually):

Wiki root: The directory containing wiki-config.md is the wiki root. The skills derive it from the config file's location; you do not write the path anywhere. If you move the wiki, move this file with it and nothing else changes. Your wiki root must be inside your filesystem tool's allowed scope or the skills cannot reach your notes.

blacklist: Paths where wiki page creation is forbidden, relative to wiki root. The placeholder values above MUST be replaced with real folder names before the wiki is useful. Add Git repos, private folders, source trees, or any area that should never receive wiki writes.

index_excludes: Paths excluded from index.md tracking. raw\ and ingested\ are always excluded; source files are not wiki pages.

ingested_folder: Folder where processed source files are archived, relative to wiki root. Must be in index_excludes; must not be in blacklist.

ingested_subdirs: Archival taxonomy within ingested_folder. The skill classifies each source and routes it to the appropriate subfolder. Adapt freely; these are just suggestions. ingested/assets/ is always created for files that couldn't be read or extracted.

templates_folder: The folder where page templates live. Deployed and managed by wiki-config - one template file per page type. Edit templates directly in your notes app; changes take effect immediately for new pages.

log_format: Do not change without updating all wiki skills.

The reliability: field you will see in frontmatter is written by wiki-ingest at ingest time. Values are high (primary or authoritative source), medium (secondary source, reasonable confidence), or low (speculative or unverified). It is only written when source: is also present.

Then create wiki-schema.md alongside it. This file defines the frontmatter fields every wiki page uses and the valid values for enumerated fields. Skills read it on boot alongside wiki-config.md and consult it whenever they write a page.

---
# Wiki Page Schema v1.0
# Read by all wiki skills on boot to know what fields pages use.
# Managed by wiki-config - run /wiki-config to view, edit, reset, or repair.

schema_version: "1.0"

# Mandatory fields - every wiki page must have these
mandatory_fields:
  title: string
  version: string
  date: date          # YYYY-MM-DD
  changes: string     # quoted, <80 chars, no paths
  page_type: enum     # see enums below

# Conditional fields - written when context applies
conditional_fields:
  updated: date                    # any skill touch, YYYY-MM-DD
  status: enum                     # default: active
  description: string              # ~200 chars, quoted
  crystallize_count: integer       # wiki-crystallize only, starts at 1
  source: list                     # always a list, even for single origin
  reliability: enum                # only meaningful when source present

# Valid enum values
enums:
  page_type:
    - knowledge
    - reference
    - survey
    - domain-home
    - overview
    - log
    - index
    - config
    - longform
    - profile
    - established-patterns
    - note
  status:
    - active
    - stub
    - artefact
    - archived
    - snapshot
  reliability:
    - high
    - medium
    - low
---

The easiest way to get a correct wiki-schema.md is to copy it from any skill's references/wiki-schema.md - they all bundle an identical read-only reference copy. Running /wiki-config does this for you in one step, and also includes a guided schema editor if you later want to extend it.

The bundled defaults are the minimum coherent set. You can safely extend the schema - add conditional fields, extend enum value lists to fit your own categories. Removing mandatory fields or renaming existing ones isn't recommended; skills depend on those being where they expect.

The resulting directory structure looks like this:

your-wiki/
├── wiki-config.md     ← your settings
├── wiki-schema.md     ← frontmatter structure for all wiki pages
├── wiki-help.md       ← user guide (fields, types, tips) - open in your notes app
├── Home.md            ← navigation hub (skill workflow, links to major sections)
├── Overview.md        ← living synthesis across all domains (grows via /wiki-crystallize)
├── CLAUDE.md          ← tells the agent how your wiki works (see below)
├── index.md           ← page catalog (agent maintains this)
├── log.md             ← operation log, prepend-only (agent maintains this)
├── raw/               ← drop source files here
├── ingested/          ← agent archives processed files here
│   ├── clippings/
│   ├── documentation/
│   ├── articles/
│   └── notes/
└── templates/         ← 13 page templates, one per page type - edit freely

2. Write a CLAUDE.md

A short document that tells the agent: where things live, what conventions to follow, and which domain home pages to read for context. Start simple - one paragraph is enough. The wiki improves this document over time.

3. Start putting it to work

If you're starting fresh, drop a clipping, a research paper, or a docume