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 skills/zmij/agent-kb/knowledge-basenpx skills add zmij/agent-kb --skill knowledge-basegit clone --depth 1 https://github.com/zmij/agent-kbWhat 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.00086 | $0.01175 |
| Opus 5 | $0.00043 | $0.00588 |
| Sonnet 5 | $0.00017 | $0.00235 |
| Haiku 4.5 | $0.00009 | $0.00118 |
Grade A, and why
knowledge-base 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 — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Knowledge Base
A local, Qdrant-backed semantic index over this project's curated corpora. Use it before stating facts the repo's docs already answer — domain mechanics, architecture decisions, build invocations, concept-to-symbol bindings. Cheaper than re-reading docs every time, and it keeps answers grounded in what the project actually says.
Sources are declared in kb.yaml at the repo root. Call kb_list_sources
once per session if you don't know what's indexed here.
When to query (auto-trigger)
The KB owns what is true about the project as written down — prose and
bindings. It does NOT carry file paths, line numbers, or live signatures —
those rot per-commit and diverge per-worktree, and are LSP territory
(see the code-intelligence skill if installed). Compose the two: KB
answers what is the symbol, the LSP answers where it is right now.
Typical source types and their question shapes:
- markdown sources (user docs, architecture docs) — about to describe
how something works, why a design is the way it is, or quote a workflow.
kb_searchwithsource="<name>". - ontology — about to claim which class/function implements a concept, what the base class or substrate is. Returns qualified symbol names structurally in the payload; hand them to the LSP for live location and signature.
- make_targets — about to suggest "run this make target" or answer "what target does X". Each hit carries the target, module, description, dependencies and the exact invocation.
- cross-source — "where is X documented" with no scope hint: omit
sourceand let all corpora rank together.
When NOT to query
- Pure code questions where reading the file is faster (
Read,grep). - Anything outside the indexed corpora (third-party APIs, OS docs).
- Questions about the user's intent or current task state.
MCP tools
| Tool | Purpose |
|---|---|
kb_search |
Semantic search; pass source to scope, top_k to widen. |
kb_get |
Fetch the full chunk by id (returned by kb_search). |
kb_list_sources |
What is indexed and how many points each collection has. |
kb_reindex |
Run an indexer (rare — usually done from the shell). |
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 · 110 lines · 86 tokens per session scan A 7c9eeaaabf9d
knowledge-base is a skill published in the GitHub repository zmij/agent-kb (2 stars, last pushed 1mo ago), licensed MIT. It adds 86 tokens to every session and 1,175 once invoked, about $0.0004 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-31.
Other skills, from other repositories
agent-platform-rag-engine-management
Manage and query Agent Platform RAG Engine Corpora and retrieve grounded contexts using the Google GenAI SDK. Use when listing RAG corpora or files, inspecting a corpus, retrieving contexts, or generating content grounded in a RAG corpus. Do not use for standard database queries (use SQL/Spanner skills), Google…
9router-embeddings
Generate vector embeddings via 9Router /v1/embeddings using OpenAI / Gemini / Mistral / Voyage / Nvidia / GitHub embedding models for RAG, semantic search, similarity. Use when the user wants embeddings, vectors, RAG, semantic search, or to embed text.
potpie-source-ingestion
Use when the user explicitly asks to ingest, refresh, or deeply understand a repository, PR, issue, ticket, runbook, incident report, document, or web link into Potpie. The harness performs todo-driven discovery, uses local/GitHub/integration tools and read-only subagents when available, builds evidence-backed…
embedding-strategies
Select and optimize embedding models for semantic search and RAG applications. Use when choosing embedding models, implementing chunking strategies, or optimizing embedding quality for specific domains.
generate-rag-dataset
Generate a synthetic evaluation dataset from your RAG knowledge base. Creates diverse Q&A pairs with expected answers and relevant context, ready for LangWatch experiments and platform import. Use when you need test data for your RAG pipeline.
embeddings
Vector embeddings configuration and semantic search.