---
description: Set up the obsidian-vault-kb skill (vault path, mode, minimal permissions whitelist)
argument-hint: [vault-path] [mode]
---

Set up the `obsidian-vault-kb` skill. As part of the `obsidian-vault-kb`
plugin, this command is automatically namespaced by Claude Code and invoked
as `/obsidian-vault-kb:setup`.

Almost everything about this setup — validating vault paths, writing the
skill's config, merging permissions into settings.json, setting executable
bits — happens inside one bundled script, `scripts/setup.sh`, which you run
as a **single** Bash call. That script also copies the wrapper scripts it
needs to a stable, self-controlled location
(`~/.agent-skills/obsidian-vault-kb/bin/`) before writing any permissions,
so the permission rules never have to change again across future plugin
updates — only this first run (and, optionally, a re-run after a plugin
update) needs to locate the plugin itself.

## 1. Ask the user — selectable questions first, vault path last

**1a. First turn: two questions via the selection UI, fixed options for
both:**
- Mode: `read-only`, `append`, or `maintain` (as defined in SKILL.md —
  explain each briefly if unsure).
- Settings scope: `project` (`.claude/settings.json` in the current
  project) or `user` (`~/.claude/settings.json`).

**1b. Second turn, plain chat message, no tool call.** Ask exactly:
"What's the path to your vault? Give it a short name too if you're
registering more than one." End your turn right after asking this, with
nothing else queued up, so the user's reply is what actually gets
collected before you continue. (Only a tool call reliably pauses for a
reply in this environment; plain text followed immediately by a tool call
in the same turn does not wait — that's what caused this question to
appear skipped in an earlier version of this command.) At least one vault
is required — `setup.sh` errors out without one — so this question is
always asked, unlike the optional repos question in the git-manager
plugin's setup.

## 2. Run the setup script — one command

Claude Code installs plugins added from a local marketplace at
`~/.claude/plugins/cache/<marketplace-name>/<plugin-name>/<plugin-version>/`.
For this repo's marketplace (`skill-repo`) and this plugin's current
version (`1.0.0` — check this plugin's own `.claude-plugin/plugin.json` if
this has since changed), that's:

```bash
~/.claude/plugins/cache/skill-repo/obsidian-vault-kb/1.0.0/scripts/setup.sh \
  --settings-scope <project|user> \
  [--project-dir <path>] \
  --mode <read-only|append|maintain> \
  --vault <name>=<path> [--vault <name>=<path> ...]
```

The script itself validates each vault path exists and is a directory, and
reports an error if not — no separate validation call needed beforehand.
Try this path directly first — don't `find`/`ls` preemptively.

If the exact cache path doesn't exist (installed version differs from
`1.0.0`, differently named marketplace, or a future cache layout change),
fall back to exactly one bounded lookup instead of guessing further:

```bash
find ~/.claude/plugins/cache/skill-repo/obsidian-vault-kb -maxdepth 2 -type d 2>/dev/null
```

and construct the same `scripts/setup.sh` call using whatever version
directory that reveals. This is expected to prompt for approval the first
time — there's no way to pre-whitelist it before the setup that establishes
the whitelist has run.

## 3. Relay the result

The script prints a JSON summary (stable script location, settings file
written, config file, mode, vaults registered, the exact permission rules
added, and a note about session reload). Present that summary to the user
in plain language — don't re-read any of those files yourself to "double
check"; the script's own output already reflects exactly what's on disk.

Do **not** follow this with a test invocation of `vault_index.sh` — Claude
Code loads permissions at session start and doesn't always pick up changes
made by its own file edits within the same session, so an immediate test
can prompt (or not) in a way that doesn't reliably indicate success either
way. If a real command later still prompts, the fix is a fresh session, not
re-running this setup — the configuration is already correctly saved.