skill-repo/skills/git-manager/SKILL.md

name, description

name

description

git-manager

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, scripts/git_cmd.sh, 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:

<skill-dir>/scripts/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. Anything else is rejected by the script itself before git runs.
• --repo <name> is optional. Omit it to operate on the git repository containing the current working directory (this is the normal case for a single-repo Claude Code project/session). Use it to target a different, pre-configured repository without changing the working directory — e.g. a separate Obsidian vault repo alongside a code repo in the same session.
• Everything after -- is passed through to git literally (e.g. -- -m "commit message", -- --oneline -10, -- origin main).

Examples:

<skill-dir>/scripts/git_cmd.sh status
<skill-dir>/scripts/git_cmd.sh log -- --oneline -10
<skill-dir>/scripts/git_cmd.sh add -- -A
<skill-dir>/scripts/git_cmd.sh commit -- -m "Update DNS notes"
<skill-dir>/scripts/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:

cat ~/.agent-skills/git-manager/config.json 2>/dev/null

{
  "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. This file is optional — omitting --repo and relying on the current working directory works without any configuration at all.

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(<skill-dir>/scripts/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.