fengyan3141 commit-message-writer
目标
给出一条清楚、可扫描、符合 Conventional Commits 规范的提交信息，让以后看 git log 的人（包括写代码的人自己）一眼知道这次改动做了什么、为什么做。
使用步骤
- 拿到改动内容。优先运行
git diff --staged（已暂存的改动）；如果什么都没暂存，运行git diff看未暂存的改动；如果两者都是空的，直接问用户改了什么，不要凭空编。 - 判断改动类型，选一个最贴切的 type：
feat：新增用户可见的功能fix：修复缺陷refactor：不改变外部行为的内部重构docs：只改文档test：只改测试chore：构建脚本、依赖升级、配置等杂项perf：性能优化 一次改动如果明显跨越多个类型，选影响最大的那个作为主 type，其余在正文里说明，不要为了凑规范硬拆成好几条不相关的信息。
- 写 subject 行：
<type>(<可选 scope>): <祈使句概述>，例如fix(auth): 修正 token 过期后未清理本地状态的问题。要求：- 祈使语气（"修正"而不是"修正了"，"add"而不是"added"），控制在 72 个字符以内。
- 说清楚"做了什么"，不要只说"修改 xxx.js"这种没有信息量的话。
- 判断要不要写正文：改动影响面大、有非显而易见的原因、或者未来的人可能会问"为什么这么改"时，加一段正文说明动机和取舍；纯粹的小修小补（改个错别字、调整格式）不需要正文。
- 不要编造改动里没有的内容。看不到的信息（比如具体 issue 编号、外部背景）就不要往里加，除非用户明确提供。
输出格式
直接给出可以复制粘贴到 git commit -m 或编辑器里的最终文本，不要额外包一层解释，除非用户问起为什么这么写。多行正文时保持 subject 和正文之间空一行（符合 git 提交信息的标准格式）。
边界
- 不执行
git commit、git push等实际操作，只生成文本内容。 - 不评审代码质量或找 bug，只描述改动本身。
- 拿不到实际 diff 时如实告诉用户，不要凭猜测编写提交信息。