pivoshenkopivoshenko/pivoshenko.ai/skills/git-commit/SKILL.md

git-commit

Skill6 starsChanged 44 days agoMITView on GitHub

Run git commit using Angular conventional commit format (header + footer only, no body). Use when the user asks to commit, create a commit, /git-commit, or save changes to git. Also trigger on "snapshot this", "save my work", "check in changes", "wrap up", "ship this locally", or whenever the user finishes a logical unit of work and the tree is dirty. Boundary with `git-pr-create`: this skill owns only the explicitly local framing - bare "ship this" / "ship it" / "send for review" means the work should leave the machine, which is `git-pr-create`'s flow. Stages relevant files and commits immediately without asking for confirmation.

Reads credentials

We split this skill into the rules it gives an agent

6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.

0
Common
Most of the 126 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Read diff -> one commit or many (see Atomic) -> write msg
line 18
Distinctive:
Commit now. Many groups + already mass-staged -> git restore --staged .
line 21
Distinctive:
If the header can't carry the change, the commit isn't atomic -> split it (see Atomic).
line 51
Very specific:
No ticket IDs in header (go in footer).
line 63
Distinctive:
No empty/placeholder trailers.
line 122
Very specific:
Never --no-verify / --no-gpg-sign unless asked.
line 134

“Common” is measured: kept by at least 6 in 10 of the 126 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Git Commit

Conventional commit. No confirm. No dry-run.

Flow

Parallel: git status + git diff --staged
Nothing staged -> stage relevant (paths > -A). Something already staged -> commit exactly the stage; mention leftover unstaged paths, don't add them. Never .env / creds / secrets
Parallel: git diff --staged (if just staged) + git log --oneline -5
Read diff -> one commit or many (see Atomic) -> write msg
- Branch linked to an issue -> add the closing trailer. Read the link with git config --get branch.$(git branch --show-current).issue; git-issue-start records it there. Why -> the branch name carries no ticket id by default, so this is the only durable link between the work and the tracker
- Many commits from one issue -> the trailer goes on the last one only. Why -> every commit carrying Closes #42 is noise on the issue timeline, and GitHub closes on the first merged one regardless
Commit now. Many groups + already mass-staged -> git restore --staged . to unstage (modern idiom; git reset HEAD also fine), then stage+commit per group. Loop til clean
Print hash + one-liner per commit

Atomic

Mixed concerns -> split. No mega-commit.

Group by:

Type - feat / fix / docs / refactor / test never share
Scope - diff modules/pkgs = diff commits
Logical unit - one thing per commit. Each builds + tests alone

Split signals:

1 unrelated area
Behavior + format/rename mixed (format separate)
Summary needs "and" / "also" / "+"
Unsure -> ask user how to group

Msg Format

<header>

<footer>

header required. footer optional. No body, ever.

If the header can't carry the change, the commit isn't atomic -> split it (see Atomic). The "why" lives in the PR body, the issue, or the code comment - not here.

Header

<type>(<scope>): <short summary>

Type: build|chore|ci|docs|feat|fix|perf|refactor|test
Scope: optional. Affected area/module/pkg. Lowercase, kebab/short noun. One scope only - pick the dominant one, else omit
Summary: imperative present ("add" not "added"/"adds"), lowercase, no trailing .
Whole header ≤ 72 chars. Tighter is better; aim ≤ 50 for the summary itself
No ticket IDs in header (go in footer). No emoji. No [WIP]

Type Pick

Pick the most specific. Behavior change > non-behavior. User-visible > internal.

SemVer bump column is the canonical mapping used by cliff.toml across all repositories. feat!: / BREAKING CHANGE: footer always -> MAJOR regardless of type.

Type	SemVer	Use when	Examples
feat	MINOR	New user-visible capability or API	new endpoint, new CLI flag, new component, new public function
fix	PATCH	Restoring intended behavior after a defect	crash on null input, wrong calc, regression repair
perf	PATCH	Same behavior, measurably faster / lighter	cache hot path, drop O(n²) loop, lazy-load
refactor	PATCH	Code shape changes; behavior identical	rename, extract, inline, move file, dedupe - no API or output change
test	none	Test files only	add coverage, fix flake, rename test
docs	none	Docs / comments / `README` / changelog only	prose edits, JSDoc, ADRs, doc-only typos
build	none	Build system, deps, lockfiles, packaging	`package.json` deps, `uv.lock`, Dockerfile, bundler config
ci	none	CI/CD pipeline config	GH Actions workflow, release pipeline, branch protection scripts
chore	none	Repository maintenance with no code/build/CI/docs effect	`.gitignore`, editor config, tooling configs not tied to build

Tiebreakers

Bug -> fix > refactor > chore
Perf -> perf > refactor
New feature ships with its tests -> single feat commit. Tests for existing code -> test
README typo -> docs. README rewrite that ships new product info -> still docs (no code)
Bumping a dep that fixes a bug here -> fix (your bug) or build (just the bump). Pick by user-visible effect
Lockfile-only churn from install -> build. Tooling config like biome.json formatting rules -> chore. CI workflow YAML -> ci
Renaming for clarity -> refactor. Renaming to land a new API -> part of the feat
Formatting / whitespace -> separate chore commit
Revert -> revert: prefix, never one of the above (see Revert)

Footer

Trailers only. One per line, Token: value, after a single blank line below the header. Order: breaking change -> deprecation -> refs.

