llm-wiki

LLM wiki kit

Created by Mehmet Goekce

Published in MehmetGoekce/llm-wiki. Publisher page

168 GitHub starsUpdated 2026-11-07

What it is

Build Karpathy's LLM Wiki with Claude Code. L1/L2 cache architecture. Logseq + Obsidian support.

— the description by Mehmet Goekce

Summary from the brain’s metadata

Build Karpathy's LLM Wiki with Claude Code. L1/L2 cache architecture. Logseq + Obsidian support. Build Karpathy's LLM Wiki with Claude Code. Two-layer cache architecture (L1/L2). Supports Logseq and Obsidian.

How it works

Memory model: LLM wiki

AutoGineer overview, from the brain’s own files

Memory model: LLM wiki. Folders: .github (agent config, 5 files); docs (docs, 7 files); examples (examples, 2 files); templates (templates, 8 files).

Folders
Folder	Role	Files
.github	agent-config	5
docs	docs	7
examples	examples	2
templates	templates	8
.claude-plugin	folder	3
openspec	folder	23

Requirements

Works with: Claude Code

Set it up

Clone the repository at the commit AutoGineer scanned:

git clone https://github.com/MehmetGoekce/llm-wiki.git && cd llm-wiki && git checkout 5fa5ee7d49a4346eeb1d92c1de7bf649e7654e91

Point Claude Code at .claude-plugin/icon.png: it does not read that file on its own.
cd llm-wiki && claude
AutoGineer scanned these files at commit 5fa5ee7.
Not scanned by AutoGineerThe author’s README also describes installing it as a Claude Code plugin marketplace. Read its install section: AutoGineer did not scan that path. https://github.com/MehmetGoekce/llm-wiki/blob/5fa5ee7d49a4346eeb1d92c1de7bf649e7654e91/README.md#quick-start
Not scanned by AutoGineerThe author’s README also describes installing it from a clone of its repository. Read its install section: AutoGineer did not scan that path. https://github.com/MehmetGoekce/llm-wiki/blob/5fa5ee7d49a4346eeb1d92c1de7bf649e7654e91/README.md#quick-start
Created by Mehmet Goekce. Published in MehmetGoekce/llm-wiki. Licence: MIT License.

Usage

From the brain’s own files

${user_config.wiki_path} (the "Wiki root:" line): your Logseq graph or Obsidian vault
${CLAUDE_PLUGIN_ROOT} (the setup workflow): the clone, so that setup finds templates/

Documentation by Mehmet Goekce

llm-wiki

Image: License: MIT Image: Release Image: Stars Image: Top Language Image: Last Commit

Build Karpathy's LLM Wiki with Claude Code. Two-layer cache architecture (L1/L2). Supports Logseq and Obsidian.

graph TB
    subgraph "Every Session — Auto-loaded"
        L1[L1: Claude Memory]
        L1R[Rules & Gotchas]
        L1I[Identity & Preferences]
        L1C[Credentials]
        L1 --> L1R
        L1 --> L1I
        L1 --> L1C
    end

    subgraph "On Demand — /llm-wiki query"
        L2[L2: Wiki]
        L2P[Projects & History]
        L2W[Workflows & Processes]
        L2K[Research & Learning]
        L2 --> L2P
        L2 --> L2W
        L2 --> L2K
    end

    NEW[New Knowledge] --> ROUTE{Quick rule?}
    ROUTE -->|Yes| L1
    ROUTE -->|No| L2

    USER[User Query] --> CLAUDE[Claude Code]
    CLAUDE --> L1
    CLAUDE -->|Deep question| L2

What is this?

Image: Wiki graph view after setup Your wiki after a few ingests — interconnected knowledge pages in Logseq's graph view.

In April 2026, Andrej Karpathy published a gist called "LLM Wiki" that got 5,000+ stars in days. The idea: let an LLM maintain a structured, cross-referenced wiki for you. Feed it raw sources, it extracts facts, links them together, and keeps everything consistent. The wiki becomes a persistent, compounding artifact instead of a graveyard of stale notes.

Everyone loved the concept. Almost nobody built one. The gist describes what to build, not how to wire it up with real tools, real files, and real workflows. llm-wiki is the implementation. It uses Claude Code as the LLM brain and either Logseq or Obsidian as the wiki UI, with a two-layer cache architecture that turned out to be the key insight Karpathy's gist does not mention.

Why use this?

5-minute setup. Install the plugin, run /llm-wiki setup, and you have a schema, namespaces, and git tracking. No manual design needed.
Claude becomes your wiki maintainer. /llm-wiki ingest updates 5-15 pages with cross-references from a single source.
L1/L2 architecture. Auto-loaded rules in memory (L1) + deep knowledge in the wiki (L2). No other tool has this.
Built-in quality checks. /llm-wiki lint finds orphan pages, stale content, broken refs, and credential leaks.
Logseq + Obsidian. Use whichever you already have. No tool switch required.

Quick Start

As a Claude Code plugin (recommended)

