git-commit

Name: git-commit
Author: thoughtbot

15stars1forks

How to install git-commit?

thoughtbot/rails-consultant/git-commit

$npx -y skills add thoughtbot/rails-consultant --skill git-commit

Installs into the current project.

Summary

Turn the working changes into one or more atomic commits with well-written messages. Use whenever the user runs /git-commit or asks to commit their work, wrap up a feature, or "commit what I have.

Files · 1

View on GitHub

SKILL.md

1	## What this does
2
3	Look at everything that has changed in the working tree, decide how the changes should be split into commits, and then create those commits — messages and all — without stopping to ask for approval. The user invoked `/git-commit` because they trust you to make the call, so make it and report what you did afterward.
4
5	Any argument the user passes is context, not a command: a hint about intent ("addressing review feedback", "this is risky, note the migration") that should inform how you group and what you write. It is never the literal commit message.
6
7	## Step 1: Understand what changed
8
9	Before grouping anything, build a real picture of the diff. Run these together:
10
11	- `git status` — what's modified, added, deleted, untracked
12	- `git diff` — unstaged changes
13	- `git diff --staged` — anything already staged
14	- `git log --oneline -15` — recent history, to match the tone and see referenced issues/PRs
15
16	Read the diff to understand the _why_, not just the _what_. You are about to explain these changes to a future reader; you can't do that if you only know which lines moved. If something is genuinely unclear, it's fine to ask one focused question — but usually the diff plus recent history tells the story.
17
18	If there's nothing to commit, say so and stop. Never create an empty commit.
19
20	## Step 2: Decide the grouping — this is the judgment call
21
22	The goal is atomic commits: each commit is one complete, coherent change that stands on its own. The hard part is knowing how many commits that means, and there's no mechanical rule — it depends on what the work actually is.
23
24	Lean toward a single commit when the changes tell one story. If the user just built a feature — new model, its migration, the controller, the view, the tests — that's _one_ logical change even though it spans many files. Splitting it into "add migration", "add model", "add tests" produces commits that are individually broken and useless to revert. Keep it together.
25
26	Split into separate commits when the changes are genuinely independent. The tell is that the work is a _set of unrelated things_ rather than one thing:
27
28	- Addressing several distinct review comments — each comment is its own commit
29	- A handful of unrelated refactors or cleanups that happen to be sitting in the tree together
30	- A bug fix that got made alongside feature work — the fix is its own commit
31	- A dependency bump plus the feature that needed it — often two commits
32
33	Ask yourself: _if someone had to revert one part of this, would the rest still make sense?_ If yes, they're separate commits. If reverting one piece would leave the others broken, they belong together.
34
35	When in doubt, prefer fewer, larger commits over many tiny ones. An over-split history is harder to read than a cohesive one.
36
37	## Step 3: Stage each group precisely
38
39	Commit the groups one at a time. For each:
40
41	- If a group is cleanly whole files, `git add <paths>` for just those files.
42	- If a single file contains changes belonging to _different_ logical groups, stage only the relevant hunks. Write the intended hunks to a patch and apply them with `git apply --cached <patch>`, since interactive `git add -p` isn't available to you. Verify with `git diff --staged` before committing.
43	- Never `git add .` or `git add -A` blindly — that defeats the point of grouping.
44
45	Then commit that group (Step 4), and move to the next.
46
47	Respect any pre-commit hooks. If a hook modifies files or fails, don't fight it — surface what happened. Don't use `--no-verify` unless the user asked for it.
48
49	Do not push, and do not amend or rewrite existing commits. This command's job ends at creating new commits from uncommitted work.
50
51	## Step 4: Write the message
52
53	Match the voice below and let the body earn its place — a message exists so a future reader understands a decision they couldn't reconstruct from the diff.
54
55	### Subject line
56
57	- Imperative mood, capitalized, no trailing period: "Prevent double-filtering of labels", "Introduce category methods", "Optimize initialization"
58	- Wrap code identifiers in backticks: "Refactor `TopSecret::Text::GlobalMapping`"
59	- Keep it under ~50 characters where you can
60	- Add a semantic prefix only when it carries real information: "Breaking change: Validate labels"
61	- Do not append `(#123)` PR-number suffixes — those are added by GitHub on merge, not by hand
62
63	### Body
64
65	Include a body whenever there's a _why_ worth recording, which is most of the time. Skip it only for changes so self-evident the subject says everything ("Fix typo in README"). When you write one:
66
67	- Blank line after the subject, wrap prose at ~72 characters
68	- Explain the why, not the what. The diff already shows what changed.

People who liked this also viewed

6 picks

Type

caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026259k92k
git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026157k181k
setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026152k181k
resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026146k181k
using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026143k259k
finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026140k259k

git-commit

15stars1forks

View on GitHub

How to install git-commit?

thoughtbot/rails-consultant/git-commit

$npx -y skills add thoughtbot/rails-consultant --skill git-commit

Installs into the current project.

Summary

Turn the working changes into one or more atomic commits with well-written messages. Use whenever the user runs /git-commit or asks to commit their work, wrap up a feature, or "commit what I have.

Files · 1

View on GitHub

SKILL.md

1	## What this does
2
3	Look at everything that has changed in the working tree, decide how the changes should be split into commits, and then create those commits — messages and all — without stopping to ask for approval. The user invoked `/git-commit` because they trust you to make the call, so make it and report what you did afterward.
4
5	Any argument the user passes is context, not a command: a hint about intent ("addressing review feedback", "this is risky, note the migration") that should inform how you group and what you write. It is never the literal commit message.
6
7	## Step 1: Understand what changed
8
9	Before grouping anything, build a real picture of the diff. Run these together:
10
11	- `git status` — what's modified, added, deleted, untracked
12	- `git diff` — unstaged changes
13	- `git diff --staged` — anything already staged
14	- `git log --oneline -15` — recent history, to match the tone and see referenced issues/PRs
15
16	Read the diff to understand the _why_, not just the _what_. You are about to explain these changes to a future reader; you can't do that if you only know which lines moved. If something is genuinely unclear, it's fine to ask one focused question — but usually the diff plus recent history tells the story.
17
18	If there's nothing to commit, say so and stop. Never create an empty commit.
19
20	## Step 2: Decide the grouping — this is the judgment call
21
22	The goal is atomic commits: each commit is one complete, coherent change that stands on its own. The hard part is knowing how many commits that means, and there's no mechanical rule — it depends on what the work actually is.
23
24	Lean toward a single commit when the changes tell one story. If the user just built a feature — new model, its migration, the controller, the view, the tests — that's _one_ logical change even though it spans many files. Splitting it into "add migration", "add model", "add tests" produces commits that are individually broken and useless to revert. Keep it together.
25
26	Split into separate commits when the changes are genuinely independent. The tell is that the work is a _set of unrelated things_ rather than one thing:
27
28	- Addressing several distinct review comments — each comment is its own commit
29	- A handful of unrelated refactors or cleanups that happen to be sitting in the tree together
30	- A bug fix that got made alongside feature work — the fix is its own commit
31	- A dependency bump plus the feature that needed it — often two commits
32
33	Ask yourself: _if someone had to revert one part of this, would the rest still make sense?_ If yes, they're separate commits. If reverting one piece would leave the others broken, they belong together.
34
35	When in doubt, prefer fewer, larger commits over many tiny ones. An over-split history is harder to read than a cohesive one.
36
37	## Step 3: Stage each group precisely
38
39	Commit the groups one at a time. For each:
40
41	- If a group is cleanly whole files, `git add <paths>` for just those files.
42	- If a single file contains changes belonging to _different_ logical groups, stage only the relevant hunks. Write the intended hunks to a patch and apply them with `git apply --cached <patch>`, since interactive `git add -p` isn't available to you. Verify with `git diff --staged` before committing.
43	- Never `git add .` or `git add -A` blindly — that defeats the point of grouping.
44
45	Then commit that group (Step 4), and move to the next.
46
47	Respect any pre-commit hooks. If a hook modifies files or fails, don't fight it — surface what happened. Don't use `--no-verify` unless the user asked for it.
48
49	Do not push, and do not amend or rewrite existing commits. This command's job ends at creating new commits from uncommitted work.
50
51	## Step 4: Write the message
52
53	Match the voice below and let the body earn its place — a message exists so a future reader understands a decision they couldn't reconstruct from the diff.
54
55	### Subject line
56
57	- Imperative mood, capitalized, no trailing period: "Prevent double-filtering of labels", "Introduce category methods", "Optimize initialization"
58	- Wrap code identifiers in backticks: "Refactor `TopSecret::Text::GlobalMapping`"
59	- Keep it under ~50 characters where you can
60	- Add a semantic prefix only when it carries real information: "Breaking change: Validate labels"
61	- Do not append `(#123)` PR-number suffixes — those are added by GitHub on merge, not by hand
62
63	### Body
64
65	Include a body whenever there's a _why_ worth recording, which is most of the time. Skip it only for changes so self-evident the subject says everything ("Fix typo in README"). When you write one:
66
67	- Blank line after the subject, wrap prose at ~72 characters
68	- Explain the why, not the what. The diff already shows what changed.

People who liked this also viewed

6 picks

Type