Henner M. Kruse
88 lines
4.2 KiB
Markdown
88 lines
4.2 KiB
Markdown
---
|
|
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.
|