agentleFS
decebalsdecebals/claude-code-java/skills/git-commit/SKILL.md

git-commit

Skill763 starsChanged 56 days agoMITView on GitHub

Generate conventional commit messages for Java projects. Use when user says "commit", "create commit", "commit changes", or after completing code changes that need to be committed.

We split this skill into the rules it gives an agent

10 rules. 0 are common, 10 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 126 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    After making code changes

    line 12
  2. Distinctive:

    Use Conventional Commits format:

    line 18
  3. Distinctive:

    test: Add/update tests

    line 31
  4. Distinctive:

    No period at end

    line 44
  5. Distinctive:

    Read staged changes ONCE: git diff --staged --stat + targeted file diffs

    line 112
  6. Distinctive:

    Don't read entire files unless necessary

    line 113
  7. Distinctive:

    Use concise body - aim for 2-3 lines max

    line 114
  8. Distinctive:

    After commit, suggest next steps:

    line 133
  9. Distinctive:

    When changes span multiple components:

    line 191
  10. Distinctive:

    Always use BREAKING CHANGE footer:

    line 208

“Common” is measured: kept by at least 6 in 10 of the 126 edited versions of this file we could read. “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 Message Skill

Generate conventional, informative commit messages for Java projects.

When to Use

  • After making code changes
  • User says "commit this" / "commit changes" / "create commit"
  • Before creating PRs

Format Standard

Use Conventional Commits format:

<type>(<scope>): <subject>

<body>

<footer>

Types (Java context)

  • feat: New feature (new API, new functionality)
  • fix: Bug fix
  • refactor: Code refactoring (no functional change)
  • test: Add/update tests
  • docs: Documentation only
  • perf: Performance improvement
  • build: Maven/Gradle changes
  • chore: Maintenance (dependency updates, etc)

Scope Examples (Java specific)

  • Module name: core, api, plugin-loader
  • Component: PluginManager, ExtensionFactory
  • Area: lifecycle, dependencies, security

Subject Rules

  • Imperative mood: "Add support" not "Added support"
  • No period at end
  • Max 50 chars
  • Lowercase after type

Body (optional but recommended)

  • Explain WHAT and WHY, not HOW
  • Wrap at 72 chars
  • Reference issues: "Fixes #123" / "Relates to #456"

Examples

Simple fix

fix(plugin-loader): prevent NPE when plugin directory is missing

Check for null before accessing plugin directory to avoid
NullPointerException during initialization.

Fixes #234

Feature with breaking change

feat(api): add support for plugin dependencies versioning

BREAKING CHANGE: PluginDescriptor now requires semantic versioning
format (x.y.z) instead of free-form version strings.

Closes #567

Refactoring

refactor(core): extract plugin validation logic

Move validation logic from PluginManager to separate
PluginValidator class for better testability and separation
of concerns.

Test addition

test(plugin-loader): add integration tests for plugin loading

Add comprehensive integration tests covering:
- Loading from directory
- Loading from JAR
- Error handling for invalid plugins

Build/dependency update

build(deps): upgrade Spring Boot to 3.2.1

Update Spring Boot from 3.1.0 to 3.2.1 for security patches
and performance improvements.

Workflow

  1. Analyze changes using git diff --staged
  2. Identify scope from modified files
  3. Determine type based on change nature
  4. Generate message following format
  5. Execute commit: git commit -m "message"

Token Optimization

  • Read staged changes ONCE: git diff --staged --stat + targeted file diffs
  • Don't read entire files unless necessary
  • Use concise body - aim for 2-3 lines max
  • Batch multiple small changes into logical commits

Anti-patterns

❌ Avoid:

  • "fix stuff" / "update code" / "changes"
  • "WIP" commits (unless explicitly requested)
  • Mixing unrelated changes (use separate commits)
  • Over-detailed technical implementation in message

✅ Good commits:

  • Single logical change
  • Clear, searchable subject
  • References issues when applicable
  • Explains business value

Integration with GitHub

After commit, suggest next steps:

  • "Push changes?"
  • "Create PR for issue #X?"
  • "Continue with next task?"

Common Patterns for Java Projects

Adding new functionality

feat(extension): add support for prioritized extensions

Allow extensions to specify priority order for execution.
Extensions with higher priority run first.

Closes #123

Fixing bugs

fix(classloader): resolve resource lookup in nested JARs

