git commit_message自动生成SKILLS

还在为了git 提交时的commit_message而发愁吗？一个Skill搞定
---
name: generate-git-commit
description: 仅当用户明确要求"生成 commit message / 提交信息 / 提交说明 / 提交文案"时使用。基于当前仓库实际改动生成提交信息文本；全程只读，不执行任何修改仓库状态的 git 操作。
---

# 生成 Git 提交信息

根据当前仓库的实际代码变更，生成可直接复制使用的 commit message。**只生成文本，不执行任何修改仓库状态的 git 操作**。

## 触发条件

仅当同时满足以下条件时使用：

1. 用户明确要求生成 commit message / 提交信息 / 提交说明 / 提交文案
2. 当前仓库存在实际改动可供总结

用户表达含糊（如"帮我处理提交""帮我提交""收尾一下"）时不触发本 skill，除非用户明确表示只需要生成提交信息文本。

## 只读约束

**允许**：`git diff`、`git diff --cached`、`git status --short`、`git log`（只读）、读取与理解改动直接相关的项目文件（最小必要原则）。

**禁止**：一切会修改仓库状态的 git 命令，包括但不限于 `add` / `commit` / `push` / `pull` / `checkout` / `switch` / `branch` / `merge` / `rebase` / `reset` / `restore` / `stash`。

## 处理流程

### 第一步：确定 diff 范围（智能分层）

1. 先检查暂存区：`git diff --cached`
2. **暂存区非空 → 只基于暂存区改动生成**。暂存区是用户准备提交的内容，message 必须与它一致，不得混入未暂存改动
3. 暂存区为空 → 基于全部工作区改动：`git diff` + untracked 文件
4. **untracked 新文件在 `git diff` 中不可见**，必须通过 `git status --short` 发现，并读取文件内容判断改动实质，不得忽略

### 第二步：理解改动

必要时读取少量相关项目文件，判断改动所属模块、功能与目的。必须基于实际 diff 生成，不得仅凭对话内容猜测。

注意：此步弄清的文件清单只用于**理解**改动，不进入 message 正文；message 要回答的是"做了什么、行为有什么变化"，而不是"动了哪些文件"（后者 git 历史自带）。

### 第三步：生成提交信息

规则见下。

## 格式规范（统一风格，不跟随仓库历史）

格式为：**`类型(模块): 中文描述`**

- **类型**：`feat` / `fix` / `refactor` / `docs` / `test` / `chore` / `perf` / `style` / `build` / `ci`
- **模块（scope）**：改动能明确归属某个模块/子系统时使用，依据是**文件路径与改动内容**（如改动集中在 `front/src/views/engine/` 下则 scope 为 `engine`）；无法明确判断时整个括号省略
- **描述**：中文，简洁明确，不超过 50 字，反映本次最核心的改动目的；专有名词和约定俗成的技术术语可保留英文
- **只写内容，不写文件**：描述必须总结改动带来的**功能 / 行为 / 配置语义上的变化**，严禁把被改的文件名、目录路径、脚本名当作描述主体（如"更新了 xxx.conf""新增 xxx 目录与 xxx 软链"都属于此类）。判断标准：读者不需要看 diff 也能明白这条提交干了什么事。若某个名字本身就是业务/技术概念（接口名、服务名、协议名、机房/站点简称等），可以保留，但描述的是它所承载的业务动作，而非文件对象本身

**写法对比**（以部署配置改动为例）：

- ❌ `feat(FeedBack): 新增data/mail目录与www/result软链并更新clear.sh`——罗列文件与路径，读者看不出改了什么事
- ✅ `feat(FeedBack): 支持mail业务数据的接收落盘与过期清理`——总结功能内容，文件层面的信息交给 git 历史

**单行优先**：绝大多数情况只输出一行。仅当单行确实无法表达时（一次提交里有多件事、跨多文件重构、行为变更需要说明动机），追加空行 + body：每行不超过 72 字符，说明**为什么改**与影响面，多件事时逐条列出所做事项（写法见"多主题改动"一节），不罗列文件清单（git 历史自带）。

## 多主题改动：一条 message 列全，不建议拆分

一次提交做了 2 件或多件事时（即使各件事主题互不相关），**不要建议拆分提交**，只输出一条 message，把做的事情全部列出来：

- 事项少且表述短：标题用顿号 / 逗号并列，仍受 50 字限制约束
- 事项多或一行放不下：标题写最核心的一件事，空行后在 body 中以 `- ` 开头逐行列出其余各件事，一行一件
- 列出的仍然是"做了什么事"（功能 / 行为 / 配置语义层面的总结），严禁写成文件名、路径、代码片段
- 不附加任何"建议拆分""可按组暂存"之类的操作性提示；仅当用户明确要求拆分时才按用户指示处理

## 输出格式

**裸文本输出**，不使用代码块围栏，不附加解释、命令示例、序号、文件分组标注或前后文。**永远只输出一条 message**（标题行，必要时 + body）。

一行足够时，只输出这一行：

    fix(scanner): 修复扫描器列表分页参数校验缺失

一次提交包含多件事时，全部列在同一条 message 里，例如：

    feat(FeedBack): 支持mail业务数据的接收落盘、web访问与过期清理

    - white_data访问白名单移除shcdt来源，仅保留lycc节点

## 边界情况

- 没有可识别的改动：明确告知用户当前没有足够的实际改动用于生成提交信息，**不得编造**
- 暂存区与工作区同时有改动时，只描述暂存区（见处理流程第一步），不提醒、不扩展

## 成功标准

基于当前仓库的实际 diff，产出准确、可直接复制使用的 commit message 文本：message 以功能/行为语言总结"改了什么内容"，而非罗列改动了哪些文件；无论本次提交做了哪几件事，产出的始终是且仅是一条列全所有事项、可直接复制的 message；全程不执行、不暗示已执行任何修改仓库状态的操作。