Allowed tokens:

BREAKING CHANGE: <summary> - exact spelling (Angular spec). Detail + migration steps follow on subsequent lines, ≤ 5 lines
DEPRECATED: <what> - same shape; include upgrade path. ≤ 5 lines
Fixes #<n> / Closes #<n> / Resolves #<n> - issue auto-close. Multiple -> one per line or comma-separated. Auto-filled from branch.<name>.issue when set (see Flow step 4)
Refs: #<n> / See: <url> - non-closing references

BREAKING CHANGE: <summary>
<detail + migration>
Fixes #<n>

DEPRECATED: <what>
<detail + upgrade path>
Closes #<n>

Footer rules:

No Co-Authored-By: / "Generated with Claude" / tool-attribution trailers ever, unless user explicitly asks. Why -> standing user policy
No Signed-off-by: unless the repository's CONTRIBUTING requires DCO
No empty/placeholder trailers. No footer at all is fine
Breaking change without migration steps -> ask user before committing. Reviewers need the upgrade path

Revert

revert: + reverted header, then a single line: This reverts commit <SHA>.

Reason -> append to that same line only if non-obvious. Nothing else.

Rules

One logical change per commit. Else split
Never --no-verify / --no-gpg-sign unless asked. Why -> hooks catch real failures (lint, type, secret scan); skipping = shipping broken code
Pre-commit hook fail -> fix + re-stage + new commit. No amend. Why -> hook fail means the commit didn't happen; --amend would modify the previous (unrelated) commit and silently rewrite it

Download now (ZIP)

Other versions164 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 164
github/awesome-copilot★ 41ksame name
doocs/leetcode★ 37ksame name
tisfeng/Easydict★ 15ksame name
doocs/md★ 13ksame name
spinabot/brigade★ 11ksame name
GitTools/GitVersion★ 3.1ksame name
igorescodro/alkaa★ 1.6ksame name
microsoft/hve-core★ 1.6ksame name
mattmireles/gemma-tuner-multimodal★ 1.5ksame name
rohaquinlop/complexipy★ 898same name
154 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use git-pr, github-pr-create and 10 more.
Other files people use alongside this one.
- klauswgSkill
  git-pr
  Prepare, review, publish, or update a complete GitHub pull request for the current repository, including local commit readiness, safe push strategy, semantic title validation, repository-native PR templates, issue linking, and checks verification. Use when the user asks to draft, create, submit, publish, open, or update a pull request. Always require the user to review and explicitly approve the exact final PR before any push or GitHub write.
  Also in 9 projects that use this
- mjun0812Skill
  github-pr-create
  Pull Requestを作成するSkill。現在のbranchからpull requestを作成する。言語指定可能。ユーザーが「PR作って」「pull request作成して」のように依頼したら使うこと。
  Also in 3 projects that use this
- MicrosoftSkill
  git-branch
  Branch management for implementation. Use when you need to create a branch, switch branches, checkout, or verify branching strategy before implementing code. Do not use for commits (use git-commit), pull requests (use pull-request), or advanced git operations (rebase, merge).
  Also in 4 projects that use this
- klauswgSkill
  git-issue
  Prepare, review, create, or update evidence-based GitHub issues for the current repository with duplicate detection, repository-native templates, valid labels, and post-publication verification. Use when the user asks to draft, file, submit, publish, edit, or refine a GitHub issue, bug report, feature request, performance issue, or technical proposal. Always require the user to review and explicitly approve the exact final issue before any GitHub write.
  Also in 3 projects that use this
- gologo13Skill
  git-push
  Push current branch to origin and sync with remote updates; keywords: git, rebase. Use only on explicit request; before execution, review diffs and list impact scope.
  Also in 6 projects that use this
- GoogleSkill
  github-pr-review
  Review a GitHub pull request and leave inline comments in a natural human reviewing voice, indistinguishable from comments typed by hand on the GitHub web UI. Deliberately bounded to defects a reader can settle by looking at the anchored line, rather than a deep audit, so every comment is cheap for the author to check. Scales to 2-20 comments by PR size, parallelises analysis across sub-agents, drafts for approval, then posts individually with human pacing. Use when the user says "review this PR", "review PR 123", pastes a github.com/.../pull/N link, or asks for comments on a pull request. Don't use for reviewing local uncommitted changes or a diff against a branch (use the `review` skill for that).
  Also in 4 projects that use this
In this repository21 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- blog-writeSkill
- cloudflare-hygieneSkill
- git-branch-cleanupSkill
- git-branch-createSkill
- git-branch-syncSkill
- git-issue-createSkill
- git-issue-startSkill
- git-issue-triageSkill
- git-pr-createSkill
- herdr-dispatchSkill
- humanizeSkill
- macos-cleanupSkill
- macos-maintenanceSkill
- obsidian-markdownSkill
- spec-applySkill
- spec-archiveSkill
- spec-exploreSkill
- spec-proposeSkill
- spec-verifySkill
- vercel-hygieneSkill

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free

6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.

Git Commit

Flow

Atomic

Msg Format

Header

Type Pick

Tiebreakers

Footer

Revert

Rules

Word for word · 0

Edited · 0

Wrote their own version · 164

git-pr

github-pr-create

git-branch

git-issue

git-push

github-pr-review

Does it work?

No reviews yet

Your trail

Now do this for your own.