LLM Wiki Functions Reference

Reference for the agent skills listed by obsidian-wiki list, with examples for invoking each workflow.

Introduction

LLM Wiki Functions Reference is the practical starting point for readers who want to operate an LLM Wiki environment instead of only reading about the idea. Reference for the agent skills listed by obsidian-wiki list, with examples for invoking each workflow. 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.

obsidian-wiki list prints the agent skills installed by the framework. These are not terminal subcommands. They are workflows an AI agent runs after reading the corresponding SKILL.md instructions.

In Codex, prefer the $skill-name form when you know the exact skill:

$wiki-status

Many agents also support slash-style invocation:

/wiki-status

Natural language works too:

wiki status

Quick Command Map

Function	Use it for	Example
`wiki-status`	Show vault health, ingested sources, pending work, and token footprint.	`$wiki-status`
`wiki-ingest`	Distill documents, URLs, exports, transcripts, and `_raw/` captures into wiki pages.	`$wiki-ingest promote my raw pages`
`wiki-query`	Ask questions against the compiled wiki.	`$wiki-query what do I know about OCI DevOps?`
`wiki-capture`	Save a finding or conversation into the wiki or `_raw/`.	`$wiki-capture --quick capture this gotcha: ...`
`wiki-update`	Sync the current project's durable knowledge into the vault.	`$wiki-update`
`wiki-lint`	Find broken links, missing frontmatter, or structural issues.	`$wiki-lint`
`cross-linker`	Add missing wikilinks between related pages.	`$cross-linker`
`tag-taxonomy`	Normalize tags and enforce the controlled taxonomy.	`$tag-taxonomy`
`wiki-dedup`	Find and consolidate duplicate or overlapping pages.	`$wiki-dedup`
`wiki-synthesize`	Discover synthesis opportunities across existing pages.	`$wiki-synthesize`
`wiki-dashboard`	Create Obsidian Bases dashboard views.	`$wiki-dashboard show all internal pages as a table`
`wiki-digest`	Summarize recent learning over a period.	`$wiki-digest weekly`
`wiki-research`	Research a topic and file findings into the wiki.	`$wiki-research OCI DevOps deployment patterns`
`wiki-export`	Export the vault or graph to portable formats.	`$wiki-export OKF bundle`
`wiki-import`	Import a previous vault/export/OKF bundle.	`$wiki-import import OKF bundle from ./export`
`wiki-rebuild`	Archive, restore, or rebuild the vault.	`$wiki-rebuild archive and rebuild`
`wiki-setup`	Initialize or repair wiki structure and config.	`$wiki-setup`
`wiki-switch`	List or switch between vault configs.	`$wiki-switch list`
`wiki-stage-commit`	Review and promote staged pages/patches.	`$wiki-stage-commit`
`wiki-context-pack`	Build a token-bounded context pack from the vault.	`$wiki-context-pack OCI networking under 8000 tokens`

Core Wiki Workflows

`llm-wiki`

Explains the LLM Wiki architecture: raw sources, compiled wiki pages, schema/skills, page templates, manifests, links, and operating principles.

Examples:

$llm-wiki explain the three-layer architecture

$llm-wiki how should project-specific pages be organized?

`wiki-setup`

Initializes the vault structure and config. Use when starting a new vault, repairing missing required files, or checking setup assumptions.

Examples:

$wiki-setup

$wiki-setup initialize this vault for agent-maintained Obsidian notes

`wiki-status`

Audits the current vault: manifest, pages, raw/staging queues, source deltas, token footprint, and recommended next actions.

Examples:

$wiki-status

$wiki-status show what changed since last ingest

Insights mode:

$wiki-status wiki insights

`wiki-ingest`

Distills source material into durable, linked wiki pages. Sources can include Markdown, text, PDFs, images, JSON/CSV exports, chat logs, meeting transcripts, web pages, or files in _raw/.

Examples:

$wiki-ingest promote my raw pages

$wiki-ingest ingest this URL: https://example.com/article

$wiki-ingest process this PDF into the wiki

`wiki-query`

Answers questions from the compiled wiki. It should scan index/frontmatter first, then open full pages when needed.

Examples:

$wiki-query what do I know about Jira dashboard refactoring?

$wiki-query public only: summarize OCI DevOps deployment lessons

`wiki-update`

Syncs knowledge from the current software/project directory into the wiki. It is best for architecture decisions, patterns, trade-offs, and durable project context.

Examples:

$wiki-update

$wiki-update sync this project's current architecture decisions

