
git-commit
Best practices for creating clean, atomic git commits with good messages. Use when: (1) staging and committing changes, (2) writing commit messages, (3) deciding what to group in a single commit, (4) handling pre-commit hook failures, (5) choosing between amend and new commit. Triggers on "commit", "stage", "git add", "write a commit message", or "commit my changes".
- Installs
- 64
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/onsager-ai/dev-skills --skill git-commit- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads git-commit automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Git Commit
Write clean, atomic commits that communicate intent clearly.
When to Use This Skill
Activate when any of the following are true:
- User asks to "commit", "make a commit", "stage changes", or "write a commit message"
- User says "commit my changes" or "commit this"
- A logical unit of work is complete and ready to land
- User asks about
git add,git commit, orgit amend
Decision Tree
What does the user need?
Stage + commit changes?
→ Check what changed: git status + git diff --staged
→ Group related changes (atomic commit rule below)
→ Write message in conventional format
→ If hook fails: fix root cause, re-stage, new commit
Amend the last commit?
→ ONLY if NOT yet pushed to remote
→ OK for: missing file, minor message fix, small oversight
→ New commit instead: substantial change, already pushed
Write a commit message only?
→ Follow conventional format below
→ Lead with "why", not "what"
Hook failure?
→ Read the full hook output
→ Fix the root cause — never use --no-verify
Conventional Commits Format
<type>(<scope>): <subject>
<body> ← optional; explain *why*, not *what*
<footer> ← optional; breaking changes, refs
Types
| Type | When |
|---|---|
feat | New feature or capability |
fix | Bug fix |
refactor | Code restructure, no behavior change |
docs | Documentation only |
test | Adding or fixing tests |
chore | Build, tooling, dependency updates |
perf | Performance improvement |
ci | CI/CD workflow changes |
Rules
- Subject: ≤ 72 chars, imperative mood ("add" not "added"), no trailing period
- Body: wrap at 72 chars; explain motivation, not mechanics
- Breaking change:
BREAKING CHANGE:footer, or!after type (feat!:)
Atomic Commits
One commit = one logical change. A reviewer should understand it without other commits.
Group together: all files for a single feature or fix; tests with the code they cover.
Keep separate: refactors from behavior changes; unrelated fixes; half-done work.
Never commit "WIP" or "misc fixes" — squash or split before finalizing.
Staging Checklist
Before git add, verify:
- No secrets, API keys, or credentials
- No debug code or temporary hacks (
console.log,TODO: remove) - Changes are related (one logical unit)
-
.gitignorerespected — no build artifacts or generated files unless intentional
Examples
Feature
feat(auth): add OAuth2 login flow
Replaces username/password form. Supports Google and GitHub as providers.
Token refresh is handled automatically by the auth middleware.
Bug fix
fix(publish): handle missing platform binary gracefully
Previously threw unhandled error when the platform package was absent.
Now logs a clear message and exits with code 1.
Breaking change
feat!: change publish config to support multiple binaries
BREAKING CHANGE: `binary` field renamed to `binaries` array.
Migrate: `binary: 'my-cli'` → `binaries: [{ name: 'my-cli', ... }]`
Chore
chore(deps): upgrade pnpm to 10.6.2
Pre-commit Hook Failures
- Read the full hook output — it tells you exactly what failed
- Fix the underlying issue (lint, type error, formatting)
- Re-stage the fixed files
- Create a new commit — do not amend the failed attempt
- Never use
--no-verifyunless the user explicitly asks
Setup & Activation
npx skills add -g onsager-ai/dev-skills --skill git-commit -a claude-code -y
Auto-activates when: user says "commit", "stage", "git add", or "commit message".
FAQ
What does the git-commit skill do?
Best practices for creating clean, atomic git commits with good messages. Use when: (1) staging and committing changes, (2) writing commit messages, (3) deciding what to group in a single commit, (4) handling pre-commit hook failures, (5) choosing between amend and new commit. Triggers on "commit", "stage", "git add", "write a commit message", or "commit my changes".
How do I install git-commit?
Run npx skills add https://github.com/onsager-ai/dev-skills --skill git-commit in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/git-commit/ (personal) or .claude/skills/git-commit/ (project).
Which AI agents can use git-commit?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is git-commit safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains git-commit?
It is published by onsager-ai in onsager-ai/dev-skills. It has 64 recorded installs.
More from onsager-ai/dev-skills
codegraph
onsager-ai/dev-skills
Pre-indexed code knowledge graph (MCP, SQLite + tree-sitter) for faster, lower-token exploration of brownfield codebases. Use when starting work on a repo larger than 500 files or when the task involves cross-file traversal — "where is X used", "what calls Y", "what breaks if I change Z", "trace flow from A to B", "explain this subsystem". Skip for single-file edits or sessions shorter than the cold-start cost. Triggers include "codegraph", "code graph", "index this repo", "where is X defined", "find callers of", "callees of", "blast radius of changing X", "explore this codebase". Cuts the grep + Read loops needed to orient, via O(1) SQLite lookups and FTS5 search over 8 MCP tools — but it's an unsound tree-sitter approximation, so grep stays the completeness backstop for renames/exhaustive callers.
issue-spec
onsager-ai/dev-skills
Open the skill to read its SKILL.md instructions.
plan-dag
onsager-ai/dev-skills
Open the skill to read its SKILL.md instructions.
rust-node-ci
onsager-ai/dev-skills
Open the skill to read its SKILL.md instructions.
rust-npm-publish
onsager-ai/dev-skills
Open the skill to read its SKILL.md instructions.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.