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 knowle

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: 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: For an existing Obsidian vault: 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: 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.