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