From commit-message
Create git commit messages based on current staged changes. Has support for git emoji messages.
npx claudepluginhub thecarlo/carlo-marketplace --plugin commit-messageThis skill uses the workspace's default tool permissions.
When this skill is invoked, follow these steps:
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
When this skill is invoked, follow these steps:
git statusgit status contains Changes not staged for commit, then:
git status contains nothing to commit, working tree clean, then:
git diff --cached to get the details of the staged changes. Review the diff output to understand:
git branch --show-current to determine the current branch.
main or master or dev or development:
<type>/<task-description> (see Branch Naming Format section below). Be specific rather than generic in branch name, ie feature/switch-to-branch instead of feature/update-commit-skill<branch> branch. Would you like me to create the branch <suggested-branch-name> for this commit?" with the suggested branch name filled ingit switch -c <branch-name>git branch --show-current one final time before executing the commit.
main or master or dev or development:
<branch>. Are you sure?"<branch>?"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
Closes #234
When creating a branch, use the following format:
<type>/<task-description>
Where:
<type>: One of the branch types listed below<task-description>: A short hyphenated description of the task (3-4 words max, use hyphens instead of spaces)| Type | Usage |
|---|---|
| feature | New feature for the user |
| fix | Bug fix for the user |
| docs | Documentation changes |
| style | Formatting, missing semicolons, etc. |
| refactor | Refactoring production code |
| test | Adding missing tests, refactoring tests |
| chore | Updating grunt tasks, nothing that an external user would see |
feature/add-user-authfix/null-response-handlingdocs/update-install-guidestyle/reformat-buttonsrefactor/simplify-data-logictest/add-edge-caseschore/upgrade-dependenciesOnly 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>
`
git commit or git push without user approval