litingyes Code Commit
Generate a git commit message following the Conventional Commits 1.0.0 specification for the current repository, then commit it immediately. Ask for confirmation only before staging otherwise unstaged or untracked files.
This skill is manually invoked only. Do not use it unless the user explicitly asks for it or explicitly asks to generate a commit message. If the user just wants general git help, answer without using this skill.
Workflow
Verify the working directory is a git repository.
- If not, tell the user and stop.
Inspect the repository state.
- Run
git status --porcelainto see staged, unstaged, and untracked files. - Run
git diff --cached --statto see the staged change summary. - Run
git diff --statto see the unstaged change summary.
- Run
Handle unstaged/untracked changes.
- If there are any unstaged or untracked files, ask the user with a
questionbefore proceeding:- Stage all changes: run
git add -A(or equivalent) and include them in the commit analysis. - Commit only staged changes: analyze only what is already staged.
- Cancel: stop and do nothing.
- Stage all changes: run
- If the user chooses "Commit only staged changes" and the staging area is empty, tell them there is nothing to commit and stop.
- If there are any unstaged or untracked files, ask the user with a
Analyze the changes.
- Read the full staged diff (
git diff --cached). If the diff is very large, first readgit diff --cached --stat, then read the diffs for the most important files. - Read
git log --oneline -5to infer the project's common scopes and conventions (e.g., whether people usefeat(api):,fix(parser):, etc.). - Commit messages must be written in English regardless of the user's language.
- Read the full staged diff (
Generate the commit message following Conventional Commits 1.0.0.
- The commit message must follow this structure:
<type>[optional scope]: <description> [optional body] [optional footer(s)] - Allowed types (from most common to acceptable):
feat,fix,docs,style,refactor,perf,test,build,ci,chore,revert. Preferfeatorfixwhen they clearly apply. - Scope: optional noun in parentheses describing the affected section, e.g.,
feat(parser):. Infer it from the changed files or the project history. Omit if no clear scope exists. - Description: short summary in the imperative mood, lowercase first letter, no trailing period. Keep it under 72 characters if possible.
- Body: optional. Use it when the change needs explanation of what and why. Leave one blank line between the description and the body.
- Breaking changes: if the change introduces a breaking API change, append
!to the type/scope prefix (e.g.,feat(api)!: ...) and/or add a footer:BREAKING CHANGE: <description>. - Footers: optional. Use git-trailer style, e.g.,
Refs: #123,Closes: #456. Footers must be separated from the body by one blank line.
- The commit message must follow this structure:
Present the final commit message and proceed without confirmation.
- Show the exact message that will be used.
- Do not ask the user whether to commit, whether to edit the message, or whether to cancel.
Commit immediately.
- Use
git commit -m "<subject>" -m "<body>" ...or another safe method to preserve newlines and footers. Avoidgit commit -mwith a single string containing literal newlines unless you can do so safely. - After committing, report the commit hash and short summary.
- Use
Important Notes
- Do not auto-stage changes without user approval.
- If the user cancels during the staging decision, stop immediately and do nothing.
- Do not include irrelevant metadata, signatures, or markdown formatting in the final commit message.
- Prefer
feat:orfix:overchore:when the change clearly introduces a feature or fixes a bug.