ClassLoader.getResource() was failing for resources in
JARs loaded from plugin JARs (nested JARs). Fixed by
implementing proper resource resolution chain.

Fixes #456

Dependency updates

build(deps): bump slf4j from 1.7.30 to 2.0.9

Updates SLF4J to latest stable version. No API changes
required as we use only stable APIs.

Documentation improvements

docs(readme): add plugin development quickstart guide

Add step-by-step guide for creating first plugin:
- Project setup
- Implementing Plugin interface
- Building and testing

Performance optimizations

perf(plugin-loader): cache plugin descriptors

Cache parsed plugin descriptors to avoid repeated I/O
and parsing. Reduces plugin loading time by ~40%.

Related to #789

Multi-file Changes

When changes span multiple components:

refactor(core): reorganize plugin lifecycle management

- Extract lifecycle state machine to separate class
- Move validation logic to validators package
- Update tests to reflect new structure

This refactoring improves testability and separation
of concerns without changing external APIs.

Related to #111, #222

Breaking Changes

Always use BREAKING CHANGE footer:

feat(api)!: replace Plugin.start() with Plugin.initialize()

BREAKING CHANGE: The Plugin.start() method has been renamed
to Plugin.initialize() for better semantic clarity. All
plugin implementations must update their code.

Migration guide: Replace @Override start() with @Override
initialize() in all Plugin implementations.

Closes #999

Quick Reference Card

Change TypeTypeExample Scope
New featurefeatapi, core, loader
Bug fixfixplugin-loader, lifecycle
Refactoringrefactorcore, utils
Teststestintegration, unit
Docsdocsreadme, javadoc
Buildbuildmaven, deps
Performanceperfclassloader, cache
Maintenancechoreci, tooling

References

Download now (ZIP)

  • Other versions164 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 1

    1. iCesofT/awesome-ai★ 190% same

    Wrote their own version · 163

    1. github/awesome-copilot★ 41ksame name
    2. doocs/leetcode★ 37ksame name
    3. tisfeng/Easydict★ 15ksame name
    4. doocs/md★ 13ksame name
    5. spinabot/brigade★ 11ksame name
    6. GitTools/GitVersion★ 3.1ksame name
    7. igorescodro/alkaa★ 1.6ksame name
    8. microsoft/hve-core★ 1.6ksame name
    9. mattmireles/gemma-tuner-multimodal★ 1.5ksame name
    10. rohaquinlop/complexipy★ 898same name

    153 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use git-pr, github-pr-create and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • klauswgSkill

      git-pr

      Prepare, review, publish, or update a complete GitHub pull request for the current repository, including local commit readiness, safe push strategy, semantic title validation, repository-native PR templates, issue linking, and checks verification. Use when the user asks to draft, create, submit, publish, open, or update a pull request. Always require the user to review and explicitly approve the exact final PR before any push or GitHub write.

      Also in 8 projects that use this

    • mjun0812Skill

      github-pr-create

      Pull Requestを作成するSkill。現在のbranchからpull requestを作成する。言語指定可能。 ユーザーが「PR作って」「pull request作成して」のように依頼したら使うこと。

      Also in 3 projects that use this

    • MicrosoftSkill

      git-branch

      Branch management for implementation. Use when you need to create a branch, switch branches, checkout, or verify branching strategy before implementing code. Do not use for commits (use git-commit), pull requests (use pull-request), or advanced git operations (rebase, merge).

      Also in 4 projects that use this

    • klauswgSkill

      git-issue

      Prepare, review, create, or update evidence-based GitHub issues for the current repository with duplicate detection, repository-native templates, valid labels, and post-publication verification. Use when the user asks to draft, file, submit, publish, edit, or refine a GitHub issue, bug report, feature request, performance issue, or technical proposal. Always require the user to review and explicitly approve the exact final issue before any GitHub write.

      Also in 3 projects that use this

    • MicrosoftSkill

      git-merge

      Integrate branches with merge or rebase, resolve conflicts, and execute an ordinary push when explicitly authorized. Use for guided integration with optional conflict-review pauses.

      Also in 3 projects that use this

    • gologo13Skill

      git-push

      Push current branch to origin and sync with remote updates; keywords: git, rebase. Use only on explicit request; before execution, review diffs and list impact scope.

      Also in 4 projects that use this

  • In this repository17 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.