Smart Git Commit

Create well-formatted commit: $ARGUMENTS

Current Repository State

• Git status: !git status --porcelain
• Current branch: !git branch --show-current
• Staged changes: !git diff --cached --stat
• Unstaged changes: !git diff --stat
• Recent commits: !git log --oneline -5

What This Command Does

• Unless specified with --no-verify, automatically runs pre-commit checks:

- pnpm lint to ensure code quality

- pnpm build to verify the build succeeds

- pnpm generate:docs to update documentation

• 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)

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