用途：生成或重写 Git 提交信息，使其读起来像真实工程师在一天工作结束时写的，采用 Conventional Commits 格式，直接、具体、不用模板英语，重点写“为什么”而非“做了什么”。
触发：/unslop-commit、/commit，或“write a commit”“commit message”“humanize this commit”“de-slop this commit”。当用户已有暂存改动并请求提交信息时可自动触发。
主要规则：主题行格式为 <type>(<scope>): <imperative summary>，scope 可选，type 可用 feat、fix、chore、refactor、docs、test、perf、build、ci、revert；使用祈使语气（add、fix、move、remove，而非 added、fixes、fixing）；尽量不超过 50 字符，硬上限 72；结尾不加句号；冒号后小写（除非项目习惯大写）。正文仅在主题行无法承载时添加，用于非显然的“为什么”、破坏性变更、迁移、安全上下文、数据完整性；正文 72 字符换行，两个及以上独立要点用 - 列表，单一想法用一段话，结尾写引用如 Closes #42、Refs #17；除非真正破坏兼容才写 BREAKING CHANGE。禁止包含：模板式开头（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。破坏性变更、安全修复、数据迁移、回滚（需引用被回滚的提交）必须包含正文。
边界：只输出提交信息，放在单个代码块中，便于粘贴；不运行 git commit、不暂存、不 amend；真正琐碎的改动保持琐碎，不凑字数；不编造用户未提供的上下文，若“为什么”不清楚则询问或省略正文。
适用场景：需要规范且自然的提交记录、去除 AI 腔调、统一团队提交风格。限制：不执行 Git 操作，不虚构上下文，格式规则固定；其余如安装方式、价格、平台等资料暂未提供。