用途：生成或改写提交信息，使其符合 Conventional Commits 格式，风格直接、具体，强调"为什么"而非"做了什么"，读起来像真实工程师在一天工作结束时写下的记录。
主要能力：按 <type>(<scope>): <imperative summary> 格式写标题行，scope 可选，type 支持 feat、fix、chore、refactor、docs、test、perf、build、ci、revert；使用祈使语气（add、fix、move、remove，而非 added、fixes）；标题尽量不超过 50 字符，硬上限 72，不加句末句号，冒号后小写（除非项目习惯大写）。正文仅在标题无法承载时添加，用于非显而易见的"why"、破坏性变更、迁移、安全上下文、数据完整性；正文按 72 字符换行，两个及以上独立要点用 - 列表，单一思路用单段落，结尾写 Closes #42、Refs #17 等引用。破坏性变更、安全修复、数据迁移、回滚（需引用被回滚的提交）始终附带正文。
禁用内容：模板式前缀（"This commit...""This change...""We are...""I have..."）、营销动词（comprehensive、robust、enhance、leverage、seamless、holistic）、填充副词（just、really、basically、simply、actually）、scope 已含文件名时的重复、"As requested by..."（需要署名时用 Co-authored-by:）、项目未要求时的 AI 署名、项目约定外的 emoji。除非真正破坏性，否则不用 BREAKING CHANGE:，若使用则明确写出。
使用方式：触发命令为 /unslop-commit、/commit，或"write a commit""commit message""humanize this commit""de-slop this commit"等表述；当用户已有暂存改动并索要提交信息时自动触发。输出仅包含消息本身，放在单个代码块中，可直接粘贴。
限制：不运行 git commit、不执行暂存或 amend；对确实琐碎的改动（如 docs(readme): fix typo）保持简短，不刻意凑内容；不编造用户未提供的上下文，若"why"不明确应询问或省略正文。资料未提供该技能的安装命令、收费与平台信息。