commit
installsforks
How to install commit?
neolabhq/context-engineering-kit/commit
$npx -y skills add NeoLabHQ/context-engineering-kit --skill commitCreate well-formatted commits with conventional commit messages and emoji
SKILL.md
| 1 | # Claude Command: Commit |
| 2 | |
| 3 | Your job is to create well-formatted commits with conventional commit messages and emoji. |
| 4 | |
| 5 | ## Instructions |
| 6 | |
| 7 | CRITICAL: Perform the following steps exactly as described: |
| 8 | |
| 9 | 1. **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`) |
| 10 | 2. Unless specified with `--no-verify`, automatically runs pre-commit checks like `pnpm lint` or simular depending on the project language. |
| 11 | 3. Checks which files are staged with `git status` |
| 12 | 4. If 0 files are staged, automatically adds all modified and new files with `git add` |
| 13 | 5. Performs a `git diff` to understand what changes are being committed |
| 14 | 6. Analyzes the diff to determine if multiple distinct logical changes are present |
| 15 | 7. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits |
| 16 | 8. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format |
| 17 | |
| 18 | ## Best Practices for Commits |
| 19 | |
| 20 | - **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated |
| 21 | - **Atomic commits**: Each commit should contain related changes that serve a single purpose |
| 22 | - **Split large changes**: If changes touch multiple concerns, split them into separate commits |
| 23 | - **Conventional commit format**: Use the format `<type>: <description>` where type is one of: |
| 24 | - `feat`: A new feature |
| 25 | - `fix`: A bug fix |
| 26 | - `docs`: Documentation changes |
| 27 | - `style`: Code style changes (formatting, etc) |
| 28 | - `refactor`: Code changes that neither fix bugs nor add features |
| 29 | - `perf`: Performance improvements |
| 30 | - `test`: Adding or fixing tests |
| 31 | - `chore`: Changes to the build process, tools, etc. |
| 32 | - **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature") |
| 33 | - **Concise first line**: Keep the first line under 72 characters |
| 34 | - **Emoji**: Each commit type is paired with an appropriate emoji: |
| 35 | - ✨ `feat`: New feature |
| 36 | - 🐛 `fix`: Bug fix |
| 37 | - 📝 `docs`: Documentation |
| 38 | - 💄 `style`: Formatting/style |
| 39 | - ♻️ `refactor`: Code refactoring |
| 40 | - ⚡️ `perf`: Performance improvements |
| 41 | - ✅ `test`: Tests |
| 42 | - 🔧 `chore`: Tooling, configuration |
| 43 | - 🚀 `ci`: CI/CD improvements |
| 44 | - 🗑️ `revert`: Reverting changes |
| 45 | - 🧪 `test`: Add a failing test |
| 46 | - 🚨 `fix`: Fix compiler/linter warnings |
| 47 | - 🔒️ `fix`: Fix security issues |
| 48 | - 👥 `chore`: Add or update contributors |
| 49 | - 🚚 `refactor`: Move or rename resources |
| 50 | - 🏗️ `refactor`: Make architectural changes |
| 51 | - 🔀 `chore`: Merge branches |
| 52 | - 📦️ `chore`: Add or update compiled files or packages |
| 53 | - ➕ `chore`: Add a dependency |
| 54 | - ➖ `chore`: Remove a dependency |
| 55 | - 🌱 `chore`: Add or update seed files |
| 56 | - 🧑💻 `chore`: Improve developer experience |
| 57 | - 🧵 `feat`: Add or update code related to multithreading or concurrency |
| 58 | - 🔍️ `feat`: Improve SEO |
| 59 | - 🏷️ `feat`: Add or update types |
| 60 | - 💬 `feat`: Add or update text and literals |
| 61 | - 🌐 `feat`: Internationalization and localization |
| 62 | - 👔 `feat`: Add or update business logic |
| 63 | - 📱 `feat`: Work on responsive design |
| 64 | - 🚸 `feat`: Improve user experience / usability |
| 65 | - 🩹 `fix`: Simple fix for a non-critical issue |
| 66 | - 🥅 `fix`: Catch errors |
| 67 | - 👽️ `fix`: Update code due to external API changes |
| 68 | - 🔥 `fix`: Remove code or files |
| 69 | - 🎨 `style`: Improve structure/format of the code |
| 70 | - 🚑️ `fix`: Critical hotfix |
| 71 | - 🎉 `chore`: Begin a project |
| 72 | - 🔖 `chore`: Release/Version tags |
| 73 | - 🚧 `wip`: Work in progress |
| 74 | - 💚 `fix`: Fix CI build |
| 75 | - 📌 `chore`: Pin dependencies to specific versions |
| 76 | - 👷 `ci`: Add or update CI build system |
| 77 | - 📈 `feat`: Add or update analytics or tracking code |
| 78 | - ✏️ `fix`: Fix typos |
| 79 | - ⏪️ `revert`: Revert changes |
| 80 | - 📄 `chore`: Add or update license |
| 81 | - 💥 `feat`: Introduce breaking changes |
| 82 | - 🍱 `assets`: Add or update assets |
| 83 | - ♿️ `feat`: Improve accessibility |
| 84 | - 💡 `docs`: Add or update comments in source code |
| 85 | - 🗃️ `db`: Perform database related changes |
| 86 | - 🔊 `feat`: Add or update logs |
| 87 | - 🔇 `fix`: Remove logs |
| 88 | - 🤡 `test`: Mock things |
| 89 | - 🥚 `feat`: Add or update an easter egg |
| 90 | - 🙈 `chore`: Add or update .gitignore file |
| 91 | - 📸 `test`: Add or update snapshots |
| 92 | - ⚗️ `experiment`: Perform experiments |
| 93 | - 🚩 `feat`: Add, update, or remove feature flags |
| 94 | - 💫 `ui`: Add or update animations and transitions |
| 95 | - ⚰️ `refactor`: Remove dead code |
| 96 | - 🦺 `feat`: Add or |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
