Execution Contract

If this skill is triggered, the assistant MUST begin the response with:

=== USING SKILL: git-commit-helper ===

When to Use This Skill

当出现以下任意请求时必须使用本 Skill：

根据 git diff 生成提交消息
按固定模板写 commit message
帮我提交代码
先看 diff，再帮我 commit
用中文生成带 emoji 的 Git 提交信息
压缩提交信息、合并 commit、squash 提交历史

Goal

基于当前工作区的真实差异，输出一条可直接用于 git commit 的中文提交消息，并在用户明确要求提交时，完成安全、最小范围的暂存与提交。

Workflow

Step 1: 先看真实差异，不要凭空写消息

必须按以下顺序检查：

git status --short
若已暂存改动，优先看 git diff --cached --stat 和 git diff --cached
若未暂存，再看 git diff --stat 和 git diff
若只有未跟踪文件，先判断它们是否应被提交

规则：

优先基于“即将提交的内容”生成消息，不要基于猜测
如果同时存在 staged 和 unstaged 改动，默认只描述 staged 内容，除非用户明确要求一并提交
不要把 .DS_Store、Thumbs.db、日志、临时文件等误当成有效业务改动
如果没有有效 diff，不要编造提交消息；应明确说明当前没有可提交内容

Step 2: 判断提交类型

只能使用以下类型：

✨ feat: 新功能、新能力、新接口、新流程
🐛 fix: Bug 修复、错误修正、异常处理补丁
📝 docs: 文档、说明、注释性内容更新
💄 style: 纯格式调整、排版、lint 修复、无逻辑变化
♻️ refactor: 重构、提炼结构、调整实现但不改行为
⚡ perf: 性能优化、查询优化、减少开销
✅ test: 测试新增或测试更新
🔧 chore: 配置、依赖、脚本、忽略规则、工程杂项

判定原则：

看主要改动目的，不要机械按文件类型分类
多类改动混合时，选择本次提交的主导类型
仅当行为不变时才用 ♻️ refactor: 或 💄 style:
忽略规则、脚本、CI、依赖、目录整理通常归为 🔧 chore:

Step 3: 生成提交消息

输出格式必须严格如下：

<emoji> <type>: <标题>

<详细描述>

生成规则：

标题必须简洁，50 字符内
标题只写本次提交最核心的变化
详细描述使用简体中文，2-3 句
详细描述要概括“改了什么”和“为什么要这样改”
用户只要求“生成提交消息”时，只输出提交消息本身，不要追加解释

Step 4: 用户明确要求提交时再执行 commit

只有当用户明确要求“提交”“commit”“直接帮我提交”时，才执行以下动作：

再次确认 git status --short
只暂存本次需求相关文件
使用刚生成的提交消息执行非交互式 git commit

执行要求：

默认不要顺手提交无关改动
如果工作区里存在明显无关或可疑文件，先排除，再提交相关文件
不要使用交互式 git 命令
优先使用多段 -m 参数完成提交，避免打开编辑器

示例：

git add path/to/file1 path/to/file2
git commit -m "📝 docs: 补充提交消息生成 skill" -m "新增基于 git diff 生成中文提交消息的执行规范。补充提交类型判断与安全提交流程，避免误提交无关文件。"

Step 5: 用户提到压缩提交信息时，先提交再 squash

当用户明确提到以下任一意图时，必须进入本步骤：

压缩提交信息
合并所有 commit
squash 提交历史
把多个 commit 压成一条

执行顺序必须固定：

先按 Step 4 提交本次内容，确保当前改动先形成一个独立 commit
基于本次改动主题创建一个新分支
在新分支上把目标范围内的 commit 压缩成一条
为压缩后的单条 commit 重新生成符合本 Skill 规范的提交消息
最后把新分支名和最终提交消息输出给用户

分支命名规则：

必须基于原分支名创建新分支，格式为：<原分支名>_<版本数>
版本数 使用递增整数，从 1 开始；如果 _1 已存在，则继续尝试 _2、_3
不要额外添加 codex/ 前缀，也不要改写原分支主体名称
原分支名保持可识别、可追溯，避免使用时间戳或无意义随机后缀
示例：
- 当前分支为 feature/git-commit-helper，则新分支可为 feature/git-commit-helper_1
- 如果 feature/git-commit-helper_1 已存在，则使用 feature/git-commit-helper_2

执行约束：

不要在原分支直接改写历史；压缩历史必须在新分支完成
如果目标提交范围不明确，默认压缩“当前分支上与本次任务直接相关的 commit”
压缩后只保留一条最终 commit，不保留中间整理提交
如果仓库存在无关未提交改动，先排除，不要混入 squash 结果

Output Rules

仅生成提交消息时

只允许输出提交消息本身，例如：

🔧 chore: 忽略系统缓存文件

补充仓库忽略规则，避免 macOS 自动生成的缓存文件进入版本控制。
减少无意义的工作区噪音，确保后续提交内容更干净、更可维护。

需要实际提交时

执行 git 操作后，回复中至少应包含：

实际使用的提交标题
已提交还是未提交
若未提交，明确阻塞原因

涉及 squash 时

执行完成后，回复中至少应包含：

新分支名
压缩后的最终提交标题
压缩后的最终详细描述
已完成 squash 还是被什么问题阻塞

Constraints

不要在没有读取 diff 的情况下直接写提交消息
不要把不确定的改动说成确定目的
不要为了凑类型而夸大改动价值
不要提交明显无关的临时文件或系统文件
如果 diff 为空，必须明确说明“当前没有可生成的有效提交内容”
如果涉及压缩提交历史，必须先提交当前内容，再在新分支上 squash

Checklist

已读取 git status 和对应 diff
已按规则选择唯一类型
标题在 50 字符内
详细描述为 2-3 句中文
若用户要求提交，已仅暂存相关文件并非交互式提交
若用户要求 squash，已先提交当前内容，再在新分支压缩为单条 commit

git-commit-helper