Tagging a commit doesn't rewrite or discard history/working-tree state, unlike stash/merge/rebase/reset which stay excluded as a deliberate guardrail.
6.2 KiB
name, description
| name | description |
|---|---|
| git-manager | 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:
~/.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 togitliterally (e.g.-- -m "commit message",-- --oneline -10,-- origin main). - Don't pre-check whether
~/.agent-skills/git-manager/bin/git_cmd.shexists 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:
~/.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.
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):
{
"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.