LLM Wiki Usage Guide

Practical guide for using this vault with LLM Wiki skills, Codex chat, Obsidian, and the obsidian-wiki setup CLI.

Full series Previous: Wiki Index Next: Agent Development Frameworks

Introduction

LLM Wiki Usage Guide is part of a practical LLM wiki knowledge base, so this article is written for readers who need an implementation-oriented explanation rather than a shallow definition. The goal is to turn the original note into a self-contained technical post that explains the context, the moving parts, and the operational trade-offs that matter when the idea is applied in a real system.

The source material emphasizes vault, wiki, obsidian-wiki, text, status, agent. Those terms are not isolated labels; they describe a working surface where teams choose tools, define boundaries, and decide how much automation, governance, observability, and human review they need. A useful blog treatment should therefore show how the topic fits into a broader engineering workflow.

Practical Implementation Context

When adopting this pattern, start by identifying the decision the page is meant to support. Some pages help compare tools, some describe an architectural layer, and others capture operating practices. Readers should map the concept to a concrete workflow before choosing technology: who owns the system, what data flows through it, what failure modes are acceptable, and how the result will be evaluated.

• Define the system boundary before comparing vendors or frameworks.
• Record assumptions explicitly so future maintainers know what changed.
• Prefer observable workflows where inputs, outputs, and quality signals can be inspected.
• Keep human review available for high-impact or ambiguous automation paths.

Architectural note: the safest implementation is usually the one where each layer can be tested independently and replaced without rewriting the rest of the stack.

Reference Implementation Pattern

The following configuration sketch shows how to translate the knowledge-page mindset into an operational checklist. It is intentionally generic so it can be adapted to agent frameworks, retrieval systems, observability pipelines, security controls, or workflow automation layers.

blog_pipeline:
  source: llm-wiki-markdown
  output: semantic-html
  quality_gates:
    - preserve_source_context
    - add_reader_navigation
    - include_accessible_visual
    - document_operational_risks
  review:
    owner: technical_editor
    checks:
      - factual_accuracy
      - link_integrity
      - implementation_value

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.

Frequently Asked Questions

How should a team use LLM Wiki Usage Guide in practice?

Start with the workflow or decision the topic supports, then choose tools and controls that make that workflow measurable and maintainable.

What is the most common mistake?

The common mistake is treating the topic as a standalone tool choice instead of part of a larger architecture with data, ownership, review, and reliability concerns.

How can the approach be validated?

Validate it with a small scenario, inspect the outputs, record failure cases, and add observability before scaling the pattern across teams or projects.

Conclusion

LLM Wiki Usage Guide becomes useful when it is connected to concrete engineering decisions. A strong implementation keeps the concept explainable, links it to adjacent system layers, and preserves enough provenance that future readers can understand why the recommendation exists.

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 status

ingest this file

what do I know about OCI networking?

capture this finding

lint my wiki

The 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 status

Use 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/article

ingest the files in _raw/

process this PDF into the wiki

Ingest 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 decisions

The 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 wiki

find broken links

dedup my wiki

connect related pages

These prompts help maintain frontmatter, links, tags, duplicate pages, and graph quality.

Terminal CLI

The installed CLI is:

obsidian-wiki

If your shell cannot find it, use the full path:

/Users/simhead/.local/bin/obsidian-wiki

Common terminal commands:

obsidian-wiki info

obsidian-wiki list

obsidian-wiki setup

obsidian-wiki setup --vault /path/to/your/vault

Important: 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 status

the 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 insights

Insights 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 info

do 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_wiki

Your 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:

1. Walk up from the current directory looking for a .env file that contains OBSIDIAN_VAULT_PATH.
2. Fall back to ~/.obsidian-wiki/config.
3. If neither exists, run setup.

The most important variable is:

OBSIDIAN_VAULT_PATH=/path/to/your/vault

For a team checkout, do not commit .env. Copy the template and set only the local vault path:

cp .env.example .env

OBSIDIAN_VAULT_PATH=/absolute/path/to/llm-shared-vault
OBSIDIAN_WIKI_REPO=${OBSIDIAN_VAULT_PATH}/obsidian-wiki
OBSIDIAN_SOURCES_DIR=${OBSIDIAN_VAULT_PATH}/_raw

OBSIDIAN_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 info

Confirm 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

1. Ask an agent: wiki status.
2. Confirm obsidian-wiki info reports the correct vault path.
3. Ingest one small representative source.
4. Open the resulting pages in Obsidian and check naming, tags, and style.
5. Continue with larger ingests once the shape feels right.

Full series Previous: Wiki Index Next: Agent Development Frameworks