Generates conventional commit messages from git diffs. Use when the user asks about writing commit messages, reviewing staged changes, committing code, or needs help with git commits.
Generates conventional commit messages from staged git diffs. Use when users ask to write commits, review staged changes, or need help with git commits.
/plugin marketplace add aasanchez/claude-plugins/plugin install aasanchez-commit-message@aasanchez/claude-pluginsThis skill is limited to using the following tools:
examples.mdThis Skill teaches Claude to generate properly formatted conventional commit messages that follow the Conventional Commits specification (https://www.conventionalcommits.org/).
Conventional Commits is a specification for adding human and machine-readable meaning to commit messages. The format correlates with Semantic Versioning (SemVer):
feat → MINOR version bumpfix → PATCH version bumpBREAKING CHANGE or ! → MAJOR version bumptype(scope): subject
[optional body]
[optional footer(s)]
```text
### Type (required)
The commit type communicates the intent of the change:
- **feat**: A new feature for the user (not a new feature for build script)
- **fix**: A bug fix for the user (not a fix to a build script)
- **docs**: Documentation only changes (README, comments, JSDoc)
- **style**: Code style changes (formatting, missing semicolons, whitespace)
- **refactor**: Code changes that neither fix bugs nor add features
- **perf**: Code changes that improve performance
- **test**: Adding missing tests or correcting existing tests
- **chore**: Changes to build process, dependencies, or auxiliary tools
- **ci**: Changes to CI configuration files and scripts
- **build**: Changes to build system or external dependencies
### Scope (optional)
A scope provides additional contextual information about the affected area:
- Noun describing a section of the codebase
- Enclosed in parentheses: `feat(parser): add support for arrays`
- Examples: `api`, `ui`, `auth`, `database`, `core`, `utils`
### Subject (required)
The subject is a brief description of the change:
**Rules**:
- Maximum 50 characters (hard limit: 72)
- Use imperative, present tense: "change" not "changed" nor "changes"
- Don't capitalize the first letter (unless it's a proper noun)
- No period (.) at the end
- Be specific and descriptive
**Good examples**:
- `add user authentication`
- `fix memory leak in event handler`
- `update dependencies to latest versions`
**Bad examples**:
- `Added user authentication` (wrong tense)
- `Fix bug` (not specific)
- `Updated the dependencies.` (has period, capitalized)
### Body (optional)
Use the body to explain:
- **What** changed
- **Why** it changed (motivation)
- **Context** for the change
**Rules**:
- Separate from subject with a blank line
- Wrap at 72 characters
- Use multiple paragraphs if needed
- Use bullet points with `-` or `*` for lists
- Explain what and why, not how (code shows how)
### Footer (optional)
Footers provide metadata:
**Issue references**:
- `Closes #123` - Closes an issue
- `Fixes #456` - Fixes a bug report
- `Refs #789` - References an issue
- Can reference multiple: `Closes #123, #456`
**Breaking changes**:
- `BREAKING CHANGE: description of the breaking change`
- Must be in all caps
- Should explain migration path
## Breaking Changes Notation
Breaking changes can be indicated in two ways:
1. **Append `!` before the colon**:
```text
feat(api)!: change authentication response format
Use footer:
feat(api): change authentication response format
BREAKING CHANGE: The /auth endpoint now returns tokens in a nested
`credentials` object instead of at the root level.
When the user asks you to write a commit message or create a commit:
Run git branch --show-current to get the current branch name:
git branch --show-current
Check if the branch name contains a JIRA ticket ID using this pattern:
[A-Z][A-Z0-9_]{1,9}-\d+
JIRA ticket format rules:
Valid examples: ABC-123, PROJECT-456, JIRA-1, MY_PROJ-789, A1B2-99
Common branch patterns that contain JIRA tickets:
ABC-123-feature-descriptionfeature/PROJ-456-add-loginbugfix/FIX-789-correct-validationJIRA-1-initial-setupIf a JIRA ticket is detected, save it to prepend to the commit message.
Run git diff --staged to understand what will be committed:
git diff --staged
If nothing is staged:
git add <files> firstgit status to see untracked/modified filesDetermine:
Select the most appropriate type:
featfixdocsstylerefactorperftestchoreNote: When multiple types apply, choose the most significant one from the user's perspective.
Ask yourself:
Skip scope if:
Common scopes by project type:
api, ui, auth, database, middlewarecore, utils, parser, renderercli, commands, configCraft a concise, imperative description:
Formula: [what you're doing] [to what]
Examples:
add password reset functionalityfix null pointer in user profile handlerupdate React to version 18refactor authentication middlewareAdd a body when:
Skip the body for:
Include footer for:
Closes #123BREAKING CHANGE: descriptionRefs #123, #456Before presenting:
Present the message to the user.
If JIRA ticket was detected in Step 1:
[JIRA-TICKET] type(scope): subject
body (if any)
footer (if any)
If no JIRA ticket was detected:
type(scope): subject
body (if any)
footer (if any)
CRITICAL: The JIRA ticket must ONLY appear at the beginning of the subject line in square brackets. Do NOT mention the JIRA ticket anywhere else in the commit message:
Explain your reasoning:
Ask for confirmation before executing git commit.
Only after user confirms:
If JIRA ticket was detected:
git commit -m "$(cat <<'EOF'
[JIRA-TICKET] type(scope): subject
body
footer
EOF
)"
If no JIRA ticket:
git commit -m "$(cat <<'EOF'
type(scope): subject
body
footer
EOF
)"
Then confirm success with git log -1 or git show HEAD.
See examples.md for detailed examples covering various scenarios.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.