---
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: three questions via the selection UI, fixed options for
all three:**
- 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).

**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:

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

Include `--repo name=path` once per repo from step 1, `--install-hook` only
if the user opted in, 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:

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