claude plugin marketplace add MehmetGoekce/llm-wiki
claude plugin install llm-wiki@mehmetgoekce

On Claude Code 2.1.275 or later, one line inside a session does the same:

/plugin install llm-wiki --marketplace MehmetGoekce/llm-wiki

Claude Code asks for one value, the Wiki root: your Logseq graph or Obsidian vault. The directory may be empty or not exist yet. Then, in any project:

/llm-wiki setup
/llm-wiki ingest "your first source"
/llm-wiki query "what do I know about X?"
/llm-wiki lint

/llm-wiki setup asks which tool you use and which namespaces you want, then creates the Schema, Dashboard, hub pages, Access-Log and llm-wiki.yml. The wiki starts sparse and gets denser with every ingest. New releases reach you through the plugin; nothing to copy.

Tested with Claude Code 2.1.296.

Without the plugin

Clone the repository and copy the skill into the project that should use it:

git clone https://github.com/MehmetGoekce/llm-wiki.git ~/llm-wiki
mkdir -p ~/myproject/.claude/commands
cp ~/llm-wiki/SKILL.md ~/myproject/.claude/commands/wiki.md

In the copy, replace two placeholders with absolute paths:

${user_config.wiki_path} (the "Wiki root:" line): your Logseq graph or Obsidian vault
${CLAUDE_PLUGIN_ROOT} (the setup workflow): the clone, so that setup finds templates/

On Linux (on macOS, write sed -i '' instead of sed -i):

sed -i -e 's|\${user_config.wiki_path}|/home/you/notes/wiki|g' \
       -e 's|\${CLAUDE_PLUGIN_ROOT}|/home/you/llm-wiki|g' \
       ~/myproject/.claude/commands/wiki.md

Then run /wiki setup in that project. The copy is invoked as /wiki <command>, stays at the version you copied, and needs the clone to stay where it is. The plugin is the recommended path.

The rest of this README writes /llm-wiki <command>. With a copied skill, type /wiki <command>.

Moving from a copied skill to the plugin

Install the plugin, enter your existing wiki directory as Wiki root, and delete the copied .claude/commands/wiki.md from your project. The wiki itself needs no change.

Coming from v1.6.0

The plugin's commands lost their second part: /llm-wiki:wiki ingest is now /llm-wiki ingest, and /llm-wiki:setup is now /llm-wiki setup. Update the plugin and use the new names.

The L1/L2 Architecture

This is the part not in Karpathy's gist, and it turned out to be the most important design decision.

When you start building a wiki, the instinct is to put everything in one place. That is wrong. Some knowledge must be available in every session, before you even ask a question -- things like "max 2-3 SSH calls to the VPS, never 10+" or "always use ISO 8601 dates." If the LLM has to query the wiki to learn these rules, it has already made the mistake.

Other knowledge only matters in specific contexts. The full history of a project. A detailed API workflow. Loading all of this into every session wastes the context window.

The solution maps to a concept every engineer knows: CPU cache hierarchy.

Layer	What	Size	Loading	Contains
L1	Claude Code Memory	~10-20 files	Auto-loaded every session	Rules, gotchas, identity, credentials
L2	Wiki (Logseq/Obsidian)	~50-200 pages	On-demand via `/llm-wiki query`	Projects, workflows, research, deep knowledge

graph TB
    subgraph "Every Session — Auto-loaded"
        L1[L1: Claude Memory]
        L1R[Rules & Gotchas]
        L1I[Identity & Preferences]
        L1C[Credentials]
        L1 --> L1R
        L1 --> L1I
        L1 --> L1C
    end

    subgraph "On Demand — /llm-wiki query"
        L2[L2: Wiki]
        L2P[Projects & History]
        L2W[Workflows & Processes]
        L2K[Research & Learning]
        L2 --> L2P
        L2 --> L2W
        L2 --> L2K
    end

    NEW[New Knowledge] --> ROUTE{Quick rule<br/>or gotcha?}
    ROUTE -->|Yes| L1
    ROUTE -->|No| L2

    USER[User Query] --> CLAUDE[Claude Code]
    CLAUDE --> L1
    CLAUDE -->|Deep question| L2

The routing rule is simple: Would the LLM making a mistake without this knowledge be dangerous or embarrassing? Then it belongs in L1. Would the mistake be merely inconvenient? Then L2.

Credentials are a special case -- they must live in L1 because the wiki is typically git-tracked. The L1 memory directory is excluded from git, making it the only safe place for secrets.

For the full deep-dive, see docs/l1-l2-architecture.md.

Commands

Command	Description
`/llm-wiki ingest <source>`	Process a source (URL, file, text), update 5-15 wiki pages
`/llm-wiki query <question>`	Two-stage search via hub index, synthesize answer with source attribution
`/llm-wiki prune [--months N]`	LRU-Demote: evict cold pages from the live index (default 6 months)
`/llm-wiki prune --l1`	L1-Verification: classify L1 rules, check due behavior claims against local evidence, re-verify / demote / delete
`/llm-wiki lint [--fix]`	Health check: orphans, stale pages, broken refs, index drift, credential leaks, due L1 claims
`/llm-wiki status`	Metrics dashboard: page count, health, hot/cold profile, recent changes

