Create git commit messages based on current staged changes. Has support for git emoji messages.
/plugin marketplace add thecarlo/carlo-marketplace/plugin install thecarlo-commit-message@thecarlo/carlo-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
When this skill is invoked, follow these steps:
git diff --cached to see what changes are currently staged for commitgit status to understand which files are affectedIf no changes are staged: Inform the user that no changes are staged and suggest they use git add to stage files first.
Note: git diff --cached and git diff --staged are equivalent commands - both show staged changes.
git status
git diff --staged
git diff --staged --stat
git diff --staged path/to/file
The basic semantic message format is:
<type>(<scope>): <subject>
<body>
<footer>
Where:
<type>: The type of change (see list below)<scope>: Optional, the area of codebase affected<subject>: Brief description in imperative mood<body>: Optional, detailed explanation<footer>: Optional, references to issues or breaking changesThe most common types are:
Scope is optional and specifies which part of the codebase is affected, like feat(auth): add login validation or fix(api): handle null responses.
Subject is a short, imperative description—start with a verb and keep it under 50 characters. Use present tense: "add feature" not "added feature."
Body is optional but useful for longer commits. It explains the why and what in more detail, usually wrapped at 72 characters. Separate it from the subject with a blank line.
Footer is optional and often used for referencing issues: Closes #123 or Fixes #456.
A practical example: feat(checkout): add PayPal payment option
Added integration with PayPal's API to support additional payment methods. This allows users to complete purchases without entering credit card information.
Closes #234
Only use emojis when explicitly requested by the user.
When emojis are requested, place the emoji at the start of the commit message, before the type. Format:
<emoji> <type>(<scope>): <subject>
| Type | Emoji |
|---|---|
| feat | ✨ |
| fix | 🐛 |
| docs | 📚 |
| style | 💄 |
| refactor | ♻️ |
| perf | ⚡ |
| test | ✅ |
| chore | 🔨 |
| ci | 👷 |
| build | 📦 |
| revert | ⏮️ |
| security | 🔒 |
| deps | 📦 |
Example commit messages with emojis:
✨ feat(auth): add two-factor authentication 🐛 fix(api): handle null responses correctly 📚 docs: update installation guide 💄 style(ui): reformat button component ♻️ refactor(core): simplify data processing logic ⚡ perf(database): optimize query performance ✅ test(utils): add edge case tests 🔨 chore: upgrade dependencies 👷 ci: add GitHub Actions workflow 📦 build: update webpack config 🔒 security: patch XSS vulnerability
When generating commit messages, follow these rules:
When presenting the generated commit message to the user, use this format:
Here's the suggested commit message based on your staged changes:
`
<generated commit message>
`
To commit these changes, run:
`bash
git commit -m "<generated message>"
`
Or for a multi-line commit with body:
`bash
git commit -m "<subject line>" -m "<body text>"
`
git commit without user approval: Only generate the message, then ask for user approval to run the commit commandgit log --oneline -10 to understand the existing commit style and follow the same patternsThis skill should be used when the user asks to "create a hookify rule", "write a hook rule", "configure hookify", "add a hookify rule", or needs guidance on hookify rule syntax and patterns.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.