Generate conventional commit messages from staged git changes. Use when the user asks to write commit message, generate commit, what should my commit say, or after the user runs git add and wants a commit message for staged files.
Generate a conventional commit message from staged changes only.
1. Run `git status --short`.
2. Determine whether any files are staged by checking the first status column for anything other than a space or `?`.
3. If no files are staged, do not suggest a commit message. Tell the user to stage changes first with `git add <files>` or `git add .`.
4. Run `git diff --cached --stat` to summarize staged file impact.
5. Run `git diff --cached` to inspect the staged patch.
6. Analyze the staged changes and return one primary commit recommendation in conventional commit format, plus optional alternatives if useful.
Use only staged changes. Do not base the commit message on unstaged, untracked, or working-tree-only changes.
```bash
git status --short
git diff --cached --stat
git diff --cached
```
If `git diff --cached` is empty, the correct response is:
```text
No staged changes found. Run `git add <files>` first, then ask me to write the commit message.
```
Use this format:
```text
type(scope): imperative summary
```
Use `type(scope)!: summary` when the staged changes introduce a breaking change.
Keep the summary under 72 characters when practical. Use imperative mood: `add`, `fix`, `update`, `remove`, `refactor`, not `added`, `fixed`, or `updates`.
When multiple types apply, choose the type that best represents the user-visible reason for the commit. Prefer `feat` or `fix` over `chore` when product behavior changes. Prefer `test` only when the commit is primarily test work.
Choose a concise lowercase scope from the most specific shared path or domain:
If staged files share a clear parent directory, use that parent directory name as the scope, such as `auth` for `src/auth/reset.ts`. If no useful scope exists, omit the scope: `chore: update repository metadata`.
For multi-area changes, choose the scope that matches the main intent. If the commit genuinely spans unrelated areas, omit scope or use a broad existing project term such as `core`.
Add `!` after the type or scope when staged changes appear to break downstream callers or users. Treat these as breaking indicators:
Do not mark `!` for internal-only refactors unless there is clear evidence of public contract impact.
Before answering, verify:
Leave a review
No reviews yet. Be the first to review this skill!
# Download SKILL.md from killerskills.ai/api/skills/git-commit-writer-free/raw