Ingest Flow

Ingest is the core operation. When you run /llm-wiki ingest "deployed v2.0 to production", here is what happens:

graph LR
    SRC[Source<br/>URL / File / Text] --> A[Phase 1<br/>Analyze & Extract]
    A --> B[Phase 2<br/>Scan Wiki<br/>Find affected pages]
    B --> C[Phase 3<br/>Update Pages<br/>Create new / Append]
    C --> D[Phase 4<br/>Quality Gate<br/>Properties? Cross-refs?<br/>No credentials?]
    D --> E[Phase 5<br/>Report<br/>Pages touched / Warnings]
    E --> GIT[git commit]

Phase 1 -- Analyze & Extract. Claude reads the source and extracts entities, facts, relationships, and dates. It classifies each piece by domain (business, technical, content, etc.) and checks whether it belongs in L1 (quick rule) or L2 (deep knowledge).

Phase 2 -- Scan Wiki. Claude reads the schema, then scans existing pages to find which ones the new information affects. If you mention a tool that already has an entity page, it knows to update that page too.

Phase 3 -- Update Pages. New pages get all required properties from the schema. Existing pages get new facts appended; when a fact supersedes a stated state (a status, a deadline, a decision), the block is rewritten and the old wording moves into a collapsed History -- nothing is deleted, and the current state stays on top. Target: 5-15 page touches per ingest.

Phase 4 -- Quality Gate. Before committing: Do all pages have required properties? Does every page have at least one cross-reference? Are there credential patterns in the content?

Phase 5 -- Report. Summary of pages created, updated, cross-references added, and any warnings.

Query

Query is two-stage, the way a CPU resolves an address before touching memory. Stage 1 (routing): Claude reads only the hub ### Index pages of the candidate namespaces — a cheap list of routing lines ([[page]] -- description #tags) — and picks the 3 most relevant pages by description. This is the wiki's page table. Stage 2 (read): it opens only those full pages and synthesizes an answer with source attribution. A full-text grep over every page is the L3 fallback, used only when routing finds nothing. Each full-page read is logged to an append-only Access-Log together with the routing reason it was picked (the matched index description or grep term) — so the log records not just what loaded but why, and it feeds prune. If the query reveals a gap, it offers to create a new page.

Prune

Prune is the eviction layer that keeps routing precise as the wiki grows. It reads the Access-Log, finds cold pages (no read in N months, default 6), and evicts them from the live index — the routing line moves from the hub ### Index to ### Archive and the page is marked archived::. This is demotion, not deletion: the file stays in place, every incoming [[link]] stays valid, and the page is still found by the L3 grep fallback (and re-promoted automatically if queried again). Crucially, prune never renames or moves a file — the wiki tool links by page name, so a move would break every backlink. Run it on a schedule (the command does not self-schedule).

--l1 is the L1 counterpart. Access frequency cannot find stale L1 rules — every L1 file loads every session, so a stale rule never looks cold; it shows up as the agent confidently acting on an outdated assumption. So L1 files carry a claim class: asserts-current-behavior: true for claims about a system's current state (a path, flag, version, quirk) and false for decisions and preferences, which never go stale. Behavior claims carry a verified date. /llm-wiki prune --l1 classifies unclassified files (it proposes, you confirm), checks due claims against read-only local evidence, and lets you re-verify, demote the rule to L2 as history, or delete it. It does not warn mid-session when a stale rule is about to justify an action — Claude Code loads L1, so there is no hook for that; it is on the roadmap.

Lint

Lint is the automated health check. It scans every wiki page and checks 13 rules: orphan pages (no incoming links), stale content (last updated 90+ days ago but still marked high-confidence), missing required properties, broken references, hub completeness, index drift (an active page with no routing line, or a routing line with no page), archived-in-live-index (a demoted page still routed), empty pages, weak cross-referencing, credential patterns, L1/L2 duplicates, due L1 claims (behavior claims whose verified date is missing or older than l1_verify_days), and block bloat (a block grown past 600 characters of prose, or an updated:: value used as a change log). Run with --fix and Claude auto-repairs what it can — including backfilling missing routing lines into hub indexes.

The Schema

The schema is the contract between you and the LLM. Without it, the LLM creates inconsistent pages -- one uses status: active, another state:: running, a third has no status field at all. With a schema, every page follows the same structure and automated quality checks become possible.

The schema defines:

8 namespaces (Business, Tech, Content, Projects, People, Learning, Reference, Careers)
5 page types (Entity, Project, Knowledge, Feedback, Hub) with required properties
Lint rules for automated health checks
L1/L2 boundary so the system knows where new knowledge should be routed

For the complete schema reference, see docs/schema-reference.md.

Logseq vs. Obsidian

Both wiki apps are supported. Choose based on your preference:

	Logseq	Obsidian
