git-master

Git Master

Use this skill when the user asks you to operate on Git history or answer a Git-history question. Be exact, conservative, and evidence-led. Read the repository state before you infer anything.

Mode Gate

Classify the request first:

• COMMIT: stage and commit local changes.
• REBASE: rebase, squash, fixup, autosquash, reorder, split, or otherwise rewrite branch history.
• HISTORY: answer when, where, who, why, or which commit changed something.
• STATUS: inspect branch, diff, or working-tree state without changing it.

Do not commit, rebase, push, force-push, reset, stash-pop, or delete anything unless the user explicitly asked for that operation. If the request is only investigative, report findings and stop.

Ground Truth

Gather independent facts in parallel when the tools allow it:

git status --short
git diff --stat
git diff --staged --stat
git branch --show-current
git log -30 --oneline
git log -30 --pretty=format:%s
git rev-parse --abbrev-ref @{upstream}
git merge-base HEAD origin/main
git merge-base HEAD origin/master

Missing upstream or missing main/master is normal. Fall back to the best available branch or report the missing fact. Never treat a failed lookup as proof.

PR Body Evidence Attachments

When a PR body needs screenshots or terminal PNGs, use the repo reference at docs/reference/github-attachment-upload.md. The allowed hosting path is GitHub user attachments from the authenticated web attachment flow; never commit temporary images, never use GitHub Releases for PR evidence, and never use external image hosts. Do not log browser cookies, CSRF tokens, S3 form fields, or upload headers.

Commit Mode

Commit only the user's requested changes. Preserve unrelated dirty work.

1. Detect message style from recent history. Use the dominant local pattern, language, and casing. Do not default to Conventional Commits unless the repo uses them.
2. Inspect the full diff, not only filenames. Separate unrelated user edits from the requested commit.
3. Build atomic groups by behavior, module, and revertability. Keep implementation and its direct tests together.
4. Prefer multiple commits for unrelated concerns. A single commit is acceptable only when the changed files form one indivisible behavior or the user explicitly asks for one commit.
5. Stage by path or hunk so each commit contains only its atomic group.
6. Before each commit, verify git diff --staged --stat and enough staged diff to prove the group is right.
7. Commit with the detected style. After each commit, verify git log -1 --oneline.