**重要提示**：此提示词可能在非交互式环境中运行（如 CI/CD、自动化脚本）。

**非交互式模式**：
- 禁止使用 `AskUserQuestion` 或任何交互式工具
- 当需要用户输入时：
  - 使用合理的默认值（如提交类型使用 `feat`）
  - 跳过可选的确认步骤
  - 记录所做的假设

**交互式模式**：
- 遵循正常的交互式流程，提示用户输入

---

<task>
分析工作区中的所有未提交变更（包括已暂存和未暂存状态），智能地将它们分组为多个逻辑提交。
</task>

<context>
用户正在 Git 仓库中工作，仓库位置为：
<project_path>
{{ projectPath }}
</project_path>

{{#if needPush}}
<push_control>
needPush 参数设置为 {{needPush}}。
pullRebaseBeforePush 参数设置为 {{pullRebaseBeforePush}}。
{{#if pullRebaseBeforePush}}
在推送前，先针对最终解析出的当前分支上游执行 `git pull --rebase`。如果 rebase 失败，必须在 push 之前停止，并明确报告远程未发布。
{{else if pullRebaseBeforePushRequested}}
用户请求了“推送前 rebase”，但本次运行并不是留在当前分支。将该请求视为 no-op，并按最终目标分支的正常推送路径继续。
{{else}}
本次运行在推送前不要执行 `git pull --rebase`。
{{/if}}
如果为 true：所有提交创建后，检查 fastforward 关系，如果安全则推送。
如果为 false：仅创建本地提交，不推送。
</push_control>
{{/if}}

<target_branch_control>
targetBranchMode 参数设置为 {{targetBranchMode}}。
{{#if targetBranchName}}
targetBranchName 参数设置为 {{targetBranchName}}。
{{/if}}
规则如下：
- 如果 targetBranchMode 为 `current`：保持当前分支，不创建新分支
- 如果 targetBranchMode 为 `new-custom`：在任何提交前，从当前分支创建名为 `targetBranchName` 的新分支
- 如果 targetBranchMode 为 `ai-generated-new`：在任何提交前，根据本次变更生成 kebab-case 新分支名，并从当前分支创建它
- 不要切换到任何已存在的其他分支
</target_branch_control>

你需要：
1. 使用 Git 命令获取工作区中所有未提交的变更（包括已暂存和未暂存状态）
2. 分析所有未提交的文件变更，理解它们的语义关系
3. 将文件智能分组为 1 个或多个逻辑提交
4. **直接使用 Git 命令执行每个提交**（不返回计划，直接操作）
</context>

<working_directory>
使用此项目路径作为工作目录：{{ projectPath }}
</working_directory>

{{#if gitProfileName}}
<git_profile>
在所有生成的提交中使用以下 Git 身份：
- 选定名称：{{gitProfileName}}
- 选定邮箱：{{gitProfileEmail}}
- Git 提交历史里有两种身份：`Author`（作者）和 `Committer`（实际执行提交的人）
- `--author="Name <email>"` 只会修改 Author
- `git -c user.name="Name" -c user.email="email" commit ...` 只会修改这一次命令的 Committer
- 对于每一个生成的提交，你都必须同时把 Author 和 Committer 设置为选定身份
- 首选命令形式：
  `git -c user.name="{{gitProfileName}}" -c user.email="{{gitProfileEmail}}" commit --author="{{gitProfileName}} <{{gitProfileEmail}}>" ...`
- 如果确实需要更底层的兜底方式，可以设置 `GIT_COMMITTER_NAME` 和 `GIT_COMMITTER_EMAIL`，但优先使用上面的 `git -c ... commit --author=...` 形式
- 提交分组与措辞都要保持与该身份一致。
{{#if signedOffByEnabled}}
- 本次运行还要求 Git 标准 sign-off 尾注，因此优先使用 `git ... commit --author=... --signoff ...`
{{/if}}
</git_profile>
{{/if}}

<tools>
你可以使用以下工具：
- Bash(git:*) - 执行 Git 命令
- Read - 读取文件内容
- Write/Edit - 写入文件（如需要）
- Bash(cat:*, ls:*, find:*) - 查看文件信息
</tools>

<requirements>
  <requirement>
    **目标分支处理**：
    - 如果 `targetBranchMode=current`，所有提交都必须保留在当前分支上执行
    - 如果 `targetBranchMode=new-custom`，必须在第一次提交前使用 `git switch -c "<targetBranchName>"` 从当前分支创建新分支
    - 如果 `targetBranchMode=ai-generated-new`，必须先根据变更内容生成 kebab-case 分支名，再使用 `git switch -c "<generated-branch>"` 从当前分支创建新分支
    - 不得切换到任何已存在的其他分支
    - 如果新分支创建失败，应返回错误而不是继续创建提交
  </requirement>
  <requirement>
    **智能分组**：根据文件变更的语义关系，将它们组织成多个逻辑提交
    - 不要执行任何 git reset 操作（状态管理由后端处理）
  </requirement>
  <requirement>
    **重要**：每个提交必须添加 Co-Authored-By 信息
    - 使用以下格式：`git commit -m "type(scope): subject" -m "" -m "Co-Authored-By: Hagicode <noreply@hagicode.com>"`
    - 或者直接在提交信息中包含 Co-Authored-By 行
  </requirement>
  {{#if signedOffByEnabled}}
  <requirement>
    **Signed-off-by 约束**：
    {{#if gitProfileName}}
    - 每个生成的提交都必须包含 `Signed-off-by: {{gitProfileName}} <{{gitProfileEmail}}>`
    - 优先使用 `git -c user.name="{{gitProfileName}}" -c user.email="{{gitProfileEmail}}" commit --author="{{gitProfileName}} <{{gitProfileEmail}}>" --signoff ...`
    {{else}}
    - 如果缺少 Git profile 信息，必须停止并报错，不得臆造 Signed-off-by 身份
    {{/if}}
    - `Co-Authored-By: Hagicode <noreply@hagicode.com>` 仍要保留在同一 trailer 块中
    - 提交正文与 trailer 块之间必须保留一个空行
  </requirement>
  {{else}}
  <requirement>
    **本次运行关闭 Signed-off-by**：
    - 不要添加任何 `Signed-off-by:` 尾注
    - 现有 `Co-Authored-By: Hagicode <noreply@hagicode.com>` 行为保持不变
  </requirement>
  {{/if}}
  {{#if gitProfileName}}
  <requirement>
    **Git 身份约束**：
    - 对于每一个生成的提交，都要把 `Author` 和 `Committer` 同时设置为 `{{gitProfileName}} <{{gitProfileEmail}}>`
    - 不要只使用 `--author`，因为那样不会修改 Committer
    - 优先使用 `git -c user.name="{{gitProfileName}}" -c user.email="{{gitProfileEmail}}" commit --author="{{gitProfileName}} <{{gitProfileEmail}}>" ...`
    - 如果需要核对提交中的双重身份，可使用 `git log --format=fuller -1`
  </requirement>
  {{/if}}
  <requirement>
    根据语义关系对文件进行分组：
    - 相同功能/特性的文件放在同一提交
    - 相同组件/模块的文件放在同一提交
    - 配置变更应独立于代码变更
    - 文档变更应独立于功能变更
    - 测试文件应与被测试的实现放在一起

    **文件分组决策树**：
    ```
    文件分组决策树
    ├── 是否为配置文件（package.json、tsconfig.json、.env 等）？
    │   ├── 是 → 独立提交（类型：chore 或 build）
    │   └── 否 → 继续
    ├── 是否为文档文件（README.md、*.md、docs/**）？
    │   ├── 是 → 独立提交（类型：docs）
    │   └── 否 → 继续
    ├── 是否与同一功能相关？
    │   ├── 是 → 合并到同一提交
    │   └── 否 → 分别提交
    └── 是否为跨模块变更？
        ├── 是 → 按模块分组
        └── 否 → 按功能分组
    ```

    **分组示例**：
    - `src/auth/login.ts` + `src/auth/auth.service.ts` → 同一提交（同一模块）
    - `src/components/Button.tsx` + `src/components/Button.test.tsx` → 同一提交（测试与实现）
    - `package.json` + `tsconfig.json` → 同一提交（配置变更）
    - `README.md` + `docs/api.md` → 同一提交（文档变更）
    - `src/auth/login.ts` + `src/utils/date.ts` → 分别提交（不同模块）
  </requirement>
  <requirement>
    遵循约定式提交（Conventional Commits）规范：
    https://www.conventionalcommits.org/zh-hans/
  </requirement>
  <requirement>
    使用以下类型之一：
    - feat: 新功能
    - fix: 修复 bug
    - docs: 仅文档变更
    - style: 不影响代码含义的格式变更
    - refactor: 既不修复 bug 也不添加功能的代码变更
    - perf: 提高性能的代码变更
    - test: 添加缺失的测试或修正现有测试
    - build: 影响构建系统或外部依赖的变更
    - ci: CI 配置文件和脚本的变更
    - chore: 其他不修改 src 或测试文件的变更
    - revert: 回滚之前的提交
  </requirement>
  <requirement>
    主题行必须：
    - 使用祈使语气（添加，而非已添加）
    - 最多 50-72 个字符
    - 不以句号结尾
    - 以 type(scope): 前缀开头
  </requirement>
  <requirement>
    确保每个文件都被提交
  </requirement>
</requirements>

<historical_format_analysis>
  <requirement>
    **历史格式一致性**：在生成提交信息之前，你**必须**分析当前仓库的提交历史以匹配现有风格

    1. 使用 `git log -n 15 --pretty=format:"%H|%s|%b%n---%n"` 获取最近的提交历史
    2. 分析提交以识别：
       - 结构模式：项目是否使用多段落？是否有 "Changes:" 或 "Capabilities:" 部分？
       - 语言模式：提交信息是英文、中文还是混合？
       - 常用类型：最常使用哪些提交类型（feat、fix、docs 等）？
       - 特殊格式：是否有 Co-Authored-By 行？其他项目特定的约定？

    3. 生成遵循检测到的模式的提交信息

    **特殊场景处理**：
    - **空仓库/首次提交**：如果没有之前的提交（新仓库），使用标准的 Conventional Commits 格式，不添加自定义模式。提交类型应使用 `feat` 或 `chore`。
    - **混合语言**：如果历史中存在混合语言，遵循主要语言或最后使用的语言。
    - **无明确模式**：如果历史提交没有明确模式，使用 Conventional Commits 标准格式。
  </requirement>
</historical_format_analysis>

<constraints>
  <constraint>不要执行任何 git reset 操作</constraint>
  <constraint>忽略 .gitignore 中定义的文件和目录</constraint>
  <constraint>按功能逻辑将文件分组到独立的提交中</constraint>
  <constraint>每个提交应包含逻辑上相关联的文件变更</constraint>
  <constraint>遵循约定式提交格式生成提交消息</constraint>
</constraints>

<workflow>
按照以下步骤执行：

1. **获取文件变更**：使用 `git status --porcelain` 或 `git diff` 命令获取所有未提交的文件变更

2. **分析文件**：使用 Read 工具查看变更的文件内容，理解变更的性质

3. **智能分组**：将文件按语义关系分组

4. **准备目标分支**：
   a. 如果 `targetBranchMode` 是 `current`，保持当前分支不变
   b. 如果 `targetBranchMode` 是 `new-custom`，使用提供的 `targetBranchName` 从当前分支创建新分支
   c. 如果 `targetBranchMode` 是 `ai-generated-new`，生成一个英文 kebab-case 分支名；如果冲突，追加稳定后缀；然后从当前分支创建新分支
   d. 记录最终实际使用的目标分支名称

5. **执行提交**（对每个分组）：
   a. 使用 `git add <file1> <file2> ...` 暂存该组的所有文件
   b. 使用正确的 Git 身份执行提交
   {{#if gitProfileName}}
      {{#if signedOffByEnabled}}
      - 使用：
        `git -c user.name="{{gitProfileName}}" -c user.email="{{gitProfileEmail}}" commit --author="{{gitProfileName}} <{{gitProfileEmail}}>" --signoff -m "type(scope): subject" -m "" -m "Co-Authored-By: Hagicode <noreply@hagicode.com>"`
      {{else}}
      - 使用：
        `git -c user.name="{{gitProfileName}}" -c user.email="{{gitProfileEmail}}" commit --author="{{gitProfileName}} <{{gitProfileEmail}}>" -m "type(scope): subject" -m "" -m "Co-Authored-By: Hagicode <noreply@hagicode.com>"`
      {{/if}}
   {{else}}
      - 使用：
        `git commit -m "type(scope): subject" -m "" -m "Co-Authored-By: Hagicode <noreply@hagicode.com>"`
   {{/if}}
   c. 记录提交的 hash

6. **验证**：使用 `git log --oneline -n 10` 验证提交已成功创建
   {{#if gitProfileName}}
   - 必要时再使用 `git log --format=fuller -1`，确认 Author 和 Committer 都已经写入选定身份
   {{/if}}

{{#if needPush}}
7. **推送到远程仓库（如果 needPush 为 true）**：
   a. 使用 `git remote -v` 识别远程仓库
   b. 使用最终目标分支名称作为唯一推送目标
   c. {{#if pullRebaseBeforePush}}如果最终目标分支就是当前原分支，先执行 `git pull --rebase`；若 rebase 失败则必须在 push 前停止{{else}}如果最终目标分支就是当前原分支，本次运行跳过推送前 rebase{{/if}}
   d. 如果最终目标分支就是当前原分支，检查 fastforward 关系：`git merge-base --is-ancestor origin/<target-branch> HEAD`
   e. 如果最终目标分支是本次新建分支，且远程不存在同名分支：执行 `git push --set-upstream origin <target-branch>`
   f. 如果最终目标分支在远程已存在：先做 fastforward 安全检查，安全时执行 `git push origin <target-branch>`
   g. 如果 fastforward 不安全（命令返回非零）：跳过推送，记录原因并继续
   h. 记录推送结果（成功/跳过）

8. **报告结果**：返回简洁的摘要，列出所有执行的提交和推送状态
{{else}}
7. **报告结果**：返回简洁的摘要，列出所有执行的提交
{{/if}}
</workflow>

<output_format>
完成所有提交后，**必须**使用以下确切的格式返回摘要（重要：使用 `---` 作为每个提交之间的分隔符）：

---
Commit 1: {commit_hash}
{commit_message}
---
Commit 2: {commit_hash}
{commit_message}
---
...

**格式要求**：
- 每个提交结果以 `---` 开头（单独一行）
- 第一行格式：`Commit N: {commit_hash}`（N 是提交序号）
- 第二行及后续行是提交信息（可以包含多行）
- 提交之间使用 `---` 分隔（单独一行）
- 最后一个提交后也以 `---` 结束

**完整输出示例**：
---
Commit 1: abc123def456
feat(auth): add user login functionality

Implement JWT-based authentication with login form and API endpoints.

Co-Authored-By: Hagicode <noreply@hagicode.com>
---
Commit 2: 789ghi012jkl
docs(readme): update installation instructions

Add new setup steps for Docker environment.

Co-Authored-By: Hagicode <noreply@hagicode.com>
---

如果任何提交失败，在对应的提交段中报告错误。
不要追加任何统计信息，输出必须只包含提交段列表。
</output_format>

<final_instruction>
重要：你必须直接执行 Git 命令来完成提交，不要只返回计划。
确保所有文件都被提交，且每个提交都包含正确的 trailer 块。
{{#if signedOffByEnabled}}
每个提交都必须同时包含 `Co-Authored-By: Hagicode <noreply@hagicode.com>` 与正确的 `Signed-off-by:` 尾注。
{{else}}
每个提交都必须包含 `Co-Authored-By: Hagicode <noreply@hagicode.com>`，且不得包含 `Signed-off-by:` 尾注。
{{/if}}

**输出格式要求**：返回结果时**必须**在每个提交之间使用 `---` 分隔符。这是后端解析多提交结果的必要格式。
</final_instruction>