`wiki-capture`

Captures small findings, gotchas, or the current conversation. Quick captures usually land in _raw/ for later promotion.

Examples:

$wiki-capture capture this finding: OCI DevOps build runners need explicit network access to private repos.

$wiki-capture --quick save this gotcha for later

`wiki-context-pack`

Produces a token-bounded context pack from wiki pages for use in another agent session, prompt, review, or handoff.

Examples:

$wiki-context-pack FG Ally refactoring under 10000 tokens

$wiki-context-pack make a context pack for OCI DevOps and Jira dashboards

Maintenance And Quality

`wiki-lint`

Audits the vault for structural problems such as missing frontmatter, broken links, orphan pages, stale content, contradictions, and index issues.

Examples:

$wiki-lint

$wiki-lint find broken links and missing frontmatter

`cross-linker`

Scans pages for missing connections and inserts or recommends wikilinks so the vault becomes a real graph.

Examples:

$cross-linker

$cross-linker connect project pages to global concepts

`tag-taxonomy`

Audits and normalizes tags against the vault taxonomy. Use after several ingests or when tags start drifting.

Examples:

$tag-taxonomy

$tag-taxonomy normalize tags and report unknown values

`wiki-dedup`

Finds duplicate or near-duplicate pages and plans consolidation. Useful after imports, rebuilds, or overlapping ingests.

Examples:

$wiki-dedup

$wiki-dedup find duplicate pages about Jira dashboards

`wiki-synthesize`

Finds cross-page synthesis opportunities: recurring concepts, unresolved tensions, themes, and missing bridge pages.

Examples:

$wiki-synthesize

$wiki-synthesize find connections across OCI, Jira, and refactoring notes

`impl-validator`

Checks whether an implementation matches its stated goal. Useful for validating generated code, docs, or project changes against a plan.

Examples:

$impl-validator validate the implementation against the plan

$impl-validator check whether this doc actually covers every listed skill

`daily-update`

Runs a daily maintenance-style pass: freshness checks, index refresh, hot cache updates, and related housekeeping.

Examples:

$daily-update

$daily-update morning sync

`graph-colorize`

Updates Obsidian graph color rules by tag, category, visibility, or other conventions.

Examples:

$graph-colorize color by category

$graph-colorize color internal pages differently from public pages

Dashboards, Digests, Research, And Export

`wiki-dashboard`

Creates Obsidian Bases dashboard definitions for dynamic tables and filtered views.

Examples:

$wiki-dashboard create a dashboard for all project pages

$wiki-dashboard show all visibility/internal pages as a table

`wiki-digest`

Summarizes recent learning or vault changes over a time window.

Examples:

$wiki-digest weekly

$wiki-digest what did I learn this month?

`wiki-research`

Runs a research workflow on a topic and distills useful findings into the wiki. Use when the task is research-first rather than ingesting a known local source.

Examples:

$wiki-research OCI DevOps deployment best practices

$wiki-research compare Jira dashboard patterns for resource planning

`wiki-export`

Exports wiki knowledge to portable formats such as OKF, graph JSON, GraphML, Neo4j-oriented data, or other supported structures.

Examples:

$wiki-export OKF bundle

$wiki-export graphml

`wiki-import`

Imports a wiki export, OKF bundle, or compatible knowledge graph into the current vault.

Examples:

$wiki-import import OKF bundle from ./my-export

$wiki-import load graph.json

`wiki-rebuild`

Archives, restores, or rebuilds wiki contents. This is a high-impact maintenance operation; use it intentionally.

Examples:

$wiki-rebuild archive current wiki before rebuilding

$wiki-rebuild restore from latest archive

`wiki-stage-commit`

Reviews staged pages and patches under _staging/ and promotes accepted changes into their final locations.

Examples:

$wiki-stage-commit

$wiki-stage-commit review staged pages and promote safe ones

`wiki-switch`

Lists, creates, or switches between configured wiki vault profiles.

Examples:

$wiki-switch list

$wiki-switch switch to work wiki

History Ingest And Cross-Agent Memory

`wiki-history-ingest`

Routes history ingestion to the right source-specific skill. Use when you know the agent family but want the unified entry point.

Examples:

$wiki-history-ingest codex

$wiki-history-ingest claude

`claude-history-ingest`

Mines Claude conversations and memory files into wiki pages.

Examples:

$claude-history-ingest

$claude-history-ingest import my Claude history for this project

`codex-history-ingest`

