skill-repo/vendor/claude-code/plugins/git-manager/commands/setup.md

---

description: Set up the git-manager skill (permissions whitelist, optional anti-chaining hook) argument-hint: [repo-name] [repo-path]

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

Almost everything about this setup — reading/writing the skill's config, merging permissions and the hook 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 script(s) it needs to a stable, self-controlled location (~/.agent-skills/git-manager/bin/) before writing any permissions, so the permission rule never has 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 — three selectable questions first, repo path last

1a. Before asking anything, check for arguments. This command's argument-hint is [repo-name] [repo-path]. If the user invoked it with both (e.g. /git-manager:setup homelab-vault /home/hmk/projects/homelab), that already answers "whether to register a repo" and "which repo" — use the given name=path pair directly as the --repo flag in step 2, and skip both the "register any repos" option below and step 1c entirely, without asking about either. If no arguments (or only one of the two) were given, proceed normally: nothing here is decided yet, ask 1b and, if needed, 1c below.

1b. First turn: questions via the selection UI:

• Whether to register any repos at all: yes/no. Omit this question if 1a already determined a repo was given as an argument — in that case there's nothing to ask, it's already yes.
• Settings scope: project (.claude/settings.json in the current project) or user (~/.claude/settings.json). Mention: if they work across many separate repos/projects, user avoids repeating setup per project.
• Anti-chaining hook: yes/no, after explaining it never silently blocks or silently allows anything, it only forces the normal confirmation prompt when a Bash command contains shell chaining operators (&&, ;, |, backticks, $(...)), as a safety net given Claude Code's Bash allow-list matching has had bugs around compound commands (see hooks/force-ask-on-chaining.sh for details).
• Ask-before-raw-git hook: yes/no, after explaining it never silently blocks or silently allows anything either — it only forces the normal confirmation prompt when a Bash command runs raw git instead of the git_cmd.sh wrapper. It never fully blocks raw git (that stays a valid fallback for subcommands the wrapper deliberately doesn't support, e.g. stash/merge/rebase/reset, or for repos that aren't registered yet) — it just makes sure raw git use is always a visible, confirmed choice rather than something that slips through unnoticed (see hooks/force-ask-on-raw-git.sh for details). Independent of the anti-chaining hook — either, both, or neither can be installed.

1c. Only if the answer to "register any repos" was yes AND 1a didn't already supply a repo: a second turn, plain chat message, no tool call. Ask exactly: "Which repos should git-manager know about? Provide as name=path pairs." 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.) Skip this sub-step entirely — don't ask it at all — if the answer to "register any repos" was no, or if 1a already supplied a repo.

2. Locate the plugin, then 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>/. Never hardcode or guess a version number — it changes on every release of this plugin, and a stale directory from a previous version can still be sitting on disk right alongside the current one (an old version won't recognize newer flags like --install-raw-git-hook, so running it by mistake fails in a confusing way). Always start with exactly one bounded, read-only lookup instead:

find ~/.claude/plugins/cache/skill-repo/git-manager -maxdepth 1 -type d 2>/dev/null

• Exactly one version directory found: use it.
• More than one found: prefer whichever one contains a .in_use marker file (Claude Code writes this into the currently-active version's directory). If none of them has one, or more than one does, fall back to whichever directory's .claude-plugin/plugin.json reports the highest version. Don't disambiguate any other way — no stat/mtime comparisons, no diffing scripts between versions, no probing with --help (there is no --help; unrecognized flags just print Error: unknown argument). That kind of exploration is exactly what this bounded lookup exists to avoid.
• None found: the plugin likely isn't installed under this name or marketplace — say so and stop rather than guessing at a different path.

Then run, as a single Bash call (no test -f ... && pre-check, no piping through grep/head to inspect it first):

~/.claude/plugins/cache/skill-repo/git-manager/<version>/scripts/setup.sh \
  --settings-scope <project|user> \
  [--project-dir <path>] \
  [--repo <name>=<path> ...] \
  [--install-hook] \
  [--install-raw-git-hook]

Include --repo name=path once per repo from step 1, --install-hook and --install-raw-git-hook only for the ones the user opted into (they're independent flags), and --project-dir only if --settings-scope project and the project isn't the current working directory. If this one call errors, that means the version picked above was wrong — re-run the find above (and re-check .in_use/plugin.json) rather than falling back to reading source files or trying more flags. 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, whether the hook was installed, repos 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 git_cmd.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.