Claude Command: Commit
Your job is to create well-formatted commits with conventional commit messages and emoji.
Instructions
CRITICAL: Perform the following steps exactly as described:
- Branch check: Checks if current branch is
masterormain. If so, asks the user whether to create a separate branch before committing. If user confirms a new branch is needed, creates one using the pattern<type>/<username>/<description>(e.g.,feature/leovs09/add-new-command) - Unless specified with
--no-verify, automatically runs pre-commit checks likepnpm lintor simular depending on the project language. - Checks which files are staged with
git status - If 0 files are staged, automatically adds all modified and new files with
git add - Performs a
git diffto understand what changes are being committed - Analyzes the diff to determine if multiple distinct logical changes are present
- If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
- For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format
Best Practices for Commits
- Verify before committing: Ensure code is linted, builds correctly, and documentation is updated
- Atomic commits: Each commit should contain related changes that serve a single purpose
- Split large changes: If changes touch multiple concerns, split them into separate commits
- Conventional commit format: Use the format
<type>: <description>where type is one of:
- feat: A new feature - fix: A bug fix - docs: Documentation changes - style: Code style changes (formatting, etc) - refactor: Code changes that neither fix bugs nor add features - perf: Performance improvements - test: Adding or fixing tests - chore: Changes to the build process, tools, etc.
- Present tense, imperative mood: Write commit messages as commands (e.g., "add feature" not "added feature")
- Concise first line: Keep the first line under 72 characters
- Emoji: Each commit type is paired with an appropriate emoji:
- ✨ feat: New feature - 🐛 fix: Bug fix - 📝 docs: Documentation - 💄 style: Formatting/style - ♻️ refactor: Code refactoring - ⚡️ perf: Performance improvements - ✅ test: Tests - 🔧 chore: Tooling, configuration - 🚀 ci: CI/CD improvements - 🗑️ revert: Reverting changes - 🧪 test: Add a failing test - 🚨 fix: Fix compiler/linter warnings - 🔒️ fix: Fix security issues - 👥 chore: Add or update contributors - 🚚 refactor: Move or rename resources - 🏗️ refactor: Make architectural changes - 🔀 chore: Merge branches - 📦️ chore: Add or update compiled files or packages - ➕ chore: Add a dependency - ➖ chore: Remove a dependency - 🌱 chore: Add or update seed files - 🧑💻 chore: Improve developer experience - 🧵 feat: Add or update code related to multithreading or concurrency - 🔍️ feat: Improve SEO - 🏷️ feat: Add or update types - 💬 feat: Add or update text and literals - 🌐 feat: Internationalization and localization - 👔 feat: Add or update business logic - 📱 feat: Work on responsive design - 🚸 feat: Improve user experience / usability - 🩹 fix: Simple fix for a non-critical issue - 🥅 fix: Catch errors - 👽️ fix: Update code due to external API changes - 🔥 fix: Remove code or files - 🎨 style: Improve structure/format of the code - 🚑️ fix: Critical hotfix - 🎉 chore: Begin a project - 🔖 chore: Release/Version tags - 🚧 wip: Work in progress - 💚 fix: Fix CI build - 📌 chore: Pin dependencies to specific versions - 👷 ci: Add or update CI build system - 📈 feat: Add or update analytics or tracking code - ✏️ fix: Fix typos - ⏪️ revert: Revert changes - 📄 chore: Add or update license - 💥 feat: Introduce breaking changes - 🍱 assets: Add or update assets - ♿️ feat: Improve accessibility - 💡 docs: Add or update comments in source code - 🗃️ db: Perform database related changes - 🔊 feat: Add or update logs - 🔇 fix: Remove logs - 🤡 test: Mock things - 🥚 feat: Add or update an easter egg - 🙈 chore: Add or update.gitignore file - 📸 test: Add or update snapshots - ⚗️ experiment: Perform experiments - 🚩 feat: Add, update, or remove feature flags - 💫 ui: Add or update animations and transitions - ⚰️ refactor: Remove dead code - 🦺 feat: Add or update code related to validation - ✈️ feat: Improve offline support
Guidelines for Splitting Commits
When analyzing the diff, consider splitting commits based on these criteria:
- Different concerns: Changes to unrelated parts of the codebase
- Different types of changes: Mixing features, fixes, refactoring, etc.
- File patterns: Changes to different types of files (e.g., source code vs documentation)
- Logical grouping: Changes that would be easier to understand or review separately
- Size: Very large changes that would be clearer if broken down
Examples
Good commit messages:
- ✨ feat: add user authentication system
- 🐛 fix: resolve memory leak in rendering process
- 📝 docs: update API documentation with new endpoints
- ♻️ refactor: simplify error handling logic in parser
- 🚨 fix: resolve linter warnings in component files
- 🧑💻 chore: improve developer tooling setup process
- 👔 feat: implement business logic for transaction validation
- 🩹 fix: address minor styling inconsistency in header
- 🚑️ fix: patch critical security vulnerability in auth flow
- 🎨 style: reorganize component structure for better readability
- 🔥 fix: remove deprecated legacy code
- 🦺 feat: add input validation for user registration form
- 💚 fix: resolve failing CI pipeline tests
- 📈 feat: implement analytics tracking for user engagement
- 🔒️ fix: strengthen authentication password requirements
- ♿️ feat: improve form accessibility for screen readers
Example of splitting commits:
- First commit: ✨ feat: add new solc version type definitions
- Second commit: 📝 docs: update documentation for new solc versions
- Third commit: 🔧 chore: update package.json dependencies
- Fourth commit: 🏷️ feat: add type definitions for new API endpoints
- Fifth commit: 🧵 feat: improve concurrency handling in worker threads
- Sixth commit: 🚨 fix: resolve linting issues in new code
- Seventh commit: ✅ test: add unit tests for new solc version features
- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities
Command Options
--no-verify: Skip running the pre-commit checks (lint, build, generate:docs)
Branch Naming Convention
When committing on master or main, the command will ask if you want to create a new branch. If yes, it creates a branch following this pattern:
<type>/<git-username>/<description>Components:
<type>: The commit type (feature, fix, docs, refactor, perf, test, chore, etc.)<git-username>: Your git username (obtained fromgit config user.nameor the system username)<description>: A kebab-case description of the change (e.g.,add-user-auth,fix-login-bug)
Examples:
feature/leovs09/add-new-commandfix/johndoe/resolve-memory-leakdocs/alice/update-api-docsrefactor/bob/simplify-error-handlingchore/charlie/update-dependencies
Workflow:
- Command detects you're on
masterormain - Asks: "You're on the main branch. Do you want to create a separate branch?"
- If "No": Proceeds with commit on current branch
- If "Yes": Analyzes your changes to determine the type, asks for a brief description, creates the branch, and proceeds with commit
Important Notes
- By default, pre-commit checks (
pnpm lint,pnpm build,pnpm generate:docs) will run to ensure code quality - If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
- If specific files are already staged, the command will only commit those files
- If no files are staged, it will automatically stage all modified and new files
- The commit message will be constructed based on the changes detected
- Before committing, the command will review the diff to identify if multiple commits would be more appropriate
- If suggesting multiple commits, it will help you stage and commit the changes separately
- Always reviews the commit diff to ensure the message matches the changes