Rewrite commit messages to sound like a human engineer

Rewrites or generates commit messages so they read like a real engineer wrote them at the end of a real day - Conventional Commits format, direct and specific, explaining why over what, with AI/marketing slop stripped out. Triggers on /unslop-commit, /commit, "write a commit message," "humanize this commit," "de-slop this commit," or automatically when the user has staged changes and asks for a commit message.

Subject line rules: <type>(<scope>): <imperative summary>, scope optional, using one of feat, fix, chore, refactor, docs, test, perf, build, ci, revert; imperative mood (add, fix, move, remove, not added/fixes/fixing); 50 chars or fewer when possible, a hard cap of 72; no trailing period; lowercase after the colon unless the project capitalizes. A body is added only when the subject can't carry it - for a non-obvious "why," breaking changes, migrations, security context, or data integrity - wrapped at 72 chars, using - bullets for two or more independent points or a single paragraph for one thought, ending with refs like Closes #42 or Refs #17, and a BREAKING CHANGE: footer only when the change is truly breaking. A body is always required for breaking changes, security fixes, data migrations, and reverts (which must cite the reverted commit).

It never includes template prefixes ("This commit...", "This change...", "We are...", "I have..."), marketing verbs (comprehensive, robust, enhance, leverage, seamless, holistic), filler adverbs (just, really, basically, simply, actually), a restated filename when the scope already names it, "As requested by..." attribution (using Co-authored-by: instead if needed), AI attribution unless the project requires it, or emoji unless project convention calls for it.

feat(api)!: rename /v1/orders to /v1/customer-orders

The old route stays in place until the next major release but logs a
deprecation warning. Internal services have been migrated.

BREAKING CHANGE: third-party integrations using /v1/orders directly need
to switch to /v1/customer-orders by 2026-07-01.

Closes #1290

If the change is genuinely trivial (e.g. docs(readme): fix typo), the message stays trivial rather than being padded with an unneeded body. It never invents context the user didn't provide - if the "why" isn't clear, it asks or omits the body rather than fabricating a rationale.

Use it whenever you need a commit message written or an existing slop-filled one rewritten to sound like a specific, human-written explanation rather than AI-generated boilerplate. It only outputs the message text in a single fenced block, ready to paste - it never runs git commit, stages, or amends anything itself.

Input is staged changes (or a description of them) and, optionally, a draft commit message to de-slop. Output is a single Conventional-Commits-formatted message in a fenced code block - subject line only for simple changes, subject plus body for changes needing a "why," breaking-change note, or issue reference.

Follows the Conventional Commits specification (feat, fix, chore, etc., plus BREAKING CHANGE: footers and Closes/Refs issue references) and defers to Co-authored-by: trailers for attribution instead of prose credit lines.

Developers who want commit messages that read as specific and human rather than AI-generated boilerplate, without having to manually strip marketing language and template phrasing from every commit themselves.