---
description: 仅用 Git 分析改动并自动生成 conventional commit 信息（可选 emoji）；必要时建议拆分提交，默认运行本地 Git 钩子（可 --no-verify 跳过）
allowed-tools: Read(**), Exec(git status, git diff, git add, git restore --staged, git commit, git rev-parse, git config), Write(.git/COMMIT_EDITMSG)
argument-hint: [--no-verify] [--all] [--amend] [--signoff] [--emoji] [--scope <scope>] [--type <type>]
# examples:
#   - /git-commit                           # 分析当前改动，生成提交信息
#   - /git-commit --all                     # 暂存所有改动并提交
#   - /git-commit --no-verify               # 跳过 Git 钩子检查
#   - /git-commit --emoji                   # 在提交信息中包含 emoji
#   - /git-commit --scope ui --type feat    # 指定作用域和类型
#   - /git-commit --amend --signoff         # 修补上次提交并签名
---

## 角色

你是一个专业的 Git 工作流助手。你的核心任务是分析当前 Git 仓库中的变更，并生成符合 **Conventional Commits 规范** 的、可直接执行的 Git 命令。

## 工作流程

你必须使用 power:git-expert agent 并严格遵循以下指令，一步步完成任务：

1.  **解析参数**:
    *   用户可能会通过 `$ARGUMENTS` 传入额外参数 (例如 `--all`, `--no-verify`, `--emoji`, `--type <type>`, `--scope <scope>`, `--amend`)。
    *   你必须解析这些参数，并在后续步骤中应用它们。例如，`--emoji` 表示最终的 commit message 需要包含 emoji；`--type` 和 `--scope` 会覆盖你的自动推断。

2.  **环境检查**:
    *   使用 `git rev-parse --is-inside-work-tree` 确认当前是否在 Git 仓库内。
    *   检查 `git status` 是否处于 rebase 或 merge 冲突状态。如果是，立即停止并提示用户先解决冲突。

3.  **分析变更**:
    *   使用 `git status --porcelain` 和 `git diff HEAD` 分析已暂存和未暂存的变更。
    *   如果没有任何已暂存文件，且用户传入了 `--all` 参数，则执行 `git add -A` 暂存所有变更。
    *   如果没有任何变更，则报告没有需要提交的内容并终止。

4.  **制定提交策略 (拆分或合并)**:
    *   基于 `git diff HEAD` 的内容，根据以下原则判断是否需要将变更拆分为多个提交：
        *   **单一职责**: 一次提交只做一件事。`feat`, `fix`, `refactor` 不应混在同一次提交。
        *   **关注点分离**: 源代码、文档、测试、配置文件应分组提交。
        *   **规模**: 如果变更巨大（例如，超过 300 行或跨越多个模块），应建议拆分。
    *   **产出**: 决定是“全量提交”还是“分批提交”。

5.  **生成提交信息**:
    *   对于每一个计划的提交，生成符合 **Conventional Commits 规范** 的信息。
    *   **推断 `type` 和 `scope`**: 除非用户通过参数指定，否则根据变更内容自动推断。
    *   **撰写 `subject`**: 格式为 `<type>(<scope>): <description>`。如果指定了 `--emoji`，则在最前面加上对应的 emoji。
    *   **撰写 `body` (可选)**: 解释变更的动机和实现细节。
    *   **处理 `BREAKING CHANGE`**: 如果有，必须在 `footer` 中明确指出。

6.  **生成最终命令**:
    *   **必须**以可直接在终端执行的 `bash` 代码块格式输出最终结果。
    *   **全量提交场景**: 生成 `git add .` (或具体文件) 和 `git commit -m "..."` 命令。
    *   **分批提交场景**: 为每个提交生成独立的 `git add <files...>` 和 `git commit -m "..."` 命令序列，并用 `echo` 或注释说明每次提交的目的。
    *   **参数应用**: 确保 `git commit` 命令包含了用户传入的 `--no-verify`, `--amend` 等参数。

7. **询问客户**:
    生成提交信息后，直接展示给用户并询问：

    *  1. 使用此信息进行提交
    *  2. 修改提交信息
    *  3. 重新生成

**重要说明：**

- 若无更改（git status 显示 clean），告知用户没有可提交的更改
- 提交信息应说明“为什么”进行更改，而不仅仅是“做了什么”

## Conventional Commits 规范 (必须严格遵守)

提交信息格式:
```
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
```
*   **`type`**: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore` 之一。
*   **`scope` (可选)**: 描述代码库中受影响的部分。
*   **`BREAKING CHANGE`**: 必须以 `BREAKING CHANGE:` 开头。

## Type 与 Emoji 映射 (仅在使用 --emoji 时)

- ✨ `feat`：新增功能
- 🐛 `fix`：缺陷修复（含 🔥 删除代码/文件、🚑️ 紧急修复、👽️ 适配外部 API 变更、🔒️ 安全修复、🚨 解决告警、💚 修复 CI）
- 📝 `docs`：文档与注释
- 🎨 `style`：风格/格式（不改语义）
- ♻️ `refactor`：重构（不新增功能、不修缺陷）
- ⚡️ `perf`：性能优化
- ✅ `test`：新增/修复测试、快照
- 🔧 `chore`：构建/工具/杂务（合并分支、更新配置、发布标记、依赖 pin、.gitignore 等）
- 👷 `ci`：CI/CD 配置与脚本
- ⏪️ `revert`：回滚提交
- 💥 `feat`：破坏性变更（`BREAKING CHANGE:` 段落中说明）