commit
Smart Atomic Commits
Analyze workspace changes, split into logical atomic units, and commit with emoji conventional format.
Process
- Inspect: Run
git statusandgit diff HEADto understand changes - Auto-stage: If nothing is staged,
git addall modified and new files - Analyze: Identify if multiple distinct logical changes should be split based on:
- Different concerns (unrelated parts of codebase)
- Different types (features vs fixes vs refactoring)
- File patterns (source vs docs vs config)
- Logical grouping (easier to understand separately)
- Size (large changes clearer when broken down)
- Commit: For each atomic unit, stage relevant files and commit
Commit Format
type(scope)!: emoji description
| Component | Required | Notes |
|---|---|---|
type |
Yes | Conventional commit type |
(scope) |
No | Lowercase, hyphenated (e.g., user-auth, api-client). Omit only when truly global |
! |
No | Breaking change indicator |
emoji |
Yes | After the colon, before description |
description |
Yes | Imperative mood, present tense |
Constraints: First line under 72 characters. Focus on "why" over "what". Imperative mood ("add" not "added").
Breaking Changes
Add ! after scope/type. Include BREAKING CHANGE footer:
git commit -m "feat(api)!: 💥 change auth response format" \
-m "BREAKING CHANGE: /auth/login now returns { token, user } instead of { accessToken, refreshToken }"
Commit Types
| Type | Emoji | Description |
|---|---|---|
feat |
✨ | New feature |
fix |
🐛 | Bug fix |
docs |
📝 | Documentation |
style |
💄 | Code style (formatting) |
refactor |
♻️ | Neither fix nor feature |
perf |
⚡️ | Performance improvement |
test |
✅ | Adding/fixing tests |
chore |
🔧 | Build process, tools |
ci |
🚀 | CI/CD improvements |
revert |
⏪️ | Reverting changes |
Extended Emoji Reference
Features: 🏷️ types, 💬 text/literals, 🌐 i18n, 👔 business logic, 📱 responsive, 🚸 UX, 🦺 validation, 🧵 concurrency, 🔍️ SEO, 🔊 logs, 🚩 feature flags, 💥 breaking, ♿️ a11y, ✈️ offline, 📈 analytics
Fixes: 🩹 simple fix, 🥅 catch errors, 👽️ external API changes, 🔥 remove code, 🚑️ hotfix, 💚 CI fix, ✏️ typos, 🔇 remove logs, 🚨 linter warnings, 🔒️ security
Refactoring: 🚚 move/rename, 🏗️ architecture, ⚰️ dead code, 🎨 structure/format
Chore: 🔀 merge, 📦️ packages, ➕ add dep, ➖ remove dep, 🌱 seeds, 🧑💻 DX, 👥 contributors, 🎉 init project, 🔖 release, 📌 pin deps, 👷 CI system, 📄 license, 🙈 gitignore
Docs: 💡 source comments
Testing: 🤡 mocks, 📸 snapshots, 🧪 failing test
UI/Assets: 💫 animations, 🍱 assets
Database: 🗃️ DB changes
Other: ⚗️ experiments, 🚧 WIP
Examples
feat: ✨ add user authentication system
fix(parser): 🐛 resolve memory leak in rendering process
refactor(api): ♻️ simplify error handling logic
feat(api)!: 💥 change authentication endpoint response format
Split example (one diff, four commits):
feat(solc): ✨ add new version type definitions
docs(solc): 📝 update documentation for new versions
chore(deps): 🔧 update package.json dependencies
test(solc): ✅ add unit tests for new version features
More from idjoo/skills
whatsapp
Send and manage WhatsApp messages via WAHA HTTP API. Use when the user wants to send WhatsApp messages (text, image, video, voice, file), read chats/messages, manage contacts, groups, or sessions. Triggers on: 'send a WhatsApp message', 'check my WhatsApp chats', 'send image on WhatsApp', 'WhatsApp group', 'WhatsApp session', or any WhatsApp-related task.
2beads
Local-first issue tracker using br (beads_rust). Use when the user wants to track issues, create tasks, manage dependencies between issues, or check what's ready to work on. Triggers on: 'create an issue', 'track a bug', 'what should I work on next', 'show blocked issues', 'add a dependency', 'beads', 'br', or any project issue-tracking task.
1waha
Send and manage WhatsApp messages via WAHA HTTP API. Use when the user wants to send WhatsApp messages (text, image, video, voice, file), read chats/messages, manage contacts, groups, or sessions. Triggers on: 'send a WhatsApp message', 'check my WhatsApp chats', 'send image on WhatsApp', 'WhatsApp group', 'WhatsApp session', 'WAHA', or any WhatsApp-related task.
1python-backend
Production-ready Python backend service architecture using FastAPI, SQLModel, and async PostgreSQL. Use when: (1) Scaffolding a new backend service or API project, (2) Adding new entities, endpoints, or features to an existing service, (3) Setting up database models, migrations, or repositories, (4) Configuring CI/CD, Docker, or Cloud Run deployment, (5) Reviewing or refactoring backend code for pattern compliance. Triggers on: 'create a new service', 'add an endpoint', 'add a new entity', 'scaffold a project', 'set up a FastAPI project', 'add CRUD', 'create a model', or any Python backend development task.
1