Git Commit

Git Commit

Workflow

Step 1: Identify changes and group atomically

git status --short
git diff
git diff --cached

Each commit = one logical change. Split unrelated changes into separate commits.

| Situation | Commits | | ---------------------------------- | --------- | | New service + its tests | 1 commit | | New feature + unrelated config fix | 2 commits | | Multiple files for one feature | 1 commit |

• If user says "commit all" - group into logical atomic commits
• If ambiguous - ask which files and grouping

Step 2: Check branch safety (BLOCKING)

git branch --show-current

Protected branches: main, master, develop, release/*, hotfix/*.

STOP if on a protected branch. Do not commit. Do not proceed to Step 3. Instead:

1. Inform the user: "Cannot commit to `` - it is a protected branch."
2. Create a feature branch: git checkout -b /
3. Only then continue to Step 3.

If on a feature branch: proceed.

Branch naming convention

Format: /

| Type | Use Case | Example | | ---------- | ------------------ | ---------------------------------- | | feat | New feature | feat/bill-reminders | | fix | Bug fix | fix/null-amount-validation | | refactor | Code restructuring | refactor/extract-payment-service | | chore | Maintenance tasks | chore/update-dependencies | | docs | Documentation | docs/api-reference | | test | Test additions | test/payment-service-coverage |

Step 3: Match project commit style

git log --format="%s" -20

Identify vocabulary, detail level, scope patterns. Mimic the project's phrasing while following Conventional Commits format.

See references/commit-format.md for type table, rules, and anti-patterns.

Step 4: Stage and commit

git add 
git commit -m "[scope]: "

For multi-line messages:

git commit -m "" -m ""

Subject line: imperative mood, under 72 chars, no period, English only. Body (if needed): wrap at 72 chars, explain what and why. The 72-char body wrap is a commit-message convention - git log and most CLI tooling render bodies as plain text in a narrow column. It does not generalize to PR descriptions (where GitHub renders soft line breaks as `` and wrapping creates visible artificial breaks), CHANGELOG prose (which follows that file's own readability conventions, not this one), or other Markdown rendered as HTML.

Do not reference docs/architecture.md, docs/decisions/, section numbers, or ADR numbers in commit messages. Those belong in specs and plans, not in the git history.

Step 5: Verify

git log --oneline -1
git show --stat HEAD

Report: commit hash, files changed, insertions/deletions.

Error Recovery

| Error | Fix | | --------------------- | ----------------------------------------------------------------- | | "nothing to commit" | Check git status, verify files have changes | | Pre-commit hook fails | Read the error, fix the issue, create a NEW commit (do not amend) | | Wrong files committed | git reset --soft HEAD~1, re-stage correctly, commit again |

Handoff

If the user also asked to create a PR, invoke the creating-pr skill after committing. Do not hand-roll gh pr create - the skill has a required template.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: sergeyklay
• Source: sergeyklay/.agents
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.