name	summarize-changes
description	总结当前代码更改的范围、动机和内容，生成结构化的 commit message 或变更摘要

summarize-changes — 代码更改总结

分析当前 Git 工作区的变更（diff），理解修改了什么、为什么修改，生成规范的 commit message 或变更摘要。

触发方式

/summarize-changes [--staged]

不带参数：自动从 git diff（工作区 + 暂存区所有未提交的变更）获取变更内容。
--staged：只总结暂存区（staged）中的变更，从 git diff --cached 获取内容。

执行流程

安全检查（仅默认模式，--staged 模式跳过此步骤）：
- 运行 .omp/skills/summarize-changes/check-changes.sh 获取工作区全貌：
  - 该脚本一次性输出暂存区、未暂存、未跟踪三类文件的状态报告，并以退出码表示结论：
    - 退出码 0（无未暂存/未跟踪文件）：将脚本输出展示给用户后直接进入步骤 1，无需询问。
    - 退出码 1（存在未暂存或未跟踪文件）：将脚本输出展示给用户，然后通过 ask 工具询问：
      
      检测到工作区存在未暂存或未跟踪的文件。当前默认模式将生成【所有本地变更】（含已暂存 + 未暂存）的摘要。是否继续？
      - 选项 1：”继续，生成所有本地变更摘要” — 保持默认行为，汇总全部未提交变更。
      - 选项 2：”切换为 --staged 模式” — 仅汇总已暂存的变更，忽略未暂存文件。
      - 选项 3：”中止” — 取消本次操作。
      - 若用户选择选项 2，后续步骤按 --staged 模式执行。
收集变更信息：
- 根据最终确定的模式（用户原始参数，或步骤 0 中用户选择的覆盖模式）确定变更范围：
  - 默认模式：总结所有未提交的本地变更。必须运行 git diff HEAD --stat 和 git diff HEAD 获取内容。
  - --staged 模式：只总结暂存区中的变更。必须运行 git diff --cached --stat 和 git diff --cached 获取内容。
容量检测：
- 根据最终确定的模式运行对应的 stat 命令查看变更文件数：
  - 默认模式：运行 git diff HEAD --stat
  - --staged 模式：运行 git diff --cached --stat
- 若输出中的变更文件 > 15 个，禁止逐一文件详解，改为按变更目的分组（如"依赖升级"、"日志格式调整"、"错误处理增强"），每组概括影响的核心文件数量即可，不展开具体代码行。
单文件上下文限制：
- 在阅读具体 diff 之前，先扫描 git diff 输出的变更行数（+++ 和 --- 的总行数）。
- 若某个文件的变更块（hunk）上下文超过 200 行，或变更总行数（+++ 与 --- 之和）超过 500 行：
  - 禁止使用 Read 工具读取该文件的完整内容。
  - 强制仅基于 git diff 中展示的变更片段（变更块及其周围 3-5 行上下文）进行分析。
  - 目的：防止单个超大类或重构文件撑爆上下文窗口。
理解改动：
- 逐一阅读每个变更文件的 diff，理解：
  - 改了什么文件、什么函数/模块。
  - 改动的具体内容（新增、删除、修改）。
  - 改动的目的（修复 bug、重构、新增功能、升级适配等）。
