| name | commit |
| description | Use this skill when an agent needs to prepare a focused commit, follow repository commit-message conventions, write a clear commit message, and create the git commit cleanly. |
Commit Skill
Use this skill when the work is already implemented and the next step is to create a clean git commit.
Goals
- Keep the commit scoped to the intended change
- Write a concise, descriptive commit message
- Avoid including unrelated modified files
Workflow
- Inspect the working tree before committing.
- Confirm which files belong to the requested change.
- Detect the repository's commit-message rules and style.
- Stage only the relevant files.
- Write a commit message that follows the detected style and summarizes the
user-visible change.
- Create the commit without rewriting unrelated history.
Commit Message Style
Before writing the message, check for explicit rules in repository instructions
such as AGENTS.md, CONTRIBUTING.md, README.md, pull request templates,
package scripts, or commitlint configuration. Explicit project or user rules
override history.
If no explicit rule exists, inspect recent commits:
git log --format=%s -n 20
git log --format=%B -n 5
Use the dominant style from relevant recent history:
- Conventional commits: use
type(scope): subject or type: subject when
recent history uses prefixes such as feat:, fix:, docs:, chore:,
ci:, refactor:, or scoped variants.
- Simple subjects: use a concise imperative subject such as
Update skill validation workflow when history uses plain sentence-style
commit subjects.
- Multiline commits: include a blank line and body when recent non-merge
commits commonly include bodies, when the change needs context, or when the
user asks for references/explanations. Keep the subject aligned with the
detected subject style.
- Mixed history: prefer the style used by recent commits touching the same
area. Do not imitate merge commits.
Guidelines
- Respect what the user already staged: inspect
git diff --cached before staging anything, treat pre-staged content as intentional, and do not unstage it unless it clearly does not belong to the requested change — call that out instead.
- If a pre-commit hook fails, fix the reported problem and retry the commit. If a hook rewrites files, restage only the hook-modified files and commit again. Do not bypass hooks with
--no-verify unless the user explicitly asks.
- Do not stage unrelated files just to make the tree clean.
- Prefer one focused commit over a mixed commit.
- Use imperative subjects unless the repository's explicit rules or dominant
history use another style.
- If the tree contains unexpected changes, call them out before committing.
- Do not amend existing commits unless explicitly requested.
