--- name: git-manager description: Manages git operations (status, log, diff, show, fetch, remote, branch, checkout, add, commit, push, pull) across one or more git repositories — including non-code repositories such as an Obsidian vault kept under version control — through a single wrapper script instead of raw shell `git`/`cd` commands. Always use this skill instead of running `git` or `cd` directly whenever the task involves checking status, committing, pushing, pulling, or otherwise managing a git repository, especially when multiple repositories are involved in the same session (e.g. a code repo and a separate notes/vault repo). --- # Git Manager This skill wraps all git operations in a single script, permanently installed at `~/.agent-skills/git-manager/bin/git_cmd.sh` by this plugin's setup (not run from wherever this skill's own files happen to live — see "Setup and permissions" below for why), so that: - There is never a need for `cd && git ...` to operate on a non-default repository — pass `--repo ` instead. - There is never a need to chain multiple git commands with `&&`/`;`/`|` in one shell invocation — each git operation is its own separate call to the wrapper. This matters beyond convenience: on the host tool side (see "Setup and permissions" below), only this single wrapper script is whitelisted to run without a confirmation prompt. Chained or `cd`-based commands don't match that whitelist entry, so avoiding them isn't just tidier — it's what keeps every git operation actually covered by the whitelist instead of falling back to prompts (or, worse, slipping through on a stale broad rule). ## How to run git commands Always use: ```bash ~/.agent-skills/git-manager/bin/git_cmd.sh [--repo ] [-- ] ``` - `` must be one of: `status`, `log`, `diff`, `show`, `fetch`, `remote`, `branch`, `checkout`, `add`, `commit`, `push`, `pull`. Anything else is rejected by the script itself before git runs. - `--repo ` targets a specific pre-configured repository. The script itself (not this skill's own logic) decides what happens if it's omitted: with exactly one repo registered in `~/.agent-skills/git-manager/config.json`, that one is used automatically; with more than one, the script errors and lists the registered names so you can retry with `--repo`; with none registered, it errors saying to register one first. The current working directory is never consulted for this — whether it happens to be a git repository itself is not a signal this skill acts on. If the task names a repo explicitly, pass `--repo ` for that one regardless of how many are registered. - Everything after `--` is passed through to `git` literally (e.g. `-- -m "commit message"`, `-- --oneline -10`, `-- origin main`). - Don't pre-check whether `~/.agent-skills/git-manager/bin/git_cmd.sh` exists with a separate command (e.g. `test -x ... && ...`) before calling it — that's exactly the kind of chained command this skill exists to avoid, and it'll trigger the anti-chaining hook if installed. Just invoke it directly. If it fails with "No such file or directory" (or similar), that means setup hasn't been run for this tool yet — tell the user to run it first (for Claude Code: `/git-manager:setup`) rather than trying to invoke the script from wherever this skill's own files happen to be mounted (a plugin cache, a symlink target, etc.) — that location isn't guaranteed stable and isn't what gets whitelisted. Examples: ```bash ~/.agent-skills/git-manager/bin/git_cmd.sh status ~/.agent-skills/git-manager/bin/git_cmd.sh log -- --oneline -10 ~/.agent-skills/git-manager/bin/git_cmd.sh add -- -A ~/.agent-skills/git-manager/bin/git_cmd.sh commit -- -m "Update DNS notes" ~/.agent-skills/git-manager/bin/git_cmd.sh push --repo homelab-notes -- origin main ``` Never call `git` directly, and never use `cd` to switch into a different repo before running git — use `--repo` instead. If a task genuinely needs a subcommand outside the allowed list (e.g. `stash`, `merge`, `rebase`, `reset`, `tag`), say so explicitly to the user rather than working around the restriction (e.g. via `git -C` called outside this script, or editing `.git` internals directly) — that path isn't whitelisted and existing on purpose as a guardrail, not an oversight. ## Multi-repo setup If a task refers to a named repo (e.g. "push the homelab-notes vault") and `~/.agent-skills/git-manager/config.json` doesn't have an entry for it yet, ask the user for its absolute path and add it. Use the Read/Write file tools for this, not `cat`/Bash — the whitelisted permission for this file is `Read(~/.agent-skills/git-manager/config.json)`, which covers the Read file tool, not a Bash `cat` invocation of the same path (those are separate permission checks in Claude Code, even though they access the same file). Read the file (it may not exist yet, that's fine — treat that as no repos registered): ```json { "repos": [ {"name": "homelab-notes", "path": "/absolute/path/to/vault"}, {"name": "dwh-pipeline", "path": "/absolute/path/to/repo"} ] } ``` Merge new entries in rather than overwriting existing ones. At least one repo must be registered for this skill to do anything — there is no current-working-directory fallback. ## Setup and permissions Configuration lives at the tool-neutral path `~/.agent-skills/git-manager/config.json`, not a Claude-specific location. Host-specific setup (permissions whitelist, hooks) lives under `vendor//` in this repo, not in this skill itself. For Claude Code, see `vendor/claude-code/plugins/git-manager/commands/setup.md` (`/git-manager:setup`), which whitelists exactly one command — `Bash(~/.agent-skills/git-manager/bin/git_cmd.sh:*)` — and optionally installs a PreToolUse hook that forces a normal confirmation prompt (not a silent block, not a silent allow) for any Bash call containing shell chaining operators (`&&`, `;`, `|`, backticks, `$(...)`), as a safety net against Claude Code's own permission-matching not always splitting compound commands correctly.