git-commit-composer
Skill3 starsChanged 9 months agoMITView on GitHub
Generate conventional commit messages from staged git changes. Use when asked to compose a commit message, write a commit, generate conventional commits, or describe staged changes.
In this repository15 other files it gives its agents.
- ai-integration-generatorSkill
- api-docs-generatorSkill
- auth-scaffoldSkill
- code-reviewerSkill
- db-seed-generatorSkill
- env-config-validatorSkill
- error-boundary-generatorSkill
- nextjs-middleware-generatorSkill
- nextjs-route-generatorSkill
- prisma-migration-reviewerSkill
- prisma-query-optimizerSkill
- react-component-generatorSkill
- test-generatorSkill
- typescript-refactorerSkill
- zod-schema-generatorSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 7 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
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
- Very specific: line 8
Before generating any output, read config/defaults.md and adapt all patterns, imports, and code examples to the user's configured stack.
- Distinctive: line 12
Run git diff --cached to read staged changes.
- Distinctive: line 15
If the diff contains multiple unrelated changes, suggest splitting into separate commits.
- Distinctive: line 55
Use imperative mood: "add" not "added" or "adds"
- Distinctive: line 56
No capitalized first letter
- Distinctive: line 57
No period at the end
- Distinctive: line 77
Add a body when the description alone doesn't explain the "why":
- Very specific: line 89
Use ! after the type/scope and add a BREAKING CHANGE footer:
- Distinctive: line 100
When the diff modifies unrelated areas, suggest splitting:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Git Commit Composer
Before generating any output, read config/defaults.md and adapt all patterns, imports, and code examples to the user's configured stack.
Process
- Run
git diff --cachedto read staged changes. If nothing is staged, rungit diffand inform the user to stage changes first. - Analyze the diff to determine: what changed, why it changed, and the impact.
- Classify the change type and generate a commit message following Conventional Commits.
- If the diff contains multiple unrelated changes, suggest splitting into separate commits.
Commit Message Format
<type>(<scope>): <description>
[optional body]
[optional footer(s)]Types
| Type | When to use |
feat | New feature or capability |
fix | Bug fix |
refactor | Code change that neither fixes a bug nor adds a feature |
test | Adding or updating tests |
docs | Documentation changes only |
style | Formatting, semicolons, whitespace (no logic change) |
perf | Performance improvement |
chore | Build, tooling, dependency updates, config changes |
ci | CI/CD configuration changes |
build | Build system or external dependency changes |
revert | Reverts a previous commit |
Scope
Derive the scope from the primary area of change:
- File/module name:
feat(auth): add JWT refresh token rotation - Feature area:
fix(checkout): prevent double charge on retry - Layer:
refactor(api): extract validation middleware
Omit scope if the change spans many unrelated areas.
Description Rules
- Use imperative mood: "add" not "added" or "adds"
- No capitalized first letter
- No period at the end
- Under 72 characters total (including type and scope)
- Describe what the change does, not what was wrong
BAD:
fix: Fixed the bug where users couldn't log in.
feat: Added new validation to the form
chore: updated dependenciesGOOD:
fix(auth): prevent login failure when session cookie is expired
feat(form): add email format validation to signup form
chore(deps): bump next from 14.1.0 to 14.2.0Body
Add a body when the description alone doesn't explain the "why":
fix(api): return 404 instead of 500 for missing resources
Previously, querying a non-existent user threw an unhandled
PrismaClientKnownRequestError, resulting in a 500 response.
Now the error is caught and mapped to a proper 404.Breaking Changes
Use ! after the type/scope and add a BREAKING CHANGE footer:
feat(api)!: change user endpoint response format
BREAKING CHANGE: GET /api/users now returns { data: User[], meta: {...} }
instead of a plain User[] array. All clients must update their response parsing.Multi-Change Detection
When the diff modifies unrelated areas, suggest splitting:
## Suggested Commits
The staged changes contain 3 unrelated modifications. Recommend splitting:
1. `feat(auth): add password reset endpoint`
Files: `app/api/auth/reset/route.ts`, `lib/email.ts`
2. `fix(ui): correct date format on invoice page`
Files: `components/InvoiceTable.tsx`
3. `chore(deps): bump zod from 3.22.0 to 3.23.0`
Files: `package.json`, `package-lock.json`
To split, unstage all and re-stage per commit:
git reset HEAD .
git add app/api/auth/reset/route.ts lib/email.ts && git commit
git add components/InvoiceTable.tsx && git commit
git add package.json package-lock.json && git commitDependency Updates
For dependency changes, include the version bump:
chore(deps): bump next from 14.1.0 to 14.2.0
chore(deps-dev): add vitest 2.0.0 and @testing-library/react 16.0.0
fix(deps): pin prisma to 5.19.0 to resolve migration bugOutput Format
## Commit Message
[The generated commit message in a code block]
### Analysis
- **Type**: [type] — [reason for classification]
- **Scope**: [scope] — [derived from]
- **Files changed**: [count]
- **Insertions/deletions**: +[n] / -[n]Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

