Wiki Switch — Manage Multiple Vault Profiles

Global config dir. Every path below is relative to the global config dir, resolved per the

Config Resolution Protocol in llm-wiki/SKILL.md: $XDG_CONFIG_HOME/obsidian-wiki (default

~/.config/obsidian-wiki), or the legacy ~/.obsidian-wiki if that already exists on disk. Resolve

it once per invocation with:

CONFIG_DIR="$( [[ -d "$HOME/.obsidian-wiki" && ! -e "${XDG_CONFIG_HOME:-$HOME/.config}/obsidian-wiki" ]] && echo "$HOME/.obsidian-wiki" || echo "${XDG_CONFIG_HOME:-$HOME/.config}/obsidian-wiki" )"

Each vault is a complete config file at $CONFIG_DIR/config.<name>. The active vault is

whichever file $CONFIG_DIR/config symlinks to. Switching vaults means re-pointing that symlink.

Switch vs. inline targeting. /wiki-switch <name> changes your persistent default (re-points

the symlink, affecting all future requests). To touch a different vault for just one request without

changing your default, use the inline **@name** override in any request (e.g. @work save this,

wiki-query @personal about X). The @name override is handled by the Config Resolution Protocol

in llm-wiki/SKILL.md, not by this skill — it resolves $CONFIG_DIR/config.<name> for that one

invocation and never re-points the symlink.

Dispatch

Parse the invocation and route to the right section:

Switch (default action)

Activate a named vault profile.

• Verify $CONFIG_DIR/config.<name> exists. If not, tell the user the vault doesn't exist and list what's available (run List).

• Run:

ln -sf "$CONFIG_DIR/config.<name>" "$CONFIG_DIR/config"

• Read OBSIDIAN_VAULT_PATH from the newly active config.

• Confirm to the user:

Switched to vault: <name>

Vault path: <value of OBSIDIAN_VAULT_PATH from the config>

List

Show all registered vault profiles and which is active.

• Find all files matching $CONFIG_DIR/config.* (exclude config itself — that's the symlink).

• Resolve the current symlink target: readlink "$CONFIG_DIR/config"

• For each config file, read the first non-empty comment line (lines starting with #) as a human description of the vault. Fall back to the file's suffix as the label if no comment exists.

• Display:

Vaults:

  personal   My personal research wiki    ← active

  work       Work projects wiki

Mark the active one with ← active. If the symlink is broken or config doesn't exist, show (none active).

Show

Print the full config for a vault.

• If a name is given, read $CONFIG_DIR/config.<name>.

• If no name given, read $CONFIG_DIR/config (the active vault).

• If the file doesn't exist, tell the user and list what's available.

• Print the file contents verbatim (redact any lines containing API_KEY or SECRET — show *** instead of the value).

New

Scaffold a new vault config from the current active config as a template.

• Check $CONFIG_DIR/config.<name> doesn't already exist. Abort if it does.

• Copy the active config:

cp "$CONFIG_DIR/config" "$CONFIG_DIR/config.<name>"

• Read the copied config. Config files use # --- Section name --- comment headers to group fields into sections (e.g., # --- Vault-specific ---, # --- Vault-independent ---, # --- Secrets ---). Use these sections to determine what to ask about:

• Fields in sections labeled "vault-specific", "paths", or similar → ask the user for new values

• Fields in sections labeled "vault-independent", "global", "shared" → keep as-is (copy over unchanged)

• Fields in sections labeled "secrets" → ask if the new vault uses the same credentials or different ones

• If there are no section headers, present all fields and let the user decide which to change

• Ask the user for updated values for the vault-specific fields. Use the current values as visible defaults — the user only needs to supply what differs.

• Write the updated values into $CONFIG_DIR/config.<name>.

• Update the top comment line to describe the new vault (e.g., # Obsidian Wiki — <name> vault).

• Confirm:

Created: $CONFIG_DIR/config.<name>

Run `/wiki-switch <name>` to activate it, then run `wiki-setup` to initialise the new vault.

Do not switch automatically — let the user decide when to activate.