LLM Wiki Usage Guide
LLM Wiki Usage Guide
Practical guide for using this vault with LLM Wiki skills, Codex chat, Obsidian, and the obsidian-wiki setup CLI.
Introduction
LLM Wiki Usage Guide is the practical starting point for readers who want to operate an LLM Wiki environment instead of only reading about the idea. Practical guide for using this vault with LLM Wiki skills, Codex chat, Obsidian, and the obsidian-wiki setup CLI. The introduction focuses on the working setup: where the vault lives, which tasks belong in an agent chat, which tasks belong in Obsidian, and which terminal commands are only for setup or inspection.
This page matters because many first-time users confuse the installed obsidian-wiki CLI with the day-to-day wiki skills. A clean setup separates those responsibilities. Obsidian provides the Markdown knowledge base, the agent runs workflows such as status, ingest, capture, query, and lint, and Git or local backups preserve the change history. By the end of the article, readers should understand the operating model well enough to run a small status or ingest cycle without treating the wiki as a black box.
This vault is an LLM-maintained Obsidian knowledge base. The main workflow happens through an AI agent such as Codex, Claude Code, Gemini, Hermes, or another agent where the obsidian-wiki skills are installed.
The terminal command obsidian-wiki is mostly for setup and configuration. It does not directly run day-to-day commands like wiki status.
Quick Start
From an agent chat inside this vault or any configured project, type requests like:
wiki statusingest this filewhat do I know about OCI networking?capture this findinglint my wikiThe agent resolves the vault configuration, reads the relevant skill instructions, and updates or queries the markdown files.
Where To Do What
| Place | Use it for |
|---|---|
| Agent chat, such as Codex | Run wiki workflows: status, ingest, query, capture, lint, synthesize, update |
| Obsidian | Browse, edit, review, link, and search the generated markdown knowledge graph |
| Terminal | Install/configure skills, inspect config, list installed skills, run optional scripts |
| Git | Version, review, back up, and sync vault changes |
Useful Agent Prompts
Check Vault Status
wiki statusUse this after setup or before a big ingest. It should report what has been ingested, what changed, and whether the vault needs an append update, lint, or rebuild.
Add Knowledge
ingest this URL: https://example.com/articleingest the files in _raw/process this PDF into the wikiIngest should compile knowledge into the right pages, not simply add a one-off summary. Existing pages should be updated when the new source belongs there.
Ask Questions
what do I know about Kubernetes node pools?find my notes on OCI DevOps and summarize the key decisionsThe query workflow should read cheap sources first, such as index.md and frontmatter summaries, then open full pages only when needed.
Capture Quick Notes
capture this gotcha: Terraform provider aliases must be passed explicitly into child modules.drop this to raw for later: ...Use capture for small findings, transient notes, and things you do not want to fully organize immediately.
Maintain The Vault
lint my wikifind broken linksdedup my wikiconnect related pagesThese prompts help maintain frontmatter, links, tags, duplicate pages, and graph quality.
Terminal CLI
The installed CLI is:
obsidian-wikiIf your shell cannot find it, use the full path:
$HOME/.local/bin/obsidian-wikiCommon terminal commands:
obsidian-wiki infoobsidian-wiki listobsidian-wiki setupobsidian-wiki setup --vault /path/to/your/vaultImportant: obsidian-wiki is an installer/configuration helper. It installs skills into agents and writes config such as ~/.obsidian-wiki/config. It is not the same as asking an agent to run wiki status.
Things To Be Aware Of
Agent Workflows Use Model Tokens
When you ask Codex or another AI agent to run:
wiki statusthe agent reads vault files and reasons over them. That file content becomes model context, so it uses tokens.
For a new or small vault, normal wiki status is usually cheap: often a few thousand tokens. As the vault grows, a normal status run can become more like 10k-30k tokens or more, depending on how many files, sources, and manifest entries it needs to inspect.
Status Is Cheaper Than Insights
Normal status is designed to be relatively lightweight. It focuses on config, .manifest.json, index.md, log.md, hot.md, frontmatter, source deltas, and file-size estimates.
The heavier prompt is:
wiki insightsInsights mode analyzes the wiki graph: hubs, bridges, orphan pages, tag cohesion, surprising links, and tier suggestions. It can read more vault structure and may write _insights.md, so expect it to cost more than normal status.
Terminal Commands Do Not Use LLM Tokens
Terminal commands such as:
obsidian-wiki infodo not use model tokens. They are local CLI operations.
The token distinction is:
| Action | Uses LLM tokens? |
|---|---|
obsidian-wiki info in terminal | No |
obsidian-wiki list in terminal | No |
obsidian-wiki setup in terminal | No |
wiki status typed to Codex | Yes |
wiki insights typed to Codex | Yes, usually more |
ingest this file typed to Codex | Yes |
what do I know about X? typed to Codex | Yes |
Python Module Note
Avoid relying on:
python3 -m obsidian_wikiYour shell may be using a virtualenv Python, such as a Hermes agent environment, where the obsidian_wiki module is not installed. Prefer the obsidian-wiki command instead.
Configuration
Skills resolve the vault path in this order:
- Walk up from the current directory looking for a
.envfile that containsOBSIDIAN_VAULT_PATH. - Fall back to
~/.obsidian-wiki/config. - If neither exists, run setup.
The most important variable is:
OBSIDIAN_VAULT_PATH=/path/to/your/vaultFor a team checkout, do not commit .env. Copy the template and set only the local vault path:
cp .env.example .envOBSIDIAN_VAULT_PATH=/absolute/path/to/llm-shared-vault
OBSIDIAN_WIKI_REPO=${OBSIDIAN_VAULT_PATH}/obsidian-wiki
OBSIDIAN_SOURCES_DIR=${OBSIDIAN_VAULT_PATH}/_rawOBSIDIAN_WIKI_REPO and OBSIDIAN_SOURCES_DIR can be derived from OBSIDIAN_VAULT_PATH, so each teammate only needs to customize one path. Prefer _raw/ as the source inbox; pointing OBSIDIAN_SOURCES_DIR at the vault root can make ingest/status scans pick up framework files and wiki metadata.
After changing vaults, run:
obsidian-wiki infoConfirm the reported vault: path is the vault you expect.
Vault Structure
The root contains special files:
| File | Purpose |
|---|---|
index.md | Master catalog of wiki pages |
log.md | Chronological activity log |
hot.md | Short semantic cache of recent context |
.manifest.json | Source tracking and delta bookkeeping |
AGENTS.md | Vault-specific instructions for agents |
Knowledge pages live in category folders:
| Folder | Purpose |
|---|---|
concepts/ | Ideas, patterns, mental models |
entities/ | Tools, people, services, organizations |
skills/ | Procedures and how-to knowledge |
references/ | Specific source summaries and reference notes |
synthesis/ | Cross-source analysis |
journal/ | Time-bound notes and session entries |
projects/ | Project-scoped knowledge |
How To Think About The Wiki
The guiding rule is: compile, do not retrieve.
That means a source should not merely become a summary page. The useful claims should be merged into the right durable pages, linked to related pages, and recorded with provenance. Over time, the vault should become more coherent rather than just larger.
Use wikilinks to connect related pages. Mark synthesized claims with ^[inferred] and unclear or conflicting claims with ^[ambiguous].
Suggested First Workflow
- Ask an agent:
wiki status. - Confirm
obsidian-wiki inforeports the correct vault path. - Ingest one small representative source.
- Open the resulting pages in Obsidian and check naming, tags, and style.
- Continue with larger ingests once the shape feels right.
Practical Implementation Context
For LLM Wiki Usage Guide, practical implementation means maintaining an operator runbook that answers a concrete reader question: which action belongs in chat versus terminal. The page should make the difference between terminal inspection, Obsidian review, and agent-executed wiki skills explicit so readers do not turn every wiki operation into a guessed shell command.
- Check vault path, agent skill request, and terminal inspection before presenting the workflow as ready.
- Use configured .env, wiki status answer, and Obsidian review as evidence that the setup guidance still matches the real environment.
- Show the expected path: open vault, then ask agent skill, then verify generated page.
- Treat the guide as validated when status, query, and lint all work on the same vault.
Implementation note: treat this operator runbook as valid only when the path from open vault to verify generated page still proves that status, query, and lint all work on the same vault.
Reference Implementation Pattern
For LLM Wiki Usage Guide, the reference implementation is an operator runbook. It should help a reader decide which action belongs in chat versus terminal, then validate the workflow by checking that status, query, and lint all work on the same vault. That makes the page useful as an operating guide rather than a generic list of commands.
guide_workflow:
page: "LLM Wiki Usage Guide"
artifact: "operator runbook"
decision: "which action belongs in chat versus terminal"
checkpoints:
- "vault path"
- "agent skill request"
- "terminal inspection"
evidence:
- "configured .env"
- "wiki status answer"
- "Obsidian review"
open vault -> ask agent skill -> verify generated page
In practice, a teammate should be able to open the vault, follow this page's examples, and know whether the next action belongs in Obsidian, in a terminal inspection command, or in an agent skill request.
Key Takeaways
- Treat the source page as distilled knowledge, then add enough implementation context for a standalone reader.
- Make trade-offs visible: reliability, observability, governance, cost, and maintenance burden all matter.
- Use structured headings, tables, examples, and explicit warnings to help readers scan and apply the material.
Operational Depth
Setup Ownership
LLM Wiki Usage Guide should be owned like operational documentation. If commands, install paths, or skill names change, the guide should be refreshed before readers follow stale instructions.
First Workflow
The safest validation is a small status or query workflow in an agent chat, followed by an Obsidian review of the resulting Markdown pages.
Review Cadence
Review this page whenever source material changes, linked pages are promoted, or a reader would make a different decision because of new information. The review should check both content accuracy and whether the page still connects cleanly to the rest of the LLM Wiki graph.
Reader Outcome
A reader should understand the boundary between terminal setup, Obsidian review, and agent-executed wiki skills.
Frequently Asked Questions
What should a reader do first after opening LLM Wiki Usage Guide?
They should confirm where the vault is configured, understand which actions belong in the agent chat, and use terminal commands only for setup or inspection.
Can wiki status be typed in a normal terminal?
No. wiki status is an agent workflow request. Terminal commands such as obsidian-wiki info inspect the installed framework, while the agent runs wiki skills.
Why does this guide emphasize Obsidian?
Obsidian gives the LLM Wiki a local Markdown foundation that humans can browse and agents can update without hiding knowledge inside a proprietary database.
Conclusion
LLM Wiki Usage Guide should close with one practical takeaway: an LLM Wiki environment works best when responsibilities are clear. Obsidian is the reading and review surface, the local configuration points agents to the vault, and day-to-day operations such as status, ingest, query, capture, and lint are requested from the agent rather than guessed from terminal commands.
After reading this page, a reader should be ready to verify the setup, run a small status check, and understand why the wiki is maintained as compiled Markdown knowledge instead of loose chat summaries. That workflow is the foundation for the rest of the series.
