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 end to end. As part of the git-manager plugin, this command is automatically namespaced by Claude Code and invoked as /git-manager:setup. Follow these steps in order.

1. Determine the skill's install directory

This plugin's skills/git-manager/ is a symlink into the repo's tool-neutral skills/git-manager/ directory (the single source of truth for SKILL.md and scripts/, shared across all vendor adapters in this repo). Resolve it to its real, absolute, symlink-free path:

realpath <plugin-dir>/skills/git-manager

This resolved path is <SKILL_DIR> for the rest of this setup.

2. Optionally register named repos

If $ARGUMENTS contains a repo name and path, or the user wants to pre-register repos now (e.g. an Obsidian vault repo used alongside a code repo), write/merge them into ~/.agent-skills/git-manager/config.json:

mkdir -p ~/.agent-skills/git-manager
cat > ~/.agent-skills/git-manager/config.json << 'EOF'
{
  "repos": [
    {"name": "<short-name>", "path": "<absolute-repo-path>"}
  ]
}
EOF

If the file already exists, merge new entries in rather than overwriting. This step is entirely optional — the skill works without any named repos, operating on the current working directory by default.

3. Generate and merge the minimal permissions whitelist

Exactly one command needs whitelisting — everything else about this skill's safety comes from the wrapper script's own subcommand allowlist and repo resolution, not from a long list of Bash rules:

• Bash(<SKILL_DIR>/scripts/git_cmd.sh:*)
• Read(~/.agent-skills/git-manager/config.json)

Steps:

1. Locate the target settings file: prefer the project-level .claude/settings.json if a project is open, otherwise the user-level ~/.claude/settings.json. Ask the user which one they want if unclear — note that if they work across many separate git repos/projects, the user-level file avoids repeating this setup per project.
2. If the target file doesn't exist yet, create it containing just these two entries under permissions.allow.
3. If it exists, read it first and merge: add only entries not already present. Don't duplicate, don't remove or overwrite unrelated existing permissions.
4. Show the user exactly what was added before writing.

Do not whitelist a generic Bash(git:*) or anything targeting cd. Do not whitelist writing to the config file — that keeps prompting for confirmation, so registering a new repo is always a visible, confirmed action.

4. Offer the anti-chaining hook

Explain to the user: this hook never silently blocks and never silently allows anything. It only ever forces the normal confirmation prompt (permissionDecision: "ask") when a Bash command contains shell chaining or substitution operators (&&, ;, |, backticks, $(...)). This exists because Claude Code's own Bash allow-list matching has had bugs where compound commands either bypass per-command checks entirely, or where a chain of individually-allowed commands still isn't recognized as such — see hooks/force-ask-on-chaining.sh for the reasoning and a link to the relevant upstream issue. With this hook installed, if a chained command ever gets constructed anyway (it shouldn't, since git_cmd.sh removes the need for cd/chaining), the user will always see a normal approval prompt for it rather than it silently going through or silently failing.

Ask the user whether to install it. If yes:

1. Locate hooks/force-ask-on-chaining.sh next to this plugin's plugin.json and note its absolute path, <HOOK_PATH>.
2. Ensure it's executable: chmod +x <HOOK_PATH>.
3. Merge this into the same settings file chosen in step 3 (project or user-level — ask if unclear, but note this hook is most useful applied broadly at the user level, since it's about Bash hygiene in general, not specific to git):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "<HOOK_PATH>"
          }
        ]
      }
    ]
  }
}

Merge into any existing hooks.PreToolUse array rather than overwriting it — don't remove other existing PreToolUse hooks for the Bash matcher or other matchers.

If the user declines, skip this step entirely; the whitelist from step 3 still works on its own, it just doesn't have this extra safety net.

5. Make the wrapper script executable

chmod +x <SKILL_DIR>/scripts/git_cmd.sh

6. Confirm and offer a test run

Summarize to the user:

• Any repos registered in step 2
• The exact permission entries added, and where
• Whether the anti-chaining hook was installed, and where

Then offer to run <SKILL_DIR>/scripts/git_cmd.sh status (against the current directory, or a registered repo) as a quick sanity check.