Mines Codex sessions, rollout logs, and history files into wiki pages.

Examples:

$codex-history-ingest

$codex-history-ingest mine my Codex sessions about Jira dashboards

`copilot-history-ingest`

Mines GitHub Copilot CLI session history into the wiki.

Examples:

$copilot-history-ingest

$copilot-history-ingest import my Copilot CLI history

`hermes-history-ingest`

Mines Hermes memories and sessions into the wiki.

Examples:

$hermes-history-ingest

$hermes-history-ingest ingest ~/.hermes

`openclaw-history-ingest`

Mines OpenClaw memory and session history into the wiki.

Examples:

$openclaw-history-ingest

$openclaw-history-ingest mine my OpenClaw sessions

`pi-history-ingest`

Mines Pi agent session history into the wiki.

Examples:

$pi-history-ingest

$pi-history-ingest import my Pi sessions

`wiki-agent`

Performs topic-first search and ingest from a specific agent's raw history.

Examples:

$wiki-agent search Codex memory for Terraform provider aliases

Shortcut examples:

/wiki-codex Terraform provider aliases

/wiki-claude OCI DevOps build runners

`memory-bridge`

Compares or browses knowledge by which AI tool produced it, useful for cross-tool memory and deltas.

Examples:

$memory-bridge compare Codex and Claude knowledge about OCI DevOps

$memory-bridge browse codex memory for Jira refactoring

Skill Creation And Packaging

`skill-creator`

Creates or improves agent skills. Use for writing new SKILL.md workflows, not for ordinary wiki pages.

Examples:

$skill-creator create a skill for Confluence dashboard ingest

$skill-creator improve the wiki-status skill with a terminal summary mode

`vault-skill-factory`

Turns mature wiki knowledge into a portable domain-expert skill.

Examples:

$vault-skill-factory package my OCI DevOps notes as a skill

$vault-skill-factory make a skill from the Jira dashboard refactoring pages

Recommended Usage Pattern

For day-to-day work:

$wiki-status

$wiki-ingest promote my raw pages

$wiki-query what do I know about the thing I just ingested?

$cross-linker

$wiki-lint

For periodic maintenance:

$wiki-synthesize

$wiki-digest weekly

$wiki-export OKF bundle

Terminal Note

The terminal command:

obsidian-wiki list

lists available skills. It does not execute those workflows. To run a workflow, ask an agent to invoke the skill, for example:

$wiki-status

Practical Implementation Context

For LLM Wiki Functions Reference, practical implementation means maintaining a skill command catalog that answers a concrete reader question: which LLM Wiki skill to request for a task. 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 intent phrase, skill name, and expected output before presenting the workflow as ready.
Use available skill list, safe command boundary, and example prompt as evidence that the setup guidance still matches the real environment.
Show the expected path: match intent, then choose wiki skill, then record result.
Treat the guide as validated when a reader can select status, query, ingest, lint, or export without guessing.

Implementation note: treat this skill command catalog as valid only when the path from match intent to record result still proves that a reader can select status, query, ingest, lint, or export without guessing.

Reference Implementation Pattern

For LLM Wiki Functions Reference, the reference implementation is a skill command catalog. It should help a reader decide which LLM Wiki skill to request for a task, then validate the workflow by checking that a reader can select status, query, ingest, lint, or export without guessing. That makes the page useful as an operating guide rather than a generic list of commands.

guide_workflow:
  page: "LLM Wiki Functions Reference"
  artifact: "skill command catalog"
  decision: "which LLM Wiki skill to request for a task"
  checkpoints:
    - "intent phrase"
    - "skill name"
    - "expected output"
  evidence:
    - "available skill list"
    - "safe command boundary"
    - "example prompt"

match intent -> choose wiki skill -> record result

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

Runbook Ownership

LLM Wiki Functions Reference guide page should be maintained as a skill command catalog. Its operational boundary is the reader decision: which LLM Wiki skill to request for a task. If setup paths, skill names, or command examples change, this page should be refreshed before readers follow stale instructions.

Control Points

The page should explicitly check intent phrase, skill name, and expected output. Evidence should come from available skill list, safe command boundary, and example prompt, not from assumptions about how the reader's machine is configured.

Validation Run

A practical validation run is: match intent, then choose wiki skill, then record result. The guide is healthy when a reader can select status, query, ingest, lint, or export without guessing.

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 content accuracy, link integrity, and whether the operational proof still matches the current 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 Functions Reference?

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 Functions Reference 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.

From Classical Logic to Agentic AI