Rewrite commit messages to sound like a human engineer
Rewrites commit messages to sound human-written, stripping AI/marketing slop while keeping Conventional Commits format.
Why it matters
Generate or rewrite Git commit messages that follow Conventional Commits format while stripping AI-generated marketing language and template phrases, producing direct, specific messages that explain why changes were made.
Outcomes
What it gets done
Strip marketing slop words like 'comprehensive', 'robust', 'leverage', and 'seamlessly' from commit text
Format subject lines in imperative mood with proper type, scope, and ≤72 character limit
Add body paragraphs only when needed to explain non-obvious context, breaking changes, or security fixes
Remove template prefixes like 'This commit...' and filler adverbs while preserving technical accuracy
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-unslop-commit | bash Overview
Unslop Commit
This skill rewrites or generates commit messages in Conventional Commits format that read like a human engineer wrote them, stripping AI/marketing slop and adding a body only when needed for the why, breaking changes, migrations, or security context. Use it whenever a commit message needs writing or de-slopping - it only outputs the message text, it never runs git commit, stages, or amends anything.
What it does
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.
When to use - and when NOT to
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.
Inputs and outputs
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.
Integrations
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.
Who it's for
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.
Source README
Unslop Commit
When to Use
Use this skill when you need rewrites commit messages so they sound like a careful human engineer wrote them. Strips AI/marketing slop ("comprehensive solution", "robust implementation", "leverage", "enhance", "seamlessly", "This commit..."). Keeps Conventional Commits format. Subject ≤72 chars (aim ≤50),...
Purpose
Generate or rewrite commit messages so they read like a real engineer wrote them at the end of a real day. Conventional Commits format. Direct, specific, no template English. Why over what.
Trigger
/unslop-commit, /commit, "write a commit", "commit message", "humanize this commit", "de-slop this commit". Auto-trigger when the user has staged changes and asks for a commit message.
Rules
Subject line
- Format:
<type>(<scope>): <imperative summary> - Scope optional. Types:
feat,fix,chore,refactor,docs,test,perf,build,ci,revert. - Imperative mood:
add,fix,move,remove- notadded,fixes,fixing. - ≤50 chars when possible. Hard cap 72.
- No trailing period.
- Lowercase after
:unless the project capitalizes.
Body (only when subject can't carry it)
- Add for: non-obvious "why", breaking changes, migrations, security context, data integrity.
- Wrap at 72 chars. Bullets
-for two or more independent points. Single paragraph for one thought. - End with refs:
Closes #42,Refs #17. NoBREAKING CHANGE:unless truly breaking - and then write it.
Never include
- 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
- Restating the filename when scope already names it
- "As requested by..." (use
Co-authored-by:if you need attribution) - AI attribution unless the project requires it
- Emoji unless project convention says so
Auto-clarity (always include body)
- Breaking changes
- Security fixes
- Data migrations
- Reverts (cite the reverted commit)
Examples
Bad → good (slop subject, no body)
- Bad:
feat: implement a comprehensive, robust solution for user profile retrieval with enhanced error handling - Good:
feat(api): return profile fields the mobile client actually needs
Bad → good (vague body)
Bad:
fix: fixed the bug
This commit addresses an issue where the application was not working correctly
in some edge cases. We've improved the logic to handle these scenarios.
Good:
fix(checkout): ignore stale cart id from localStorage
Stale cart ids came from tabs that hadn't refreshed after a deploy. Server
now treats unknown ids as empty cart instead of 500.
Closes #842
Breaking change
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
Boundaries
- Output the message only, in a single fenced block, ready to paste.
- Do not run
git commit, stage, or amend. - If the change is genuinely trivial (
docs(readme): fix typo), keep it trivial. Don't pad. - Never invent context the user didn't provide. If the "why" isn't clear, ask, or omit the body.
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.