- name
- git-commit
- description
- Use this skill when the user wants to make a Git commit or split changes into more than one commit. Also use it when the user types "/commit" or asks for a conventional commit. The skill examines the diff, stages the related files, writes a Conventional Commits message, and runs git commit. Do not use it when the user wants only a commit message and no commit. Do not use it to push, open a pull request, rebase, or change the commit history.
- license
- MIT
- compatibility
- Requires Git. The `--resolved` option of `git add` requires Git 2.56 or later.
- allowed-tools
- shell(git:*)
Git Commit with Conventional Commits
Make Git commits that follow the Conventional Commits 1.0.0 specification. Get the type, the scope, and the summary from the diff.
Message Format
<type>(<scope>): <summary>
<body>
<footer>
- The scope, the body, and the footer are optional. Without a scope, write
<type>: <summary>. - Write the summary in the imperative mood: "add", not "added" or "adds".
- Keep the first line at 72 characters or less. Do not put a period at the end.
- In the body, tell what changed and why.
- Write each footer as
Token: valueorToken #value, for exampleRefs: #456orCloses #123. Conventional Commits accepts the two forms, but Git reads onlyToken: valueas a trailer. In a token, use-in place of a space.
Types
Conventional Commits defines only feat and fix. The other types come from the Angular convention (@commitlint/config-conventional). If the repository has its own list, use that list.