- 如果 diff 涉及不熟悉的代码区域，快速读取附近文件的上下文确认。
- 注意：diff 中的行号是行号。Read 工具的输出格式为 <line-number>\t<line-content>，两者视觉上易于混淆，务必注意区分。
- 不可以执行写操作的命令（如 git add、git commit 等），只可执行读操作的命令用于分析和总结。
分析根因（如果是修复类变更）：
- 如果是修复类变更（修复 panic/错误/异常），从 diff 反推发生了什么错误，确认修复是否完整。
生成 commit message：
- 格式遵循 Conventional Commits 2.1.0 规范：
```
<type>(<scope>): <用一句用户视角的话，描述提交后的最终效果或影响>

<正文留空一行>
**🤔 背景与动机 (Why)**
- 当前存在什么问题？
- 用户/系统的痛点是什么？

**✨ 解决方案与影响 (What & Impact)**
- 本次变更的核心逻辑/决策是什么？（高阶描述，非代码diff）
- 带来了哪些性能/体验上的变化？（如有数据请附上）
```
- type: fix / feat / chore / refactor / docs / style / perf / test / ci / build / revert
- scope: 模块名或目录名，如 plugin-system / cli_server / config / sdk
- 第一行不超过 72 字符
- 使用中文 body 说明背景和动机，输出的所有内容中不可以存在'"'双引号，避免 commit message 解析错误。
- Scope 推导规则（硬性约束）：
  1. 取变更文件数量最多的顶级目录作为 Scope（如 src/tauri/ 变更最多，取 tauri）。
  2. 若变更文件均匀分布在 3 个及以上互不相关的目录，省略 Scope（即 fix: xxx）。
  3. 禁止生成组合型 Scope（如 core/ui 或 core+ui）。
输出结果：
- 展示最终的 commit message 给用户。
- 不执行 git commit，只输出内容。

输出示例

fix(cli_server): 将 axum 路由参数从 `:param` 语法迁移到 `{param}` 语法

**🤔 背景与动机 (Why)**
- 项目依赖的 axum 从 0.7 升级到 0.8 后，路径参数语法从 `:param` 变更为 `{param}`。
- 旧语法导致 CLI HTTP 服务器启动时 panic，所有含参数的路由不可用。

**✨ 解决方案与影响 (What & Impact)**
- 将 server.rs 中 11 处路由定义从 `/:param` 全部替换为 `/{param}`。
- 变更后服务器正常启动，`/v1/config/{id}/` 和 `/v1/plugins/{id}/` 路由恢复可用。

注意事项

专注总结变更，不继续扩展新改动。
diff 里的文件内容不要直接复制到 commit message 中，而是概括性质和范围。
如果变更涉及外部依赖版本变更（如 crate 升级），在 commit body 里注明原因。
对于大型变更，按文件或模块分组描述。

summarize-changes — 代码更改总结

分析当前 Git 工作区的变更（diff），理解修改了什么、为什么修改，生成规范的 commit message 或变更摘要。

触发方式

/summarize-changes [--staged]

不带参数：自动从 git diff（工作区 + 暂存区所有未提交的变更）获取变更内容。

--staged：只总结暂存区（staged）中的变更，从 git diff --cached 获取内容。

执行流程

安全检查（仅默认模式，--staged 模式跳过此步骤）：

运行 .omp/skills/summarize-changes/check-changes.sh 获取工作区全貌：
- 该脚本一次性输出暂存区、未暂存、未跟踪三类文件的状态报告，并以退出码表示结论：
  - 退出码 0（无未暂存/未跟踪文件）：将脚本输出展示给用户后直接进入步骤 1，无需询问。
  - 退出码 1（存在未暂存或未跟踪文件）：将脚本输出展示给用户，然后通过 ask 工具询问：
    
    检测到工作区存在未暂存或未跟踪的文件。当前默认模式将生成【所有本地变更】（含已暂存 + 未暂存）的摘要。是否继续？
    - 选项 1：”继续，生成所有本地变更摘要” — 保持默认行为，汇总全部未提交变更。
    - 选项 2：”切换为 --staged 模式” — 仅汇总已暂存的变更，忽略未暂存文件。
    - 选项 3：”中止” — 取消本次操作。
    - 若用户选择选项 2，后续步骤按 --staged 模式执行。

收集变更信息：

根据最终确定的模式（用户原始参数，或步骤 0 中用户选择的覆盖模式）确定变更范围：
- 默认模式：总结所有未提交的本地变更。必须运行 git diff HEAD --stat 和 git diff HEAD 获取内容。
- --staged 模式：只总结暂存区中的变更。必须运行 git diff --cached --stat 和 git diff --cached 获取内容。

