Commit Message

Generate conventional-commit messages in two situations: an ordinary commit of staged changes (Flow A) and a squash merge message for a PR (Flow B). The defining property of this skill is that nothing enters git history unreviewed: every message is shown in chat first, every commit needs an explicit yes, and pushing is never part of the flow.

Hard rules

1. Never commit without an explicit yes. Show the full proposed message in chat, then ask the confirmation question. A yes from an earlier message or an earlier session does not count; when in doubt, ask again.
2. Never push. The skill completes at the local commit (Flow A) or the printed message (Flow B). When the work is done, say so and stop; the user pushes themselves.
3. Commit as the local user. Never pass --author, never override user.name or user.email, and never append Co-Authored-By: or "generated with" trailers of any kind. The commit must be authored by the identity already configured in the local environment.
4. Gate the protected branches. main and master (and the remote's default branch when it is neither) get an extra are-you-sure question before the flow proceeds.
5. No em dashes or en dashes in any generated message. Use a hyphen, comma, colon, or parentheses instead; they render inconsistently across terminals and git tooling.
6. Use AskUserQuestion for every question, so the user gets clickable options. The "Make changes" option loops: apply the requested change, show the message again, ask again, until the user picks yes or no.

Message generation (both flows)

Read references/commit-message-rules.md and apply every rule in it before writing any message. The short version: {type}: {subject} under 50 characters, lowercase, imperative mood; secondary changes go in an optional body; only the types listed in that file are allowed.

Base the message on what the code actually shows, not on what the user casually called the change.