Properties	`property:: value` (inline)	YAML frontmatter
Format	Outliner (`-` prefix on every line)	Flat markdown
File names	`Wiki___Tech___Strapi.md`	`Wiki/Tech/Strapi.md`
Links	`[[Wiki/Tech/Strapi]]`	`[[Wiki/Tech/Strapi]]`
Backlinks	Automatic (graph-native)	Via plugin or core feature
Block addressing	Every line is a block	Paragraph-level
License	AGPL-3.0 (open source)	Proprietary (free for personal use)

Logseq shines when the LLM is doing the writing -- its outliner format means every block is independently addressable, so appending new content never disrupts existing structure.

Obsidian is better if you do a lot of manual editing -- flat markdown is more natural to write by hand, and the plugin ecosystem is massive.

For a detailed comparison with migration paths, see docs/logseq-vs-obsidian.md.

Before & After

The difference between a dead wiki and a living one is page quality.

Before -- a placeholder created when the page was first made:

- type:: knowledge
- domain:: content
- ## Newsletter
  - To be filled via /llm-wiki ingest.

After -- synthesized from multiple sources over several ingest operations:

- type:: knowledge
- domain:: content
- confidence:: high
- created:: 2026-03-15
- updated:: 2026-04-07
- ## Company Newsletter
  - Monthly newsletter targeting existing clients and prospects.
  - ### Metrics
    - | Metric | Value | As of |
      |--------|-------|-------|
      | Subscribers | ~240 | 2026-04-01 |
      | Open rate | 38% | 2026-04-01 |
      | Cadence | monthly | -- |
  - ### Content Strategy
    - 1 technical deep-dive + 1 business insight per issue
    - Always include a CTA to the latest blog post
    - Subject lines: question format performs 2x better
  - ### Open Questions
    - Segment list by industry vertical?
    - A/B test send time (Tuesday AM vs Thursday AM)?
  - ### Cross-References
    - [[Wiki/Content/Blog]] -- Source content
    - [[Wiki/Content/LinkedIn]] -- Promotion channel
    - [[Wiki/Reference/Workflows]] -- Publishing workflow

Every number has a date. Decisions have rationale. Open questions are explicit. Cross-references connect to related pages.

Configuration

Setup creates llm-wiki.yml in your wiki root. You can also create it manually:

# llm-wiki.yml

tool: logseq          # or "obsidian"
wiki_path: ~/Documents/MyWiki/
pages_dir: pages      # relative to wiki_path
memory_path: ~/.claude/projects/my-project/memory/
l1_verify_days: 90    # optional: re-verify L1 behavior claims after N days

namespaces:
  - Business
  - Tech
  - Content
  - Projects
  - People
  - Learning
  - Reference
  - Careers

# Lint settings
lint:
  stale_threshold_days: 90
  min_cross_refs: 1
  credential_patterns:
    - "token::"
    - "password::"
    - "secret::"
    - "api.key::"

# Ingest settings
ingest:
  target_page_touches: [5, 15]   # min, max pages per ingest
  append_only: true              # never delete content; superseded state moves to a collapsed History

# Language (for multilingual wikis)
language:
  business: en    # Language for business content
  tech: en        # Language for technical content

Trade-offs

No system is perfect. Some things to know:

The schema feels overengineered at first. With 10 pages, defining 5 page types and 8 lint rules seems like overkill. Past 50 pages, you will be grateful for the consistency. Define the schema early -- it is much harder to retrofit one later.
Two systems means you need a clear boundary. Having both L1 and L2 means you could accidentally put the same information in both places. The lint rule for L1/L2 duplicates exists precisely for this reason.
Parallel agents can conflict. If you have multiple Claude sessions writing to wiki files simultaneously, concurrent edits can cause conflicts. Treat wiki files as a shared resource.
Start with fewer hub pages. Let them emerge organically from ingest operations rather than creating empty hubs upfront.

Documentation

FAQ — Common questions before you install
Troubleshooting — Setup, integration, and runtime issues
L1/L2 Architecture — Why two layers, how to route knowledge
Schema Reference — Page types, properties, lint rules
Logseq vs. Obsidian — Detailed comparison and migration notes

Privacy

llm-wiki has no backend and collects nothing. It is a skill and a few shell scripts that run inside your own Claude Code session.

Wiki pages, the access log and llm-wiki.yml are written to your local Logseq graph or Obsidian vault and stay there. Whatever you ingest ends up in those files, including names or contact details if the source contains them.
If you set memory_path, the skill also reads your local Claude Code memory directory: query may consult it, lint reports rules that are due for a check, and prune --l1 classifies, updates, moves or deletes memory files, each one only after you confirm it. lint never prints the content of a memory file. Without memory_path the skill does not touch that directory.
The skill and the scripts send nothing to the author or to any third party. There is no telemetry.
The only network access is the page fetch that ingest makes when you pass a URL as the source.
Commits are local. Nothing is pushed unless you push your wiki yourself.
Claude reads the content you work with in order to do the work. That processing is covered by your own Claude plan and Anthropic's terms, not by this plugin.

