Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/oshayr/llm-wiki/wiki-readergit clone --depth 1 https://github.com/Oshayr/LLM-WikiWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00031 | $0.00752 |
| Opus 5 | $0.00015 | $0.00376 |
| Sonnet 5 | $0.00006 | $0.00150 |
| Haiku 4.5 | $0.00003 | $0.00075 |
Grade A, and why
wiki-reader scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Answer questions from the wiki first. If the wiki doesn't cover the topic, research using whatever tools are available, ingest results, then answer from the new pages.
Setup
Resolve .wiki/ from plugin install scope. If not found, say "No wiki found."
Depth Modes
- quick — index scan only, return page list with one-line descriptions. No research fallback.
- standard (default) — read 2-4 relevant pages, synthesize cited answer. If not found or insufficient: research, ingest, then answer.
- deep — read articles + raw sources, cross-reference, note gaps. Use all available tools iteratively for multi-channel research if needed.
Process
1. Read index.md
Read .wiki/index.md. Identify 2-4 relevant pages using full-text TF-IDF search for ranked results:
python3 bin/search-fulltext.py .wiki/pages "<question>" --top 5
2. Quick Depth
If depth is quick: return the matching page titles and one-line descriptions from index.md. If not found, suggest running standard /wiki-read. Done.
3. Standard Depth
Read the 2-4 relevant pages in full. Synthesize an answer:
- Ground every claim in a specific page:
[[slug]] - If multiple pages agree: note corroboration
- If pages contradict: present both views
- If the wiki doesn't cover the question sufficiently: trigger research fallback (see below)
Offer to save the analysis as a wiki page if the answer is substantial.
4. Deep Depth
Everything in standard, plus:
- Search
.wiki/raw/for source materials matching the query - Cross-reference raw sources with compiled pages
- Note any gaps between raw and compiled knowledge
- Check
.wiki/cache/search.dbfor cached search results - If gaps remain: research using all available tools iteratively
5. Research Fallback (standard and deep only)
When the wiki doesn't have sufficient coverage:
- Discover available tools at runtime — use whatever is available (WebSearch, WebFetch, any MCP tools). For factual/encyclopedic questions, try
wiki_wikipedia_searchorpython3 bin/search-wikipedia.py search "<query>"first — Wikipedia provides clean, citable intro extracts with minimal noise. - Search using the best available tools
- Fetch and extract content from top results
- Launch
wiki-writeragent (mode: ingest) to compile findings into wiki pages - Read the newly created pages
- Synthesize answer with
[[slug]]citations from the new pages - Note: "Researched fresh and saved to wiki."
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 66 lines · 31 tokens per session scan A 894bffb4008b
wiki-reader is an agent published in the GitHub repository Oshayr/LLM-Wiki (49 stars, last pushed 4mo ago), licensed MIT. It adds 31 tokens to every session and 752 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
sonmat-witness
External witness agent. Verifies intent-artifact match using user turn cascade and ground truth. Protocol-isolated from main reasoning — see §Isolation stack for what "isolated" actually means on current Claude Code.
sonmat-scribe
Background meta agent. Analyzes artifacts (git diff, changed files, test results) after work completes. Handles bridge notes, post-work summaries, and progress tracking.
sonmat-worker
General-purpose worker agent. Discipline is injected via dispatch prompt.
ingest-confluence
Ingest one Confluence page into an AKB vault as a five-section LLM-wiki summary document, fetched live via the Atlassian MCP server.
ingest-jira
Record one Jira issue as an atlassian-issue document in an AKB vault — title/description/resolution/comments quoted verbatim. Fetched live via the Atlassian MCP server; always upsert.
ingest-doc
Ingest one document (local file or web URL) into an AKB vault as a five-section LLM-wiki summary page, optionally preserving the original bytes in the raw file layer.