# llm-wiki's last five releases moved provider automation out of the public repository

> llm-wiki compiles a file-based knowledge base and ships it as a plugin for Claude Code, OpenAI Codex and OpenCode, with two entry points of deliberately different power and a changelog that reads like a governance record. The interesting story is not the wiki. It is that five consecutive releases progressively deleted capability from the public package, moved it behind private adapters, and left the verification primitives in.

**nvk/llm-wiki** — LLM-compiled knowledge bases for any AI agent. Parallel multi-agent research, thesis-driven investigation, source ingestion, wiki compilation, querying, and artifact generation. 

- Repository: https://github.com/nvk/llm-wiki
- Website: https://llm-wiki.net/
- Stars: 1,376 · Forks: 130
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/nvk-llm-wiki

## Five changelog entries, and four of them remove things from the public package

Read the six most recent entries in order and the direction is consistent.

v0.20.0, Governed remote writes, extends private adapters with exact remote-resource allowlists, declared read and write effects, explicit approval bound to an exact plan hash, expected revisions, stable idempotency keys, private verified receipts and content-free terminal reporting.

v0.21.3, Adapter-boundary transition, then says provider-specific workflow material from that line is superseded by manifest-driven routing and lives only in the corresponding private adapter.

v0.22.0, Declarative private-adapter routing, says the public plugin discovers the route before ingestion but no longer embeds any provider's authentication, browser, recovery or editing workflow.

v0.23.0, Personal specialist framework, says the public release contains the framework only, and that personal specialist packages and wiki-derived candidate reports are not bundled or published.

So authentication, browser automation, recovery and editing workflows all left the repository between two releases, replaced by a declarative manifest that names an intent and an exact-URL route. What stayed is the machinery for constraining writes: allowlists, plan hashes, idempotency keys, receipts.

This is an unusual shape for a 0.x project and it is the most interesting thing about it.

## Checkpoint writes are explicitly barred from authorising a commit

The v0.24.0 entry is the densest sentence in the changelog, and one clause in it matters more than the rest.

Checkpoint export writes comprehensive cross-topic project handoffs under `docs/knowledge/<slug>/`. The guarantees listed are dry-run-first create and refresh, read-only verification and bounded import, exact source and section coverage, explicit omissions, semantic privacy minimization, deterministic sealing, attested overrides and a thin-output guard.

Then: checkpoint writes never authorize commit, publication or import.

That is a capability boundary stated in the release notes rather than buried in a policy file. An export produces a document. Something else decides whether that document enters version control, gets published, or is read back in. Deterministic sealing and attested overrides are the two halves of the same idea: the artefact's state is reproducible, and any departure from the deterministic result has to be declared.

The thin-output guard is worth noting as a design choice too. A handoff that comes out nearly empty is treated as a failure condition rather than a success, which stops an empty checkpoint from looking like a clean one.

## Two entry points, and only one of them is allowed to fire on its own

The canonical invocations split into a read-only half and a writing half, and the difference is explicit.

`$wiki-query` is described as the small, explicit, read-only skill for lookups. It never activates implicitly and it never changes wiki files. In the Codex CLI or IDE you select it by typing `$` or opening `/skills`. A call looks like `wiki-query "What does the wiki say about hardware wallet threat models?"`.

`@wiki` is the full research and maintenance entry point, and natural-language wiki requests can still auto-activate it. Its subcommands include `research`, `collect`, `ingest`, `audit`, `session status`, `feedback list --unpromoted` and an `ll` lookup.

So `ingest https://example.com/article` and `collect "bitcoin memes" --wiki memes-bitcoin` both write, and both sit behind a skill that can trigger itself. That is the single most important thing to understand about the tool before enabling it in an environment where you mind what gets written.

There is an opt-out and a hook story too. `@wiki session disable` is the documented way out, and automated session capture runs through bundled hooks you have to trust by opening `/hooks`. The skill works without that trust, which is the better default: the reading and writing path does not depend on the capture path.

## On OpenCode the instruction file is fetched from `master` at the start of every session

The OpenCode setup is not a plugin install. It is an instruction URL in `opencode.json`:

```json
{
  "instructions": ["https://raw.githubusercontent.com/nvk/llm-wiki/master/plugins/llm-wiki-opencode/skills/wiki-manager/SKILL.md"]
}
```

The stated behaviour is that OpenCode fetches that URL fresh on every session start, so there are no manual updates. The consequence is that the instruction file your agent reads can change with the repository's default branch, with no local action and no version marker.

The alternative is one line, and it is worth taking:

```bash
curl -sL https://raw.githubusercontent.com/nvk/llm-wiki/master/plugins/llm-wiki-opencode/skills/wiki-manager/SKILL.md > ~/.config/opencode/AGENTS.md
```

That gives you a local copy you control. There is also a smaller preset that points `instructions` at a `wiki-query` skill instead of `wiki-manager`, for a read-only configuration.

Two details in the permissions block are worth reading. The `external_directory` map is required because the wiki hub lives outside the project directory, and the example allowlist includes a macOS iCloud Drive path, `~/Library/Mobile Documents/com~apple~CloudDocs/wiki/**`, which does nothing on Linux or Windows. Alternatively there is a `--local` mode that puts the wiki in `.wiki/` inside the project and skips the external permission entirely.

## The project calls its own OpenCode profile best-effort, and tells you to lock permissions down

This is the passage that most affects whether you should trust the OpenCode path:

> The OpenCode profile is sync- and budget-tested, but not tied to one model, so it does not have a provider-specific live quality gate. Treat it as a portable best-effort preset.

