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:

```bash
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):

```bash
~/.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.