agentleFS
NembieNembie/claude-code-skills/skills/git-commit-composer/SKILL.md

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.

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
  1. Very specific:

    Before generating any output, read config/defaults.md and adapt all patterns, imports, and code examples to the user's configured stack.

    line 8
  2. Distinctive:

    Run git diff --cached to read staged changes.

    line 12
  3. Distinctive:

    If the diff contains multiple unrelated changes, suggest splitting into separate commits.

    line 15
  4. Distinctive:

    Use imperative mood: "add" not "added" or "adds"

    line 55
  5. Distinctive:

    No capitalized first letter

    line 56
  6. Distinctive:

    No period at the end

    line 57
  7. Distinctive:

    Add a body when the description alone doesn't explain the "why":

    line 77
  8. Very specific:

    Use ! after the type/scope and add a BREAKING CHANGE footer:

    line 89
  9. Distinctive:

    When the diff modifies unrelated areas, suggest splitting:

    line 100

≈ “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.

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

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

  1. Run git diff --cached to read staged changes. If nothing is staged, run git diff and inform the user to stage changes first.
  2. Analyze the diff to determine: what changed, why it changed, and the impact.
  3. Classify the change type and generate a commit message following Conventional Commits.
  4. If the diff contains multiple unrelated changes, suggest splitting into separate commits.

Commit Message Format

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Types

TypeWhen to use
featNew feature or capability
fixBug fix
refactorCode change that neither fixes a bug nor adds a feature
testAdding or updating tests
docsDocumentation changes only
styleFormatting, semicolons, whitespace (no logic change)
perfPerformance improvement
choreBuild, tooling, dependency updates, config changes
ciCI/CD configuration changes
buildBuild system or external dependency changes
revertReverts 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 dependencies

GOOD:

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.0

Body

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 commit

Dependency 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 bug

Output 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]

Download now (ZIP)

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.