SKILL.md
中文规范化提交信息助手#
把一次改动（diff、工作记录或口述）整理成规范 Git 提交信息。纯指令技能：不带脚本、不联网、不写任何文件，产出为可直接使用的提交信息文本。
输出结构#
<type>(<scope>): <主题>
<正文：为什么改、改了什么、影响面>
<脚注：BREAKING CHANGE / 关联工单>
type 选择表（按第一个匹配项选）#
| type | 用途 | 判断问题 | | feat | 新功能 | 用户能感知到新能力吗？ | | fix | 修缺陷 | 这是让错误的行为变正确吗？ | | perf | 性能优化 | 行为不变、只变快或变省吗？ | | refactor | 重构 | 既不加功能也不修缺陷吗？ | | test | 测试 | 只动测试代码吗？ | | docs | 文档 | 只动文档吗？ | | chore | 构建与工具 | 只动构建、依赖、配置吗？ | | ci | 持续集成 | 只动流水线配置吗？ | | revert | 回滚 | 是撤销某次提交吗？ |
规则#
- scope：受影响的模块名，小写；拿不准就不写；
- 主题行：祈使语气，结尾不加句号，全行不超过 50 字符；写结果不写过程，如「登录接口改用长连接」而不是「对登录问题做了一些处理」；
- 正文：回答为什么改、影响哪里、有什么风险；每行不超过 72 字符；没有值得说的就不写正文；
- 破坏性变更：正文开头写
BREAKING CHANGE:并附迁移方法； - 一个提交只做一件事：整理时发现功能与格式化混装，先建议拆分再分别生成。
正反例#
- 好：
fix(auth): 修复刷新令牌过期后静默登出 - 坏：
修改了一些bug（无类型、无范围、无信息量） - 坏：
feat: 新功能以及修复bug和更新依赖（一次提交混装多件事）
工作流程#
- 读 diff 或听口述，判断 type 与 scope；
- 写主题行，检查长度与语气；
- 正文回答三个问题：为什么改？影响哪里？有什么风险？
- 有破坏性变更或关联工单时补脚注；
- 输出最终文本，并附一句「为什么选这个 type」的解释。
用途与依赖
作者没写，这些是平台读文件后整理的，以文件为准。
使用示例
请求：帮我把这次改动写成提交信息：刷新令牌过期后用户会被直接踢回登录页，没有任何提示。我在 src/auth/token.ts 里加了过期前的静默刷新，并补了对应测试。
预期
输出： fix(auth): 修复刷新令牌过期后静默登出 原逻辑在访问令牌过期后直接清除会话并跳转登录页，用户正在编辑的内容会丢失。本次在过期前触发静默刷新，刷新失败时才回落到登出流程；影响 auth 模块的令牌获取路径，需注意并发请求下的重复刷新问题。 为什么选这个 type：这是把错误的行为（无提示踢出）改为正确行为，符合 fix 的判断问题；scope 取受影响模块 auth。 补充提示：改动中包含新测试代码，若测试与修复希望分开提交，可再生成一条 test(auth): 补充令牌静默刷新用例。
- 适用场景
- 写完一段代码，需要一条规范的中文提交信息
- 手上的 diff 或改动记录比较零散，想整理成一条清晰的提交说明
- 不确定某次改动该用 feat、fix、refactor 还是 chore
- 提交信息写得含糊（如「修改了一些bug」），想改成有信息量的表述
- 改动里含破坏性变更或关联工单，需要写 BREAKING CHANGE 与脚注
- 一次改动混合了功能、格式化、依赖更新，想先拆分再分别生成提交信息
- 团队要求统一提交信息格式，需要按规范改写
- 输入
- 改动的 diff、工作记录或口头描述
- 受影响的模块或范围（用于 scope，拿不准可不提供）
- 是否存在破坏性变更及迁移方式
- 关联的工单或 issue 编号（可选）
- 是否希望把混装的多件事拆成多次提交
- 输出
- 一条完整的规范提交信息（主题行、正文、脚注）
- 所选 type 及一句选择理由
- 需要拆分提交时的拆分建议
- 按需改写后的其他候选提交信息
- 运行环境
- 未说明
- 依赖
- 无
