Commit Skill

Create a high-quality git commit from the currently staged changes.

Steps

1. •

   Check for staged changes Run git diff --cached --stat to see what's staged. If nothing is staged, tell the user and suggest what to stage.

2. •

   Analyze the changes Run git diff --cached to read the actual changes. Understand:

   • •What files were modified, added, or deleted
   • •The nature of the changes (new feature, bug fix, refactor, docs, test, chore, style)
   • •The scope of the changes (which module/component is affected)
3. •

   Check recent commit style Run git log --oneline -10 to see the project's existing commit message style.

4. •

   Generate the commit message Follow the Conventional Commits format:

   code

   <type>(<scope>): <short description>
   
   <optional body explaining WHY, not WHAT>
   
   <optional footer>
   

   Types:

   • •feat — new feature
   • •fix — bug fix
   • •refactor — code restructuring without behavior change
   • •docs — documentation changes
   • •test — adding or fixing tests
   • •chore — maintenance tasks (deps, config, etc.)
   • •style — formatting, whitespace, etc.
   • •perf — performance improvements
   • •ci — CI/CD changes
5. •

   Create the commit Use git commit -m "..." with the generated message. Use a HEREDOC for multi-line messages.

6. •

   Show the result Run git log -1 to confirm the commit was created successfully.

Rules

• •The first line must be under 72 characters
• •Use imperative mood ("add feature" not "added feature")
• •The body should explain WHY the change was made, not WHAT changed (the diff shows WHAT)
• •If there are breaking changes, add BREAKING CHANGE: in the footer
• •Never skip the analysis step — always read the full diff
• •Match the project's existing commit style when possible