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. First turn: four questions via the selection UI, fixed options for all four:

• Whether to register any repos at all: yes/no.
• 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.

1b. Only if the answer to "register any repos" was yes: 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.) If the answer to "register any repos" was no, skip this sub-step entirely — don't ask it at all.

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:

~/.claude/plugins/cache/skill-repo/git-manager/1.0.0/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. Try this path directly first — don't find/ls preemptively.

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

find ~/.claude/plugins/cache/skill-repo/git-manager -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, 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.