Commit
Automate conventional, emoji-prefixed git commits with branch safety checks and optional pre-commit lint before you open a PR.
Overview
Commit is an agent skill most often used in Ship (also Build) that creates conventional-commit messages with emoji, enforces branch rules on main/master, and runs optional pre-commit lint before recording git commits.
Install
npx skills add https://github.com/neolabhq/context-engineering-kit --skill commitWhat is this skill?
- Blocks or redirects commits on main/master and can create type/username/description branches on demand
- Runs project lint (pnpm/npm/yarn/bun) unless --no-verify is passed
- Auto-stages when nothing is staged, diffs changes, and suggests splitting mixed logical changes
- Formats messages as conventional commits with emoji per project norms
- Uses scoped git and lint bash tools only
- 8-step commit procedure including branch check, lint, stage, diff, and split suggestion
Adoption & trust: 537 installs on skills.sh; 1.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have local changes but no consistent branch discipline, lint gate, or commit messages that explain what actually changed.
Who is it for?
Solo builders who commit frequently from Claude Code or similar agents and want Superpowers-style hygiene without memorizing commit templates.
Skip if: Repos that forbid agent-driven git writes, teams that require signed commits only via CI, or workflows where every commit must be manually authored without auto-staging.
When should I use this skill?
You want the agent to record staged work as formatted conventional commits with optional verification.
What do I get? / Deliverables
You get one or more well-scoped, conventional commits on an appropriate branch, with lint verified when enabled, ready for push and PR review.
- One or more git commits with conventional messages and emoji
- Optional new branch following type/username/description
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Commits sit at the handoff from implementation to reviewable changes, so the canonical shelf is Ship where you polish changes before merge and release. Review is where diff quality, message clarity, and commit granularity matter most for solo builders doing self-review or preparing for collaborators.
Where it fits
After implementing an API change, run commit so the message is feat(scope) with emoji instead of a vague WIP.
Before opening a PR, split a diff that mixes refactor and feature into two conventional commits the reviewer can skim.
Hotfix on a branch with lint still passing so production cherry-picks have traceable conventional titles.
How it compares
Use instead of ad-hoc “git commit -m fix” chat turns when you want enforced conventional format and split-commit suggestions.
Common Questions / FAQ
Who is commit for?
Indie and solo developers using AI coding agents who want readable git history and safer commits off default branches.
When should I use commit?
After you finish a slice of work in Build, before you push or open a PR in Ship review, or whenever you need lint-checked conventional commits with emoji.
Is commit safe to install?
It runs git and optional lint commands on your machine; review the Security Audits panel on this page and confirm branch and hook policies match your team rules.
SKILL.md
READMESKILL.md - Commit
# 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: 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`) 2. Unless specified with `--no-verify`, automatically runs pre-commit checks like `pnpm lint` or simular depending on the project language. 3. Checks which files are staged with `git status` 4. If 0 files are staged, automatically adds all modified and new files with `git add` 5. Performs a `git diff` to understand what changes are being committed 6. Analyzes the diff to determine if multiple distinct logical changes are present 7. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits 8. 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 - 🎉 `ch