Credits

Inspired by Andrej Karpathy's LLM Wiki gist
Built with Claude Code
Works with Logseq and Obsidian

License

MIT -- see LICENSE for details.

CHANGELOG.md

Changelog

All notable changes to this project will be documented in this file.

Format based on Keep a Changelog. This project adheres to Semantic Versioning.

[Unreleased]

[1.8.1] - 2026-11-07

The plugin directory refused v1.8.0 as well: it judges a file's type by its extension, and the three Mermaid diagrams ended in .mmd.

Changed

The architecture diagrams moved from diagrams/*.mmd into fenced Mermaid blocks in docs/diagrams.md, where GitHub renders them. No change to the plugin's behavior.

Removed

The diagrams/ directory.

[1.8.0] - 2026-11-07

No scripts. Anthropic's plugin directory accepts executable files only from Verified organizations and refused v1.7.1 for its two shell scripts. /llm-wiki setup now creates the wiki itself; the wiki it creates is the same.

Changed

/llm-wiki setup writes the pages, llm-wiki.yml and .gitignore itself instead of running scripts/init-wiki.sh. It renders the same templates, asks the same questions, never overwrites a file and commits only the files it created. Tested against v1.7.1 in both tool modes, with the default and a custom namespace list: every page is byte-identical.
An invalid answer (tool, namespace name) is asked again instead of ending setup.
llm-wiki.yml writes an empty value as pages_dir: without the trailing space v1.7.1 left. Both read as empty.
Setup needs no python3 any more. git stays optional.

Added

Documentation, support and privacy policy links in the plugin manifest, read by the plugin directory for its listing.
Privacy section in the README. It names the optional access to the Claude Code memory directory.
Security policy with a private channel for vulnerability reports.

Removed

setup.sh and scripts/init-wiki.sh.

Migration

Plugin users: nothing to do.
Copied /wiki skill: keeps working. To make a new copy, follow "Without the plugin" in the README: copy SKILL.md, replace the wiki root and the clone path, run /wiki setup.
Anyone who ran ./setup.sh: install the plugin, or copy the skill by hand as above.

[1.7.1] - 2026-10-11

Housekeeping for a listing in Anthropic's plugin directory. No change to the skill or the scripts.

Added

Plugin icon in the .claude-plugin directory (1024 x 1024 PNG).

Fixed

Two spec scenarios showed a made-up API key as sample input (openspec/specs/lint.md scenario 6, openspec/specs/ingest.md scenario 3). The directory's validation reads such a string as a real secret, so the scenarios now describe the value instead of showing one.

[1.7.0] - 2026-10-11

One command. v1.6.0 shipped the plugin as two skills, /llm-wiki:wiki and /llm-wiki:setup. The plugin is now a single root skill with subcommands, as originally intended.

Changed

The plugin command is /llm-wiki <subcommand>. /llm-wiki:wiki ingest becomes /llm-wiki ingest, and /llm-wiki:setup becomes /llm-wiki setup. This breaks the v1.6.0 command names; see Migration.
The skill moved from skills/wiki/SKILL.md to SKILL.md in the repository root. The plugin has no skills/ directory any more: with one, Claude Code would not load the root file as the plugin's single skill (plugin.md REQ-860, REQ-862).
Setup is a subcommand of the skill instead of a skill of its own.
README, docs, specs and page templates write /llm-wiki <command>.
A skill copied by setup.sh is still .claude/commands/wiki.md and still invoked as /wiki, so it never collides with the plugin. setup.sh now also writes the path of the repository clone into the copy, which makes /wiki setup work there.
The pointer file wiki.md stays until v1.8.0 and points to SKILL.md.

Migration

From v1.6.0: update the plugin and type /llm-wiki ... instead of /llm-wiki:wiki ... and /llm-wiki setup instead of /llm-wiki:setup. The Wiki root option and the wiki are unaffected.
Copied skills (/wiki) are unaffected.

[1.6.0] - 2026-10-11

llm-wiki is now a Claude Code plugin. Until now, installing meant cloning the repo and letting setup.sh copy wiki.md into one project: no update path, one copy per project, and a skill that did not know where the wiki was. The repository now doubles as its own plugin marketplace.

Added

Plugin and marketplace manifests (.claude-plugin/). Install with claude plugin marketplace add MehmetGoekce/llm-wiki and claude plugin install llm-wiki@mehmetgoekce.
Wiki root option. The plugin asks for the wiki directory once and hands it to the skill. Everything else stays in llm-wiki.yml.
/llm-wiki:setup: creates the wiki skeleton from inside Claude Code.
scripts/init-wiki.sh: non-interactive page and config creation, used by both setup.sh and the setup skill. Validates all input before writing; a second run skips everything.
Spec openspec/specs/plugin.md (REQ-830-880). config.md REQ-670-672 define how the wiki root is resolved. Counts: 348 requirements, 104 scenarios.

Changed

wiki.md moved to skills/wiki/SKILL.md. A pointer file stays at the old path until v1.7.0. With the plugin the command is /llm-wiki:wiki <command>; a copied skill stays /wiki.
setup.sh asks the same questions as before and delegates page creation to the init script.
The initial commit contains only the files setup created. Before, git add -A also committed whatever else was uncommitted in an existing vault.
Entering skip at the memory path prompt now skips it; before, the word was written to memory_path.
A missing llm-wiki.yml is reported with the wiki root and both ways to create it.

Fixed

The skill never received the wiki location. setup.sh replaced a <CONFIG_PATH> placeholder that wiki.md did not contain, so the copied skill had to infer the wiki root from context. A copied skill now carries the absolute path.
The Dashboard page was created with a literal {{NAMESPACES}} line: the template used a placeholder the renderer did not fill. New wikis get the namespace links.

Migration

Existing wikis need no change. To move from a copied skill to the plugin: install it, enter the existing wiki directory as Wiki root, delete .claude/commands/wiki.md from the project.
An existing Dashboard with a {{NAMESPACES}} line: replace the line by hand with one [[Wiki/<Namespace>]] link per namespace.
Several wikis on one machine: the plugin holds one Wiki root per user. See the FAQ.

Not included

A SessionStart hook for due L1 claims, a deterministic lint script, and the listing in Anthropic's plugin directory. Separate changes.

1.5.1 - 2026-10-05

Fixed

Five places still described page updates as append-only ("never overwrite"), which v1.5.0 replaced with State + History (REQ-032, REQ-032a/b): openspec/AGENTS.md, docs/l1-l2-architecture.md, both Schema.md templates and .github/SECURITY.md. New installs got a Schema page that contradicted wiki.md. The Access-Log stays append-only.

1.5.0 - 2026-09-28

Current state on top, history collapsed. The append-only rule ("never overwrite, only append") kept every fact, but it also turned long-lived blocks into paragraphs of dated addenda: a task picked up "Status <date>: ..." sentences until the valid state sat in the last line of 2,400 characters, and a hub's updated:: property grew into a 5,000-character change log. Nothing was lost, but nothing was readable either. Piloted on a real hub page before release.

Changed

Ingest (REQ-032, new REQ-032a/b): delete nothing, but overwrite stale state. A fact that supersedes nothing is still appended. A fact that supersedes a stated state rewrites the block's headline, properties and next step, and the superseded wording moves, dated and verbatim, into a collapsed History child (Logseq collapsed:: true, Obsidian folded callout).
updated:: holds the date only (REQ-035). Change notes go to the commit message; hubs keep them in a collapsed ## Change log.
Query write-back follows the same rule (REQ-423).

Added

Format section State + History in wiki.md and docs/schema-reference.md, with Logseq and Obsidian examples.
/wiki lint Rule 13 Block Bloat (REQ-230-234): warns on blocks with more than 600 characters of prose outside history sections, and on updated:: values that are more than a date. --fix moves updated:: notes verbatim into ## Change log; oversized blocks are never auto-restructured.
Scenarios: ingest 11, lint 15-16. openspec/project.md counts: 315 requirements, 95 scenarios.

Migration

Existing pages stay valid. Run /wiki lint to find bloated blocks, then restructure them by hand or on the next ingest that touches them. lint --fix handles the updated:: part.

1.4.0 - 2026-09-16

L1 verification. Access-based eviction cannot find stale L1 rules: every L1 file loads every session, so a stale rule never looks cold. It shows up as the agent confidently acting on an outdated assumption. L1 staleness is now tied to the kind of claim a rule makes. Prompted by a reader asking what moves a rule back out of L1 once auto-loading keeps repeating a stale assumption.

Piloted on a real, long-lived L1 (15 files) before release. The pilot changed the spec: verdicts per claim with an evidence basis, corrections that also reach description and the index line, reference rewriting before removal, and a carry-over summary instead of dumping full files.

Added

L1 frontmatter keys asserts-current-behavior (true = claim about a system's current state, false = decision/preference, never stale) and verified (last evidence check). Read at top level or inside a metadata: block; writes preserve all other keys.
/wiki lint Rule 12 L1 Verification Due: warns on behavior claims never verified or older than l1_verify_days, reports the unclassified count as one info line. No auto-fix, never prints L1 bodies.
/wiki prune --l1 [--batch N] [--days N]: classify unclassified L1 files (propose, confirm), check due claims against read-only local evidence (supports / contradicts / inconclusive), then per rule re-verify, demote to L2 as a history block (source:: l1-demotion), or delete. Verdicts are per claim with an evidence basis (executed / source / file). Corrections reach body, description, and index line; references from other L1 files are rewritten before removal. Credential rules are never demoted.
Config key l1_verify_days (default 90).
Specs: l1-l2-routing.md REQ-370-379, lint.md REQ-220-225, prune.md REQ-900-929, config.md REQ-660-661, with scenarios. docs/schema-reference.md now also documents lint rules 10-11.

Changed

REQ-353 (flag L1 files unreferenced for 90 days) superseded by REQ-370-379.
openspec/project.md spec table brought up to date (prune added, counts: 308 requirements, 92 scenarios).

Not included

A runtime planning-vs-action gate (warn when a due rule is about to justify an action). Claude Code loads L1, not llm-wiki, so there is no hook to enforce it (REQ-379). On the roadmap.

Known limitations

Not yet confirmed that Claude Code keeps asserts-current-behavior and verified when it rewrites a memory file's frontmatter (e.g. its own modified timestamp). If a key disappears, lint will count the file as unclassified again rather than fail silently.

Fixed

docs/l1-l2-architecture.md: removed the claim that /wiki lint flags L1 files unreferenced for 90 days and L2 pages queried in every session. Neither is implemented; lint only flags L1/L2 duplicates. The section now explains why access-based eviction cannot see L1 staleness; the L1 mechanism added in this release replaces that claim.

1.3.0 - 2026-06-08

Routing transparency. The Access-Log already recorded which pages a query pulled; now it records why each was picked. Loading becomes auditable — not just what loaded, but the index description or grep term that selected it. Inspired by a reader pointing out that knowing when and why context loads is half the problem.

Added

Routing reason in the Access-Log — every query log line now carries a matched: "<reason>" field: the matched hub ### Index routing description / #tag on index routing, or the grep term on the L3 fallback (<date> -- [[page]] -- query -- matched: "..."). Shows not just WHICH page loaded but WHY it was selected for the question.
status cache profile now breaks down the most frequent matched: reasons per hot page, surfacing mis-routing: a page always hit via the same grep term instead of its index line signals a weak or missing routing description in its hub ### Index.

Changed

openspec/specs/query.md — REQ-450 line format extended; new REQ-450b defines the matched: reason semantics (<= 60 chars, quoted, parsing-safe).

Notes

Backward compatible: legacy Access-Log lines without matched: stay valid (the field is additive). prune/status parse date + [[page]] from fixed positions (split on --), so the suffix never affects LRU aggregation.

1.2.0 - 2026-06-07

Two retrieval-scaling mechanisms, the CPU-cache analogy carried through to the index and eviction layers. As a wiki grows past a few dozen pages, grep-over-everything gets imprecise; these keep retrieval sharp.

Added

Hub-Index-Routing — two-stage query. Each hub page carries an ### Index of routing lines ([[page]] -- description #tags); query reads the cheap index first, picks the 3 best pages by description, then reads only those. Full-text grep becomes the L3 fallback. ingest maintains the routing line for every page (the wiki's page table).
LRU-Demote — new /wiki prune [--months N] command. query appends every full-page read to an append-only Wiki/Reference/Access-Log; prune evicts pages with no access in N months (default 6) from the live index into the hub ### Archive, marked archived::. Eviction never deletes, renames, or moves a file — incoming [[links]] stay valid and the page is still greppable (L3). Re-promotion is automatic on re-hit.
openspec/specs/prune.md — new spec (EARS requirements + BDD scenarios)
Lint rules 10 (Index Drift) and 11 (Archived-in-Live-Index), both auto-fixable; lint --fix now backfills missing routing lines into hub indexes
status now reports a hot/cold cache profile (most-queried pages, demote-ready cold pages)
Access-Log page templates for Logseq and Obsidian; setup.sh scaffolds the Access-Log page

Changed

Hub page templates (Logseq + Obsidian) now include ### Index and ### Archive sections
docs/schema-reference.md — Hub example updated; new "Hub-Index-Routing & LRU-Demote" section
Specs updated: query.md (Phase 0 routing + Phase 1b access logging), ingest.md (routing-line maintenance), lint.md (11 rules), schema.md (hub index, archived:: marker, Access-Log page)

Notes

Backward compatible. Existing wikis keep working; run /wiki lint --fix once to backfill routing lines into hubs that predate this release.
archived:: is the canonical demote marker and is valid on any page type. status:: archived is set additionally only where the type's status enum allows it (Entity).

1.1.1 - 2026-04-18

Added

README badge row — license, release, stars, top language, last commit
docs/faq.md — 10 questions first-time users actually ask (paid plan, L1/L2 rationale, tool choice, credential safety, wiki growth thresholds)
docs/troubleshooting.md — setup, wiki-app integration, Claude Code integration, and wiki-growth issues with symptom → cause → fix format
README "Documentation" section linking all five docs pages

Notes

Documentation-only release. No code, schema, or command changes.
Focus: adoption friction. The v1.1.0 feedback pointed at missing onboarding docs, not missing features.

1.1.0 - 2026-04-10

Added

7 OpenSpec specifications with 162 EARS requirements and 66 BDD scenarios
- ingest.md — 5-phase source processing pipeline
- query.md — Search, synthesis, write-back, source attribution
- lint.md — 9 health checks with auto-fix rules
- schema.md — Page types, property validation, format rules
- config.md — Configuration loading and error handling
- setup.md — Interactive installer specification
- l1-l2-routing.md — L1/L2 boundary decision logic
GitHub issue templates (bug report, feature request)
Pull request template with dual-tool testing checklist
SECURITY.md with responsible disclosure process
.gitignore for editor and OS files
CHANGELOG.md

Fixed

setup.sh: Add prerequisite checks for python3 and git
setup.sh: Add set -eo pipefail for stricter error handling
setup.sh: Validate namespace names (letters, numbers, hyphens only)
setup.sh: Skip existing wiki pages instead of silently overwriting
setup.sh: Prompt before overwriting existing llm-wiki.yml

1.0.0 - 2026-04-07

First stable release.

Added

/wiki ingest — 5-phase source processing pipeline (URL, file, text)
/wiki query — Search, synthesis, and source attribution
/wiki lint — 9 automated health checks with --fix auto-repair
/wiki status — Wiki metrics and health dashboard
setup.sh — Interactive installer for Logseq and Obsidian
L1/L2 dual-layer cache architecture (CPU cache metaphor)
Templates for both Logseq (outliner) and Obsidian (flat markdown)
Schema with 5 page types: Entity, Project, Knowledge, Feedback, Hub
config.example.yml for reference configuration

Security

Credential leak detection (lint rule 6) scans for tokens, passwords, secrets
L1/L2 security boundary: credentials stay in L1 (git-excluded), wiki is git-tracked

58 files · 2 not served here

Advantages

5-minute setup. Install the plugin, run /llm-wiki setup, and you have a schema, namespaces, and git tracking. No manual design needed. evidence: README.md
Claude becomes your wiki maintainer. /llm-wiki ingest updates 5-15 pages with cross-references from a single source. evidence: README.md
L1/L2 architecture. Auto-loaded rules in memory (L1) + deep knowledge in the wiki (L2). No other tool has this. evidence: README.md
Built-in quality checks. /llm-wiki lint finds orphan pages, stale content, broken refs, and credential leaks. evidence: README.md
Logseq + Obsidian. Use whichever you already have. No tool switch required. evidence: README.md

Limitations

The schema feels overengineered at first. With 10 pages, defining 5 page types and 8 lint rules seems like overkill. Past 50 pages, you will be grateful for the consistency. Define the schema early -- it is much harder to retrofit one later. evidence: README.md
Two systems means you need a clear boundary. Having both L1 and L2 means you could accidentally put the same information in both places. The lint rule for L1/L2 duplicates exists precisely for this reason. evidence: README.md
Parallel agents can conflict. If you have multiple Claude sessions writing to wiki files simultaneously, concurrent edits can cause conflicts. Treat wiki files as a shared resource. evidence: README.md
Start with fewer hub pages. Let them emerge organically from ingest operations rather than creating empty hubs upfront. evidence: README.md

Security

Risk level: No risk found

This brain runs

Agent instructions that run or fetch something (18)

SKILL.md: Run /llm-wiki setup to create one." If its `wiki_path` names a different directory than the wiki root above, warn once, naming both paths, and continue with the wiki root above.
SKILL.md: Meant as a periodic run (default cadence N = 6 months) — wire it via your scheduler;
SKILL.md: READ-ONLY and LOCAL: check existence, read files, search contents, read dependency manifests, run commands only with `--version` / `--help`.
SKILL.md: Evidence basis per claim: `executed` (read-only command), `source` (read the implementing code, not run), or `file` (existence/content).
SKILL.md: Skip -> file untouched, stays due for the next run
SKILL.md: Timestamp the lint run
SKILL.md: Last prune run (newest archived:: date) + a recommendation when the cold-page count is high
SKILL.md: Comparison to last status run (if Dashboard page exists)
SKILL.md: git: if the user wants git init or the root is a repository, check `git --version`.
SKILL.md: Run `date +%Y-%m-%d` once.
SKILL.md: Git init, only if the user agreed and the root has no `.git`: `git -C "<root>" init`.
SKILL.md: Commit, only if the root is a git repository and this run created at least one file.
SKILL.md: Run lint on imported pages
SKILL.md: decision:: run benchmark B1 first, then delete (2026-09-12)
SKILL.md: - **Next step:** run B1, otherwise default A (check volumes, delete)
SKILL.md: status: open · ticket: OPS-195 · decision: run benchmark B1 first, then delete (2026-09-12)
SKILL.md: **Next step:** run B1, otherwise default A (check volumes, delete)
openspec/AGENTS.md: git is optional.

Attribution and licence

Created by

Mehmet Goekce

Declared authors

Mehmet Goekce (declared in .claude-plugin/plugin.json)

Publisher

Mehmet Gökçe (Community)

Source

MehmetGoekce/llm-wiki · commit 5fa5ee7

Licence

MIT License (files served here)

ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-12

AutoGineer is not affiliated with or endorsed by Mehmet Goekce.

Install from source

2 of its files are not served here, so there is no ZIP. MehmetGoekce/llm-wiki at 5fa5ee7