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
master or main. 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 like pnpm lint or 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 diff to 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 from git config user.name or the system username)
<description>: A kebab-case description of the change (e.g., add-user-auth, fix-login-bug)
Examples:
feature/leovs09/add-new-command
fix/johndoe/resolve-memory-leak
docs/alice/update-api-docs
refactor/bob/simplify-error-handling
chore/charlie/update-dependencies
Workflow:
- Command detects you're on
master or main
- 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
1---2name: git-commit3description: Create well-formatted commits with conventional commit messages and emoji4---56# Claude Command: Commit78Your job is to create well-formatted commits with conventional commit messages and emoji.910## Instructions1112CRITICAL: Perform the following steps exactly as described:13141. **Branch check**: Checks if current branch is `master` or `main`. 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`)152. Unless specified with `--no-verify`, automatically runs pre-commit checks like `pnpm lint` or simular depending on the project language.163. Checks which files are staged with `git status`174. If 0 files are staged, automatically adds all modified and new files with `git add`185. Performs a `git diff` to understand what changes are being committed196. Analyzes the diff to determine if multiple distinct logical changes are present207. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits218. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format2223## Best Practices for Commits2425- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated26- **Atomic commits**: Each commit should contain related changes that serve a single purpose27- **Split large changes**: If changes touch multiple concerns, split them into separate commits28- **Conventional commit format**: Use the format `<type>: <description>` where type is one of:29 - `feat`: A new feature30 - `fix`: A bug fix31 - `docs`: Documentation changes32 - `style`: Code style changes (formatting, etc)33 - `refactor`: Code changes that neither fix bugs nor add features34 - `perf`: Performance improvements35 - `test`: Adding or fixing tests36 - `chore`: Changes to the build process, tools, etc.37- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")38- **Concise first line**: Keep the first line under 72 characters39- **Emoji**: Each commit type is paired with an appropriate emoji:40 - ✨ `feat`: New feature41 - 🐛 `fix`: Bug fix42 - 📝 `docs`: Documentation43 - 💄 `style`: Formatting/style44 - ♻️ `refactor`: Code refactoring45 - ⚡️ `perf`: Performance improvements46 - ✅ `test`: Tests47 - 🔧 `chore`: Tooling, configuration48 - 🚀 `ci`: CI/CD improvements49 - 🗑️ `revert`: Reverting changes50 - 🧪 `test`: Add a failing test51 - 🚨 `fix`: Fix compiler/linter warnings52 - 🔒️ `fix`: Fix security issues53 - 👥 `chore`: Add or update contributors54 - 🚚 `refactor`: Move or rename resources55 - 🏗️ `refactor`: Make architectural changes56 - 🔀 `chore`: Merge branches57 - 📦️ `chore`: Add or update compiled files or packages58 - ➕ `chore`: Add a dependency59 - ➖ `chore`: Remove a dependency60 - 🌱 `chore`: Add or update seed files61 - 🧑💻 `chore`: Improve developer experience62 - 🧵 `feat`: Add or update code related to multithreading or concurrency63 - 🔍️ `feat`: Improve SEO64 - 🏷️ `feat`: Add or update types65 - 💬 `feat`: Add or update text and literals66 - 🌐 `feat`: Internationalization and localization67 - 👔 `feat`: Add or update business logic68 - 📱 `feat`: Work on responsive design69 - 🚸 `feat`: Improve user experience / usability70 - 🩹 `fix`: Simple fix for a non-critical issue71 - 🥅 `fix`: Catch errors72 - 👽️ `fix`: Update code due to external API changes73 - 🔥 `fix`: Remove code or files74 - 🎨 `style`: Improve structure/format of the code75 - 🚑️ `fix`: Critical hotfix76 - 🎉 `chore`: Begin a project77 - 🔖 `chore`: Release/Version tags78 - 🚧 `wip`: Work in progress79 - 💚 `fix`: Fix CI build80 - 📌 `chore`: Pin dependencies to specific versions81 - 👷 `ci`: Add or update CI build system82 - 📈 `feat`: Add or update analytics or tracking code83 - ✏️ `fix`: Fix typos84 - ⏪️ `revert`: Revert changes85 - 📄 `chore`: Add or update license86 - 💥 `feat`: Introduce breaking changes87 - 🍱 `assets`: Add or update assets88 - ♿️ `feat`: Improve accessibility89 - 💡 `docs`: Add or update comments in source code90 - 🗃️ `db`: Perform database related changes91 - 🔊 `feat`: Add or update logs92 - 🔇 `fix`: Remove logs93 - 🤡 `test`: Mock things94 - 🥚 `feat`: Add or update an easter egg95 - 🙈 `chore`: Add or update .gitignore file96 - 📸 `test`: Add or update snapshots97 - ⚗️ `experiment`: Perform experiments98 - 🚩 `feat`: Add, update, or remove feature flags99 - 💫 `ui`: Add or update animations and transitions100 - ⚰️ `refactor`: Remove dead code101 - 🦺 `feat`: Add or update code related to validation102 - ✈️ `feat`: Improve offline support103104## Guidelines for Splitting Commits105106When analyzing the diff, consider splitting commits based on these criteria:1071081. **Different concerns**: Changes to unrelated parts of the codebase1092. **Different types of changes**: Mixing features, fixes, refactoring, etc.1103. **File patterns**: Changes to different types of files (e.g., source code vs documentation)1114. **Logical grouping**: Changes that would be easier to understand or review separately1125. **Size**: Very large changes that would be clearer if broken down113114## Examples115116Good commit messages:117- ✨ feat: add user authentication system118- 🐛 fix: resolve memory leak in rendering process119- 📝 docs: update API documentation with new endpoints120- ♻️ refactor: simplify error handling logic in parser121- 🚨 fix: resolve linter warnings in component files122- 🧑💻 chore: improve developer tooling setup process123- 👔 feat: implement business logic for transaction validation124- 🩹 fix: address minor styling inconsistency in header125- 🚑️ fix: patch critical security vulnerability in auth flow126- 🎨 style: reorganize component structure for better readability127- 🔥 fix: remove deprecated legacy code128- 🦺 feat: add input validation for user registration form129- 💚 fix: resolve failing CI pipeline tests130- 📈 feat: implement analytics tracking for user engagement131- 🔒️ fix: strengthen authentication password requirements132- ♿️ feat: improve form accessibility for screen readers133134Example of splitting commits:135- First commit: ✨ feat: add new solc version type definitions136- Second commit: 📝 docs: update documentation for new solc versions137- Third commit: 🔧 chore: update package.json dependencies138- Fourth commit: 🏷️ feat: add type definitions for new API endpoints139- Fifth commit: 🧵 feat: improve concurrency handling in worker threads140- Sixth commit: 🚨 fix: resolve linting issues in new code141- Seventh commit: ✅ test: add unit tests for new solc version features142- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities143144## Command Options145146- `--no-verify`: Skip running the pre-commit checks (lint, build, generate:docs)147148## Branch Naming Convention149150When 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:151152```153<type>/<git-username>/<description>154```155156**Components:**157- `<type>`: The commit type (feature, fix, docs, refactor, perf, test, chore, etc.)158- `<git-username>`: Your git username (obtained from `git config user.name` or the system username)159- `<description>`: A kebab-case description of the change (e.g., `add-user-auth`, `fix-login-bug`)160161**Examples:**162- `feature/leovs09/add-new-command`163- `fix/johndoe/resolve-memory-leak`164- `docs/alice/update-api-docs`165- `refactor/bob/simplify-error-handling`166- `chore/charlie/update-dependencies`167168**Workflow:**1691. Command detects you're on `master` or `main`1702. Asks: "You're on the main branch. Do you want to create a separate branch?"1713. If "No": Proceeds with commit on current branch1724. If "Yes": Analyzes your changes to determine the type, asks for a brief description, creates the branch, and proceeds with commit173174## Important Notes175176- By default, pre-commit checks (`pnpm lint`, `pnpm build`, `pnpm generate:docs`) will run to ensure code quality177- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first178- If specific files are already staged, the command will only commit those files179- If no files are staged, it will automatically stage all modified and new files180- The commit message will be constructed based on the changes detected181- Before committing, the command will review the diff to identify if multiple commits would be more appropriate182- If suggesting multiple commits, it will help you stage and commit the changes separately183- Always reviews the commit diff to ensure the message matches the changes