Observed live: a stale plugin-cache version dir (1.0.0) coexisted with
the active one (1.1.0). setup.md's 'try the hardcoded version path
first' advice picked the stale one, its --install-raw-git-hook flag
failed silently, and Claude went on an unscripted forensic dig (chained
test&&echo, --help probing, grep/cat across both version dirs, cat'ing
plugin.json, stat'ing .in_use mtimes) to figure out which version was
actually active.
Fix, in both plugins' commands/setup.md:
- Never hardcode a version number. Always do one bounded
find -maxdepth 1 -type d first; disambiguate multiple hits via the
.in_use marker Claude Code itself writes, falling back to highest
plugin.json version. Explicitly rule out the exploration that
happened here (stat/mtime, --help, reading source, diffing versions)
since setup.sh has no --help and unrecognized flags just error.
- Wire up the declared but previously-unused argument-hint
([repo-name] [repo-path] / [vault-path] [mode]): if the user already
supplied it on the command line, skip asking the question that would
just re-collect the same info.
Forces a normal confirmation prompt (never a silent block, never a silent
allow) when Bash runs raw git instead of git_cmd.sh, worded more
insistently when the subcommand is one the wrapper already supports.
Raw git stays a valid fallback for unsupported subcommands and
unregistered repos - a hard deny would remove that fallback entirely.
Also documents in SKILL.md that repo ambiguity (which registered repo is
meant, or none at all) must be resolved by asking the user rather than
guessing - a hook only sees the literal command string, not the
conversation, so that judgment can't live in the hook itself.
Henner M. Kruse