**Important Note**: This prompt may run in non-interactive environments (e.g., CI/CD, automation scripts).

**Non-interactive mode**:
- Do NOT use `AskUserQuestion` or any interactive tools
- When user input is needed:
  - Use reasonable defaults (e.g., use `feat` for commit type)
  - Skip optional confirmation steps
  - Document assumptions made

**Interactive mode**:
- Follow normal interactive flow, prompt user for input

---

<task>
Analyze all uncommitted changes in the workspace (including staged and unstaged states), intelligently group them into multiple logical commits.
</task>

<context>
User is working in a Git repository at:
<project_path>
{{ projectPath }}
</project_path>

{{#if needPush}}
<push_control>
needPush parameter is set to {{needPush}}.
If true: After all commits are created, check fastforward relationship and push if safe.
If false: Only create local commits, do not push.
</push_control>
{{/if}}

You need to:
1. Use Git commands to get all uncommitted changes in the workspace (including staged and unstaged states)
2. Analyze all uncommitted file changes to understand their semantic relationships
3. Intelligently group files into 1 or more logical commits
4. **Directly use Git commands to execute each commit** (do not return a plan, execute directly)
</context>

<working_directory>
Use this project path as the working directory: {{ projectPath }}
</working_directory>

<tools>
You can use the following tools:
- Bash(git:*) - Execute Git commands
- Read - Read file contents
- Write/Edit - Write files (if needed)
- Bash(cat:*, ls:*, find:*) - View file information
</tools>

<requirements>
  <requirement>
    **Branch Protection**:
    - Do NOT execute any branch switching operations (git checkout, git switch)
    - All git commit commands must be executed on the current branch
    - Do NOT create, delete, or rename branches
    - Do NOT modify untracked files or unstaged changes
    - If branch switching is required to complete the operation, return an error instead of executing
  </requirement>
  <requirement>
    **Intelligent grouping**: Organize file changes into multiple logical commits based on their semantic relationships
    - Do not execute any git reset operations (state management is handled by the backend)
  </requirement>
  <requirement>
    **Important**: Each commit must include Co-Authored-By information
    - Use this format: `git commit -m "type(scope): subject" -m "" -m "Co-Authored-By: Hagicode <noreply@hagicode.com>"`
    - Or include Co-Authored-By line directly in the commit message
  </requirement>
  <requirement>
    Group files based on semantic relationships:
    - Files for the same feature/functional area go in the same commit
    - Files for the same component/module go in the same commit
    - Configuration changes should be separate from code changes
    - Documentation changes should be separate from feature changes
    - Test files should be grouped with the implementation they test

    **File Grouping Decision Tree**:
    ```
    File grouping decision tree
    ├── Is it a config file (package.json, tsconfig.json, .env, etc.)?
    │   ├── Yes → Separate commit (type: chore or build)
    │   └── No → Continue
    ├── Is it a doc file (README.md, *.md, docs/**)?
    │   ├── Yes → Separate commit (type: docs)
    │   └── No → Continue
    ├── Is it related to the same feature?
    │   ├── Yes → Merge into same commit
    │   └── No → Separate commits
    └── Is it a cross-module change?
        ├── Yes → Group by module
        └── No → Group by feature
    ```

    **Grouping Examples**:
    - `src/auth/login.ts` + `src/auth/auth.service.ts` → Same commit (same module)
    - `src/components/Button.tsx` + `src/components/Button.test.tsx` → Same commit (test with implementation)
    - `package.json` + `tsconfig.json` → Same commit (config changes)
    - `README.md` + `docs/api.md` → Same commit (documentation changes)
    - `src/auth/login.ts` + `src/utils/date.ts` → Separate commits (different modules)
  </requirement>
  <requirement>
    Follow Conventional Commits specification:
    https://www.conventionalcommits.org/
  </requirement>
  <requirement>
    Use one of the following types:
    - feat: A new feature
    - fix: A bug fix
    - docs: Documentation only changes
    - style: Changes that do not affect the meaning of the code
    - refactor: A code change that neither fixes a bug nor adds a feature
    - perf: A code change that improves performance
    - test: Adding missing tests or correcting existing tests
    - build: Changes that affect the build system or external dependencies
    - ci: Changes to CI configuration files and scripts
    - chore: Other changes that don't modify src or test files
    - revert: Reverts a previous commit
  </requirement>
  <requirement>
    Subject line must:
    - Use imperative mood (add, not added)
    - Be 50-72 characters max
    - Not end with a period
    - Begin with type(scope): prefix
  </requirement>
  <requirement>
    Ensure every file is committed
  </requirement>
</requirements>

<historical_format_analysis>
  <requirement>
    **Historical Format Consistency**: Before generating commit messages, you MUST analyze the current repository's commit history to match the existing style

    1. Use `git log -n 15 --pretty=format:"%H|%s|%b%n---%n"` to get recent commit history
    2. Analyze the commits to identify:
       - Structure pattern: Does the project use multiple paragraphs? Are there "Changes:" or "Capabilities:" sections?
       - Language pattern: Are commit messages in English, Chinese, or mixed?
       - Common types: Which commit types (feat, fix, docs, etc.) are most frequently used?
       - Special formatting: Are there Co-Authored-By lines? Any other project-specific conventions?

    3. Generate commit messages that follow the detected patterns

    **Special Scenarios**:
    - **Empty repository/First commit**: If there are no previous commits (new repository), use standard Conventional Commits format without custom patterns. Use `feat` or `chore` for commit type.
    - **Mixed languages**: If the history contains mixed languages, follow the primary language or the last used language.
    - **No clear pattern**: If there's no clear pattern in commit history, use the standard Conventional Commits format.
  </requirement>
</historical_format_analysis>

<constraints>
  <constraint>Do not execute any git reset operations</constraint>
  <constraint>Ignore files and directories defined in .gitignore</constraint>
  <constraint>Group files into separate commits by functional logic</constraint>
  <constraint>Each commit should contain logically related file changes</constraint>
  <constraint>Follow Conventional Commits format for commit messages</constraint>
</constraints>

<workflow>
Follow these steps:

1. **Get file changes**: Use `git status --porcelain` or `git diff` commands to get all uncommitted file changes

2. **Analyze files**: Use Read tool to examine the changed files and understand the nature of changes

3. **Intelligent grouping**: Group files by semantic relationships

4. **Execute commits** (for each group):
   a. Use `git add <file1> <file2> ...` to stage all files in this group
   b. Use `git commit -m "type(scope): subject" -m "" -m "Co-Authored-By: Hagicode <noreply@hagicode.com>"` to execute the commit
   c. Record the commit hash

5. **Verify**: Use `git log --oneline -n 10` to verify commits were successfully created

{{#if needPush}}
6. **Push to remote (if needPush is true)**:
   a. Use `git remote -v` to identify the remote repository
   b. Use `git branch --show-current` to get the current branch name
   c. Check fastforward relationship with: `git merge-base --is-ancestor origin/$(git branch --show-current) HEAD`
   d. If fastforward is safe (command returns success): Execute `git push`
   e. If fastforward is NOT safe (command returns non-zero): Skip push, log the reason, and continue
   f. Record the push result (success/skipped)

7. **Report results**: Return a concise summary listing all executed commits and push status
{{else}}
6. **Report results**: Return a concise summary listing all executed commits
{{/if}}
</workflow>

<output_format>
After completing all commits, you **must** return a summary in this exact format (Important: use `---` as the delimiter between commits):

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

**Format Requirements**:
- Each commit result starts with `---` on its own line
- First line format: `Commit N: {commit_hash}` (N is the commit number)
- Second and subsequent lines contain the commit message (may span multiple lines)
- Use `---` separator between commits (on its own line)
- End the last commit with `---` as well

**Complete Output Example**:
---
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>
---

If any commit fails, report the error in the corresponding commit segment.
Do not append any statistics section; output MUST include commit blocks only.
</output_format>

<final_instruction>
Important: You must directly execute Git commands to complete the commits, do not just return a plan.
Ensure all files are committed and each commit includes the correct Co-Authored-By information.

**Output Format Requirement**: When returning results, you **must** use `---` delimiters between each commit. This is the required format for backend parsing of multi-commit results.
</final_instruction>
