Added git-manager, updated READMEs
This commit is contained in:
@@ -0,0 +1,97 @@
|
||||
---
|
||||
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,
|
||||
`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:
|
||||
|
||||
```bash
|
||||
<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:
|
||||
|
||||
```bash
|
||||
<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:
|
||||
|
||||
```bash
|
||||
cat ~/.agent-skills/git-manager/config.json 2>/dev/null
|
||||
```
|
||||
|
||||
```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. 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.
|
||||
Reference in New Issue
Block a user