playbooks

home / skills / henkisdabro / wookstar-claude-plugins / git-commit-helper

git-commit-helper skill

/plugins/developer/skills/git-commit-helper

This skill analyzes staged diffs to generate clear, conventional commit messages that explain why changes were made.

npx playbooks add skill henkisdabro/wookstar-claude-plugins --skill git-commit-helper

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
2.7 KB
---
name: git-commit-helper
description: Generate descriptive commit messages by analyzing git diffs. Use when the user asks for help writing commit messages or reviewing staged changes.
user-invocable: false
---

# Git Commit Helper

## Quick start

Analyse staged changes and generate a commit message:

```bash
git diff --staged
```

## Commit message format

Follow conventional commits format:

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

[optional body]

[optional footer]
```

### Types

- **feat**: New feature
- **fix**: Bug fix
- **docs**: Documentation changes
- **style**: Code style changes (formatting, missing semicolons)
- **refactor**: Code refactoring
- **test**: Adding or updating tests
- **chore**: Maintenance tasks

### Example

```
feat(auth): add JWT authentication

Implement JWT-based authentication system with:
- Login endpoint with token generation
- Token validation middleware
- Refresh token support
```

> For more examples (bugfix, refactor, multi-file, breaking changes, scopes), see `references/examples.md`.

## Commit message guidelines

**DO:**

- Use imperative mood ("add feature" not "added feature")
- Keep first line under 50 characters
- Capitalise first letter
- No period at end of summary
- Explain WHY not just WHAT in body

**DON'T:**

- Use vague messages like "update" or "fix stuff"
- Include technical implementation details in summary
- Write paragraphs in summary line
- Use past tense

## Template workflow

1. **Review changes**: `git diff --staged`
2. **Identify type**: Is it feat, fix, refactor, etc.?
3. **Determine scope**: What part of the codebase?
4. **Write summary**: Brief, imperative description
5. **Add body**: Explain why and what impact
6. **Note breaking changes**: If applicable

> For git commands (analysing diffs, interactive staging, amending commits), see `references/git-commands.md`.

## Best practices

1. **Atomic commits** - One logical change per commit
2. **Test before commit** - Ensure code works
3. **Reference issues** - Include issue numbers if applicable
4. **Keep it focused** - Don't mix unrelated changes
5. **Write for humans** - Future you will read this

## Commit message checklist

- [ ] Type is appropriate (feat/fix/docs/etc.)
- [ ] Scope is specific and clear
- [ ] Summary is under 50 characters
- [ ] Summary uses imperative mood
- [ ] Body explains WHY not just WHAT
- [ ] Breaking changes are clearly marked
- [ ] Related issue numbers are included

## References

- `references/examples.md` - Detailed commit message examples (feature, bugfix, refactor, multi-file, breaking changes, scope examples)
- `references/git-commands.md` - Git commands for analysing changes, interactive staging, and amending commits

Overview

This skill generates descriptive, conventional commit messages by analyzing staged git diffs. It recommends commit type, scope, concise summary, and a focused body that explains why the change was made. Use it to produce consistent, human-friendly commits that follow best practices for traceability and code review.

How this skill works

The skill inspects staged changes (git diff --staged) to determine file groups, modified functions, and intent (feature, fix, docs, refactor, test, style, chore). It suggests a conventional-commits formatted message: <type>(<scope>): <summary> plus an optional body and footer for issue references or breaking changes. The output emphasizes imperative mood, a sub-50 character summary, and a body that explains rationale and impact.

When to use it

  • Preparing a commit from staged changes
  • Needing a consistent conventional-commit message
  • Writing summaries for code review or CI changelogs
  • Refining vague or terse commit messages
  • Adding issue references or noting breaking changes

Best practices

  • Make commits atomic—one logical change per commit
  • Choose the most specific type and scope that apply
  • Keep the summary under 50 characters and use imperative mood
  • Use the body to explain why and the impact, not low-level implementation
  • Reference issue numbers and clearly mark breaking changes

Example use cases

  • Generate a commit message for a new authentication feature across multiple files
  • Create a concise fix commit after stabilizing a failing unit test
  • Convert a terse staged change into a conventional-commits formatted message with scope and body
  • Draft a chore commit for dependency bumps or build tooling changes
  • Annotate a refactor commit to explain design decisions and ensure reviewers understand intent

FAQ

Does it require the repository to be committed locally?

Yes. It analyzes the staged changes in your local git index (git diff --staged) to produce accurate messages.

Will it include implementation details in the summary?

No. The skill keeps summaries high-level and places rationale and important implementation notes in the body, following the guidelines to avoid low-level details in the summary.