meta-attach-vaultlisted

Interactive DEFAULTS-FIRST wizard to attach an Obsidian vault to a code/dev workspace (the dominant case), or bootstrap a standalone local vault, or register a remote vault. If the target vault ALREADY exists in the router config, skip the wizard entirely — Step 0.0 is a one-command link-only path (`obsidian-mcp-router --attach <slug> [--also <slug>]`), no provisioning. Computes a complete default plan via `plan_vault`, shows it in one line, lets the user accept it as-is (happy path = 1 interaction) or adjust any point, then provisions in one `provision_vault` call. Use whenever the user wants to "set up Obsidian for this project", "attach a vault to this workspace", "add a vault to the router", "register a new obsidian vault", "create a wiki for this repo", "connect my remote vault" — in EN or FR. Replaces the old `meta-add-vault` skill (v0.12.7+); v2 defaults-first + MCP tools (v0.35.0+).
tboome33/obsidian-mcp-router · ★ 1 · AI & Automation · score 74

Install: claude install-skill tboome33/obsidian-mcp-router

# meta-attach-vault Walk the user through attaching an Obsidian vault to their current context. The wizard is **didactic by design** — at every step it explains what's about to happen, why, and what will be touched. Built around the assumption that the user is mid-flow and shouldn't have to context-switch to read docs. ## Three flows, one wizard The wizard detects the right flow from context, but the user can override at any time. 1. **Workspace-first (the common case)** — the user is in a code/dev project (cwd has `.git/` or feels like a workspace) and wants a vault attached to it. The vault lives OUTSIDE the workspace (so it never gets pushed with credentials), and the workspace's `.env` gets a line that binds them. This is what Roland does ~95% of the time. 2. **Standalone vault (rare)** — the user wants a vault that isn't tied to any code project (think personal journal). No workspace binding. 3. **Remote vault** — the vault already runs on another machine (NAS, VPS, behind a tunnel) and just needs to be registered in the router config. ## Style rules (apply throughout the wizard) 1. **Pre-flight every Bash call**: before any `Bash` invocation that mutates state (provisioning, linking, gitignore edit, git init), output 2-3 lines in chat that explain: *what's about to run*, *why*, *what files will be touched*. This is so when the permission prompt appears, the user already has the context — they're not clicking "approve" on a cryptic command label. 2. **Use full-sent