---
name: git-manager
description: Manages git operations (status, log, diff, show, fetch, remote, branch, checkout, add, commit, push, pull, tag) 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 <path> && git ...` to operate on a
  non-default repository — pass `--repo <name>` 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 <subcommand> [--repo <name>] [-- <git-args...>]
```

- `<subcommand>` must be one of: `status`, `log`, `diff`, `show`, `fetch`,
  `remote`, `branch`, `checkout`, `add`, `commit`, `push`, `pull`, `tag`.
  Anything else is rejected by the script itself before git runs.
- `--repo <name>` 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 <name>` 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`), 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. Those excluded subcommands can
rewrite or discard history/working-tree state in ways that are hard to
reverse; `tag` is allowed because tagging a commit doesn't carry that risk.

## When it's unclear which repo is meant

Don't guess. If a task says "the repo" or otherwise implies a repo without
naming one, and it's genuinely ambiguous which registered repo (if any) it
refers to, or the request's context doesn't clearly match any registered
repo at all, ask the user before picking a `--repo` or falling back to raw
git. Concretely, this is already handled operationally rather than needing
new logic: call `git_cmd.sh` without `--repo` and let it resolve —
`resolve_repo_path` in `_lib.sh` errors out listing every registered name
when more than one repo is configured and none was specified, and errors
saying none are registered when the config is empty. Either error is the
signal to ask the user which repo (or whether to register a new one),
rather than picking one, or reaching for raw git, on your own.

## 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/<tool>/`
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.