tomevault-io 中文提交并按变更拆分
当用户要求创建提交、整理提交、准备 commit、执行 push，或明确提到提交与推送规范时，使用这个 skill。
规则
- 除非用户明确要求其他语言，否则所有 commit message 都使用中文。
- 提交前先检查当前 diff，按变更意图和影响范围分组。
- 差异较大的改动要拆成多个 commit。
- 构建系统、配置、测试、重构、功能修改等不同类型的改动，能分开时就不要混在同一个 commit 里。
- 不要为了拆分而拆分，单个逻辑变更不能被切碎到多个 commit。
- 如果工作区里混有不该一起提交的用户改动，先停下来确认，不要擅自一起提交。
- 用户要求推送时，默认遵循固定流程：
git fetch->git stash->git rebase->git stash pop->git push。 - 如果工作区本来就是干净的，可以跳过
stash和stash pop，但仍然要先fetch再rebase。 stash pop后如果产生冲突，先解决冲突并确认工作区状态，再继续后续操作。
工作流
- 运行
git status --short，并检查相关 diff。 - 按用户可感知的目的、风险和作用范围决定提交边界。
- 每次只暂存一组逻辑相关的改动。
- 为每组改动创建一个中文 commit。
- 全部提交完成后，再次运行
git status --short确认工作区状态。
推送工作流
当用户要求 push、同步远端，或需要把本地提交推到远端时，按下面顺序执行：
- 先运行
git fetch同步远端引用。 - 如果工作区有未提交改动，先
git stash保存现场。 - 基于对应远端分支执行
git rebase。 - 如果前面做过
stash，在 rebase 完成后执行git stash pop。 - 如果
stash pop或 rebase 产生冲突，先解决冲突并确认结果正确。 - 工作区状态确认正常后，再执行
git push。
如果用户明确要求其他流程，再按用户要求执行；否则默认使用这套顺序。
提交信息要求
- 标题保持简洁，通常 8 到 20 个中文字符即可。
- 优先使用表意明确的动词开头，例如：
修复、重构、调整、补充、优化。 - 需要时带上影响范围，例如：
重构 cppOps 算子测试并补充性能基准。 - 不要把多个独立目的写进同一个标题。
向用户汇报时
- 按顺序列出本次创建的 commits。
- 如果拆成多个 commit，简要说明拆分依据。
- 如果有刻意未提交的本地修改，要明确说明。
- 如果执行了 push，简要说明是否经历了
stash、rebase、冲突处理，以及最终推送结果。
Source: ztxz16/fastllm — distributed by TomeVault.