Commit Message

Write one Conventional Commits message describing the staged changes.

This is the demo skill shipped with claude-skill-improver. It exists so you can drive the feedback → eval → patch loop end to end without writing a skill first. It's small on purpose — the point is the loop, not the skill. Delete it once you've pointed the loop at your own skills.

Step 1 — Read the change

Run git diff --staged. If nothing is staged, run git diff and say you're describing unstaged changes. If both are empty, stop and say there's nothing to describe.

Step 2 — Pick the type and scope

Scope is the affected area in lowercase (auth, parser, ci). Omit the scope rather than inventing a vague one like core or misc.

Step 3 — Write the subject

Format: type(scope): summary

• Imperative mood: "add", not "added" or "adds".
• Lowercase after the colon, unless starting with a proper noun.
• No trailing period.
• 72 characters maximum, including the type and scope.
• Describe the effect of the change, not the files touched. fix(auth): reject expired refresh tokens — not fix(auth): update token.ts.

Step 4 — Add a body only when it earns its place

Skip the body when the subject already says everything. Add one when the change needs a why: what was broken, what constraint forced this approach, what the reader would otherwise misread.

Wrap the body at 72 characters. Separate it from the subject with a blank line.

Step 5 — Output

Print the message in a fenced block and nothing else — no preamble, no summary of what you did, no offer to commit unless the user asked you to commit.

Rules

• One commit message per invocation. If the staged diff clearly contains two unrelated changes, say so and suggest how to split the staging, but still produce the single best message for what's staged.
• Never invent a scope or a ticket reference that isn't in the diff or the user's message.
• Never add trailers (Co-Authored-By, Signed-off-by) unless asked.