/commit
Create well-formatted commits with conventional commit messages and emoji
Claude Code
$ npx -y skills add NeoLabHQ/context-engineering-kit --skill commit --agent claude-code
Codex
$ npx skills add NeoLabHQ/context-engineering-kit --skill commit -a codex -y
Cursor
$ npx skills add NeoLabHQ/context-engineering-kit --skill commit -a cursor -y
Gemini CLI
$ npx skills add NeoLabHQ/context-engineering-kit --skill commit -a gemini-cli -y
GitHub Copilot
$ npx skills add NeoLabHQ/context-engineering-kit --skill commit -a github-copilot -y
OpenCode
$ npx skills add NeoLabHQ/context-engineering-kit --skill commit -a opencode -y
Windsurf
$ npx skills add NeoLabHQ/context-engineering-kit --skill commit -a windsurf -y
SKILL.md
commit.SKILL.mdname: commit
description: Create well-formatted commits with conventional commit messages and emoji
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
- ๐ `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:
1. **Different concerns**: Changes to unrelated parts of the codebase 2. **Different types of changes**: Mixing features, fixes, refactoring, etc. 3. **File patterns**: Changes to different types of files (e.g., source code vs documentation) 4. **Logical grouping**: Changes that would be easier to understand or review separately 5. **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 pipe
Read more
name: commit description: Create well-formatted commits with conventional commit messages and emoji
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
- ๐ `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:
1. **Different concerns**: Changes to unrelated parts of the codebase 2. **Different types of changes**: Mixing features, fixes, refactoring, etc. 3. **File patterns**: Changes to different types of files (e.g., source code vs documentation) 4. **Logical grouping**: Changes that would be easier to understand or review separately 5. **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 pipe
A hand-crafted collection of advanced context engineering techniques and patterns with minimal token footprint, focused on improving agent result quality and predictability.
Other skills on context-engineering-kit.
add-task
creates draft task file in .specs/tasks/draft/ with original user intent
agent-evaluation
Evaluate and improve Claude Code commands, skills, and agents. Use when testing prompt effectiveness, validating contextโฆ
analyse-problem
Comprehensive A3 one-page problem analysis with root cause and action plan
analyse
Auto-selects best Kaizen method (Gemba Walk, Value Stream, or Muda) for target
analyze-issue
Analyze a GitHub issue and create a detailed technical specification
More skills from other plugins.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, orโฆ
ask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
Questions about commit.
- Which coding agents can use commit?
- commit installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.

