Henner M. Kruse
97 lines
4.6 KiB
Markdown
97 lines
4.6 KiB
Markdown
---
|
|
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.
|