So the Claude Code and Codex paths get pinned model testing and the OpenCode path does not, and the project says so rather than implying parity. The advice that follows is to keep OpenCode's write and shell permissions disabled for query-only sessions.

Put that next to the entry point design and the shape is coherent. The read-only skill is the safe default, the best-effort profile is the portable one, and both are configured for reading. The writing capability is where model quality actually matters, and that is where the testing is claimed.

The v0.25.0 entry adds the other half of the safety story, a lint gate:

`llm-wiki lint --fail-on critical|warning|suggestion`

Three thresholds, and choosing one turns lint output into an exit code. That is what makes the gate usable in the same pipeline as `mise run check` style verification rather than something a human has to remember to read.

## Ideas, briefs and Projects are three states with an explicit promotion between them

The workflow description is short and specific. You capture rough Ideas, research and shape them, then explicitly promote approved briefs into delivery Projects.

The word doing the work is explicitly. Promotion is a separate, deliberate act, not something that happens because the research finished. That is the difference between a research tool that writes into your codebase and one that stops at a proposal.

The supporting surface follows the same shape. `feedback list --unpromoted` shows what is waiting on a decision, so the queue of things that were researched but not adopted is a first-class, listable thing rather than a memory. `audit --project` runs against a named project. `session status` and `session disable` cover the capture layer.

Everything else in the feature list hangs off this: parallel multi-agent research, thesis-driven investigation, collector catalogs, source ingestion, compilation, querying and artifact generation. Those are the mechanisms; the Ideas to briefs to Projects promotion is the part that decides what actually ships.

And the wiki itself is a directory of files, Obsidian-compatible, which is what makes the whole thing portable between harnesses rather than trapped inside one agent's memory.

## Two spellings of the Claude plugin directory sit at the repository root

The root tree holds `.agents/`, `.claude-plugin/`, `.claude/`, `AGENTS.md`, `CLAUDE.md`, `benchmarks/`, `claude-plugin/`, `plugins/`, `profiles/`, `scripts/` and `tests/`.

Two of those are plugin directories for the same harness in two spellings, one with a leading dot and one without. Only one of them can be the conventional plugin metadata directory, and both are checked in, so it takes a look at the contents to tell which is live.

Alongside them, both `AGENTS.md` and `CLAUDE.md` are present. Given that the project ships instructions for three different agents, having two root-level instruction files is defensible, but combined with the duplicate plugin directory it reads as a migration that left both sides in place.

`profiles/` is the directory that the changelog's multi-runtime work implies, and `benchmarks/` exists at the root with no numbers in the visible text, so the benchmark suite is there and its results are not in the README.

The last cross-runtime detail is the sandbox requirement: running Codex under a wrapper such as nono means Codex needs read and write access to `$HOME/.codex` for the plugin install to complete. That is a filesystem grant worth checking against your sandbox policy before you install.

## Conclusion

llm-wiki is worth reading if you are building agent memory that has to survive across harnesses, because the file-based design and the Obsidian compatibility mean the wiki outlives whatever agent wrote it. Four things to check before you install it. Decide which entry point you actually want: `$wiki-query` is read-only and never fires implicitly, while `@wiki` can auto-activate and writes. On OpenCode, the instruction file is fetched from the `master` branch at the start of every session, so pin it locally with the curl line if you want reproducibility. Note that the project calls its own OpenCode profile best-effort and advises keeping write and shell permissions off for query-only sessions. And expect the provider automation to be absent: five releases moved it into private adapters, which means authenticated ingestion of a real site is not something this repository does.

## FAQ

### How do I install llm-wiki for Claude Code?

One command: `claude plugin install wiki@llm-wiki`, which is the native plugin path. For OpenAI Codex you instead register a marketplace and add the plugin, with `codex plugin marketplace add nvk/llm-wiki` followed by `codex plugin add wiki@llm-wiki`, then start a new Codex thread. A local checkout can be bootstrapped with `./scripts/bootstrap-codex-plugin.sh --scope user --verify`.

### How do I set up llm-wiki for OpenCode?

OpenCode uses an instruction file rather than a plugin. Add the URL of the wiki-manager SKILL.md on the master branch to the `instructions` array in `opencode.json`, project-level or at `~/.config/opencode/.opencode.json` for global, and allow `external_directory` access to your wiki hub because it lives outside the project. The `external_directory` permission is skipped entirely if you use `--local` mode, which keeps the wiki in `.wiki/` inside the project.

### How do I use llm-wiki once it is installed?

Two entry points with different power. `$wiki-query "your question"` is the small read-only lookup, selected by typing `$`, and it never activates implicitly or changes wiki files. `@wiki` is the full research and maintenance entry point and can auto-activate from natural language, with `research`, `collect`, `ingest`, `audit`, `session status` and `feedback list --unpromoted` beneath it. `@wiki session disable` is the documented opt-out.

### Is llm-wiki better than RAG?

The visible material makes no such comparison and does not discuss retrieval pipelines, so it cannot answer that. What it does state is the shape: llm-wiki compiles a file-based knowledge base that any agent can read, is Obsidian-compatible, and exposes a read-only `wiki-query` skill for lookups alongside a separate `@wiki` skill for research and maintenance. Whether that beats a retrieval setup depends on your corpus and your harness, which is not something this repository measures.

## Sources

- [License: MIT](https://github.com/nvk/llm-wiki/blob/master/LICENSE)
- [nvk/llm-wiki on GitHub](https://github.com/nvk/llm-wiki)
- [Project website](https://llm-wiki.net/)
- [README](https://github.com/nvk/llm-wiki/blob/master/README.md)
- [Releases](https://github.com/nvk/llm-wiki/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nvk-llm-wiki