/wiki
Initialize, adopt, and route work for a separate Obsidian knowledge vault through the portable claude-obsidian core. Use for vault setup, scaffolding, workspace selection, cross-project configuration, or choosing the correct wiki sub-skill. Triggers: /wiki, set up wiki, scaffold
$ npx -y skills add AgriciDaniel/claude-obsidian --skill wiki --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/wiki
Context preview
The summary Claude sees to decide when to auto-load this skill.
Initialize, adopt, and route work for a separate Obsidian knowledge vault through the portable claude-obsidian core. Use for vault setup, scaffolding, workspace selection, cross-project configuration, or choosing the correct wiki sub-skill. Triggers: /wiki, set up wiki, scaffold
SKILL.md
wiki.SKILL.mdname: wiki
description: "Initialize, adopt, and route work for a separate Obsidian knowledge vault through the portable claude-obsidian core. Use for vault setup, scaffolding, workspace selection, cross-project configuration, or choosing the correct wiki sub-skill. Triggers: /wiki, set up wiki, scaffold vault, create knowledge base, adopt this vault, Obsidian vault, second brain setup, persistent wiki."
Wiki orchestration
Treat the installed product as code and the selected user vault as data. Never use the plugin/product root as a vault, even when the current directory happens to be the product checkout.
Resolve the portable core from this skill's installation and invoke it by absolute path:
CORE=/absolute/product/root/scripts/claude-obsidian.py
python3 "$CORE" --help
Resolve a vault in this order: explicit `--vault`, `CLAUDE_OBSIDIAN_VAULT`, the nearest `.claude-obsidian.json`, then an unambiguous initialized vault at or above the current directory. Fail closed when selection is missing or ambiguous.
Baseline setup requires no network egress. Do not fetch templates, plugins, or remote content unless the user separately approves the destinations and budget.
Set up a vault
Use the deterministic setup commands. Both are dry-run by default.
For a new, separate vault:
python3 "$CORE" init /absolute/path/to/vault \
--generated-at <ISO-UTC> --operation-id init-reviewed
python3 "$CORE" init /absolute/path/to/vault \
--generated-at <ISO-UTC> --operation-id init-reviewed \
--approved-plan-sha256 <reviewed-sha256> --apply
For an existing Obsidian vault:
python3 "$CORE" adopt /absolute/path/to/vault \
--generated-at <ISO-UTC> --operation-id adopt-reviewed
python3 "$CORE" adopt /absolute/path/to/vault \
--generated-at <ISO-UTC> --operation-id adopt-reviewed \
--approved-plan-sha256 <reviewed-sha256> --apply
Before `--apply`, show the selected path and changed-path preview, then pass the emitted `approved_plan_sha256` unchanged. Do not use `--force` unless the user has reviewed the conflicts and explicitly approved replacement. Setup is non-destructive by default and creates no upstream Git remote.
If the user asks for a domain-specific scaffold, establish the baseline first, then read [modes.md](references/modes.md). Draft the additional pages and configuration as one operation-level transaction. Never mutate vault files with host Write/Edit tools or an Obsidian transport.
Route operations
Route the user's intent without silently broadening it:
| Intent | Skill | |---|---| | Ingest supplied sources | `wiki-ingest` | | Answer from existing vault knowledge | `wiki-query` | | Save a specific conversation result | `save` | | Research the public web under a budget | `autoresearch` | | Check vault health | `wiki-lint` | | Roll up log entries | `wiki-fold` | | Work with a canvas | `canvas` |
Query is read-only. Persistence from a query must be an explicit, separately scoped Save operation. Never capture a transcript or update the hot cache merely because a session ended.
Mutation contract
Read [operation-transactions.md](references/operation-transactions.md) before any custom scaffold or mutation. One logical operation must produce one inspected and recoverable `claude-obsidian.transaction.v1` bundle. Parallel agents may return drafts and evidence only; the orchestrator merges them and applies once. Every canonical page create or removal includes an active index or MOC update in that bundle; update the overview only when the stable high-level picture changed. Raw source payloads are create-only. There are no automatic commits.
Use [provenance.md](references/provenance.md) when initializing or changing source and claim ledgers. Unsupported evidence stays unsupported; never invent a source, quote, date, locator, or confidence.
After a successful apply, report the operation ID and exact changed paths. If the user explicitly wants a Git checkpoint, run it separately:
python3 "$CORE" checkpoint OPERATION_ID --vault /absolute/path/to/vault
On a conflict, re-read and rebuild. On interruption, use `transaction recover`. Reuse an operation ID only with the identical bundle.
Installation context
Read [install-modes.md](references/install-modes.md) when installation or host behavior matters. Hooks are optional adapters; portable behavior lives in the core and skills.
Conditional references
Read only the reference needed for the current request:
- [frontmatter.md](references/frontmatter.md) when defining or adopting a
property schema;
- [css-snippets.md](references/css-snippets.md) for requested Obsidian visual
customization;
- [git-setup.md](references/git-setup.md) for explicit local Git or checkpoint
setup;
- [plugins.md](references/plugins.md) when evaluating optional Obsidian
integrations;
- [mcp-setup.md](references/mcp-setup.md) when the user asks to evaluate an
external read transport;
- [rest-api.md](references/rest-api.md) only when the user explicitly has or
requests the Local REST API adapter.
Think, verify, grow
Before applying, pause once: observe existing state, verify the vault selection and evidence, then choose the smallest reversible operation that satisfies the request. Afterward, report uncertainty and the next useful improvement without performing it automatically.
Read more
name: wiki description: "Initialize, adopt, and route work for a separate Obsidian knowledge vault through the portable claude-obsidian core. Use for vault setup, scaffolding, workspace selection, cross-project configuration, or choosing the correct wiki sub-skill. Triggers: /wiki, set up wiki, scaffold vault, create knowledge base, adopt this vault, Obsidian vault, second brain setup, persistent wiki."
Wiki orchestration
Treat the installed product as code and the selected user vault as data. Never use the plugin/product root as a vault, even when the current directory happens to be the product checkout.
Resolve the portable core from this skill's installation and invoke it by absolute path:
CORE=/absolute/product/root/scripts/claude-obsidian.py python3 "$CORE" --help
Resolve a vault in this order: explicit `--vault`, `CLAUDE_OBSIDIAN_VAULT`, the nearest `.claude-obsidian.json`, then an unambiguous initialized vault at or above the current directory. Fail closed when selection is missing or ambiguous.
Baseline setup requires no network egress. Do not fetch templates, plugins, or remote content unless the user separately approves the destinations and budget.
Set up a vault
Use the deterministic setup commands. Both are dry-run by default.
For a new, separate vault:
python3 "$CORE" init /absolute/path/to/vault \ --generated-at <ISO-UTC> --operation-id init-reviewed python3 "$CORE" init /absolute/path/to/vault \ --generated-at <ISO-UTC> --operation-id init-reviewed \ --approved-plan-sha256 <reviewed-sha256> --apply
For an existing Obsidian vault:
python3 "$CORE" adopt /absolute/path/to/vault \ --generated-at <ISO-UTC> --operation-id adopt-reviewed python3 "$CORE" adopt /absolute/path/to/vault \ --generated-at <ISO-UTC> --operation-id adopt-reviewed \ --approved-plan-sha256 <reviewed-sha256> --apply
Before `--apply`, show the selected path and changed-path preview, then pass the emitted `approved_plan_sha256` unchanged. Do not use `--force` unless the user has reviewed the conflicts and explicitly approved replacement. Setup is non-destructive by default and creates no upstream Git remote.
If the user asks for a domain-specific scaffold, establish the baseline first, then read [modes.md](references/modes.md). Draft the additional pages and configuration as one operation-level transaction. Never mutate vault files with host Write/Edit tools or an Obsidian transport.
Route operations
Route the user's intent without silently broadening it:
| Intent | Skill | |---|---| | Ingest supplied sources | `wiki-ingest` | | Answer from existing vault knowledge | `wiki-query` | | Save a specific conversation result | `save` | | Research the public web under a budget | `autoresearch` | | Check vault health | `wiki-lint` | | Roll up log entries | `wiki-fold` | | Work with a canvas | `canvas` |
Query is read-only. Persistence from a query must be an explicit, separately scoped Save operation. Never capture a transcript or update the hot cache merely because a session ended.
Mutation contract
Read [operation-transactions.md](references/operation-transactions.md) before any custom scaffold or mutation. One logical operation must produce one inspected and recoverable `claude-obsidian.transaction.v1` bundle. Parallel agents may return drafts and evidence only; the orchestrator merges them and applies once. Every canonical page create or removal includes an active index or MOC update in that bundle; update the overview only when the stable high-level picture changed. Raw source payloads are create-only. There are no automatic commits.
Use [provenance.md](references/provenance.md) when initializing or changing source and claim ledgers. Unsupported evidence stays unsupported; never invent a source, quote, date, locator, or confidence.
After a successful apply, report the operation ID and exact changed paths. If the user explicitly wants a Git checkpoint, run it separately:
python3 "$CORE" checkpoint OPERATION_ID --vault /absolute/path/to/vault
On a conflict, re-read and rebuild. On interruption, use `transaction recover`. Reuse an operation ID only with the identical bundle.
Installation context
Read [install-modes.md](references/install-modes.md) when installation or host behavior matters. Hooks are optional adapters; portable behavior lives in the core and skills.
Conditional references
Read only the reference needed for the current request:
- [frontmatter.md](references/frontmatter.md) when defining or adopting a
property schema;
- [css-snippets.md](references/css-snippets.md) for requested Obsidian visual
customization;
- [git-setup.md](references/git-setup.md) for explicit local Git or checkpoint
setup;
- [plugins.md](references/plugins.md) when evaluating optional Obsidian
integrations;
- [mcp-setup.md](references/mcp-setup.md) when the user asks to evaluate an
external read transport;
- [rest-api.md](references/rest-api.md) only when the user explicitly has or
requests the Local REST API adapter.
Think, verify, grow
Before applying, pause once: observe existing state, verify the vault selection and evidence, then choose the smallest reversible operation that satisfies the request. Afterward, report uncertainty and the next useful improvement without performing it automatically.
Self-organizing AI second brain for Obsidian + Claude Code. Drop any source and Claude reads, links, and files it into one connected knowledge graph of plain Markdown you own. AI note-taking, personal knowledge management (PKM), and an open-source Notion alternative. Based on Karpathy's LLM Wiki pattern.
Other skills on claude-obsidian.
- /autoresearch
Run a bounded, source-grounded research loop, draft a cited dossier, and optionally propose a separately reviewed canonical vault merge. Use when the user wants autonomous or deep research that may access the public web. Triggers: /autoresearch, autoresearch, research this
Open skill - /canvas
Create, inspect, and update Obsidian JSON Canvas boards with text, file, link, group, and edge nodes. Use for canvas status, canvas lists, visual maps, zones, spatial layouts, adding vault notes or media to a .canvas file, and requests such as create canvas, add to canvas, or
Open skill - /defuddle
Plan and, with explicit network consent, use an optional external Defuddle cleaner to extract article-like HTTPS pages as Markdown. Use for defuddle, clean this URL, strip page clutter, readable Markdown from a web page, or preparing a web source for later wiki ingestion.
Open skill - /obsidian-bases
Explain, draft, and validate Obsidian Bases .base files with filters, formulas, properties, summaries, and table, card, or list views. Use for Obsidian Bases, database-like vault views, dynamic tables, reading lists, task trackers, filters, formulas, summaries, and .base file
Open skill - /obsidian-markdown
Explain, draft, or validate Obsidian Flavored Markdown syntax: properties, wikilinks, embeds, callouts, tags, comments, highlights, block references, math, and Mermaid. Use when the user explicitly requests Obsidian note formatting or syntax help, not for general Markdown or
Open skill - /save
Save a user-selected answer, decision, insight, or session summary into an Obsidian vault as one reviewed transaction. Use only when the user explicitly asks to preserve specific conversation content, not when they supply a file or URL to ingest. Triggers: /save, save this, save
Open skill