容量检测：

根据最终确定的模式运行对应的 stat 命令查看变更文件数：
- 默认模式：运行 git diff HEAD --stat
- --staged 模式：运行 git diff --cached --stat
若输出中的变更文件 > 15 个，禁止逐一文件详解，改为按变更目的分组（如"依赖升级"、"日志格式调整"、"错误处理增强"），每组概括影响的核心文件数量即可，不展开具体代码行。

单文件上下文限制：

在阅读具体 diff 之前，先扫描 git diff 输出的变更行数（+++ 和 --- 的总行数）。
若某个文件的变更块（hunk）上下文超过 200 行，或变更总行数（+++ 与 --- 之和）超过 500 行：
- 禁止使用 Read 工具读取该文件的完整内容。
- 强制仅基于 git diff 中展示的变更片段（变更块及其周围 3-5 行上下文）进行分析。
- 目的：防止单个超大类或重构文件撑爆上下文窗口。

理解改动：

逐一阅读每个变更文件的 diff，理解：
- 改了什么文件、什么函数/模块。
- 改动的具体内容（新增、删除、修改）。
- 改动的目的（修复 bug、重构、新增功能、升级适配等）。
如果 diff 涉及不熟悉的代码区域，快速读取附近文件的上下文确认。
注意：diff 中的行号是行号。Read 工具的输出格式为 <line-number>\t<line-content>，两者视觉上易于混淆，务必注意区分。
不可以执行写操作的命令（如 git add、git commit 等），只可执行读操作的命令用于分析和总结。

分析根因（如果是修复类变更）：

如果是修复类变更（修复 panic/错误/异常），从 diff 反推发生了什么错误，确认修复是否完整。

生成 commit message：

格式遵循 Conventional Commits 2.1.0 规范：

<type>(<scope>): <用一句用户视角的话，描述提交后的最终效果或影响>

<正文留空一行>
**🤔 背景与动机 (Why)**
- 当前存在什么问题？
- 用户/系统的痛点是什么？

**✨ 解决方案与影响 (What & Impact)**
- 本次变更的核心逻辑/决策是什么？（高阶描述，非代码diff）
- 带来了哪些性能/体验上的变化？（如有数据请附上）

type: fix / feat / chore / refactor / docs / style / perf / test / ci / build / revert
scope: 模块名或目录名，如 plugin-system / cli_server / config / sdk
第一行不超过 72 字符
使用中文 body 说明背景和动机，输出的所有内容中不可以存在'"'双引号，避免 commit message 解析错误。
Scope 推导规则（硬性约束）：
1. 取变更文件数量最多的顶级目录作为 Scope（如 src/tauri/ 变更最多，取 tauri）。
2. 若变更文件均匀分布在 3 个及以上互不相关的目录，省略 Scope（即 fix: xxx）。
3. 禁止生成组合型 Scope（如 core/ui 或 core+ui）。

输出结果：

展示最终的 commit message 给用户。
不执行 git commit，只输出内容。

输出示例

fix(cli_server): 将 axum 路由参数从 `:param` 语法迁移到 `{param}` 语法 **🤔 背景与动机 (Why)** - 项目依赖的 axum 从 0.7 升级到 0.8 后，路径参数语法从 `:param` 变更为 `{param}`。 - 旧语法导致 CLI HTTP 服务器启动时 panic，所有含参数的路由不可用。 **✨ 解决方案与影响 (What & Impact)** - 将 server.rs 中 11 处路由定义从 `/:param` 全部替换为 `/{param}`。 - 变更后服务器正常启动，`/v1/config/{id}/` 和 `/v1/plugins/{id}/` 路由恢复可用。

注意事项

专注总结变更，不继续扩展新改动。

diff 里的文件内容不要直接复制到 commit message 中，而是概括性质和范围。

如果变更涉及外部依赖版本变更（如 crate 升级），在 commit body 里注明原因。

对于大型变更，按文件或模块分组描述。

summarize-changes