| name | write-commit-message |
| description | Show a ready-to-use commit message for the current changes in flutter_ilib in chat, matching this repo's commit style. Reads the diff and prints the message for the user to copy — it NEVER runs git commit or stages anything. Use when the user wants to see the commit message for changes they will commit themselves. Triggers: "write a commit message", "show me the commit message", "commit message for this", "what should the commit say". |
Write a commit message
Show a ready-to-use commit message for the pending changes so the user can commit
it themselves. This skill only prints the message to chat — it never commits,
stages, or pushes. Performing the commit is entirely the user's action and is
out of scope for this skill.
Procedure
1. Read what changed
git status
git diff --staged
git diff
If both staged and unstaged changes exist, ask which set the commit should cover
(or suggest staging the intended files first). Describe only what the commit will
actually include — never describe changes that won't be in it.
2. Write the message
Follow doc/development.md § Commit Message Format:
type(scope): description
- Detail 1
- Detail 2
fixes: #issue # only if it closes an issue
- Types: feat, fix, refactor, test, docs, chore
- Scope: the area touched —
locale, datefmt, calendar, numfmt,
durationfmt, timezone, test, docs, … (omit if it spans many)
- Subject: imperative mood, lower-case, no trailing period, ≤ ~72 chars
- Body: bullet points for the what/why, only when the subject isn't enough.
Small mechanical changes need no body.
- Write it in English (repo convention); explain to the user in the
conversation language.
Match the surrounding history — skim git log --oneline -15 for the prevailing
style before drafting.
3. Output to chat
Present the message in a code block so the user can copy it. If the change is
better split into more than one commit (unrelated concerns mixed), say so and
propose the split instead of forcing one message.
Do not run git add, git commit, or git push — this skill ends at
showing the message. The user takes it from there.
Do not append a Co-Authored-By: Claude trailer — this repo's history does
not use it (the standard harness default is overridden here to match convention).
Critical rules
- Committing is out of scope — only print the message; never
git add/commit/push.
- Describe only the changes the commit will include (staged vs unstaged).
- Conventional-Commits type/scope, English, imperative subject.
Checklist
