---
description: Commit staged and unstaged changes following Conventional Commits, splitting big changes into smaller logical commits.
---

## User Input

```text
$ARGUMENTS
```

You **MUST** consider the user input before proceeding (if not empty).

## Outline

1. **Resolve remote URL**: Run `git remote get-url origin` to get the remote URL. All commit references produced by this skill MUST use the remote URL format (e.g., `<remote-url>/commit/<hash>`). Never output bare hashes without the full remote link.
2. Run `git status` to see all changed and untracked files.
3. Run `git diff` and `git diff --staged` to understand the changes.
4. Run `git log --oneline -5` to see recent commit style.
5. **Analyze and group changes into logical commits.** Review all changed files and determine if they can be separated into smaller, focused commits. Group by:
   - **Purpose**: Bug fix vs feature vs docs vs config — never mix these in one commit.
   - **Scope**: Changes to different modules (frontend, backend, specs, config) should be separate commits unless they are tightly coupled and meaningless without each other.
   - **Independence**: If a subset of changes can stand on its own and still make sense, it should be its own commit.
   - Present the proposed commit grouping to the user for approval before proceeding.
6. For each logical group, stage only the relevant files using `git add <file>` (never use `git add -A` or `git add .`) and commit them individually.
7. Write a commit message following the **Conventional Commits** specification.
8. After each successful commit, report the commit hash as a full remote link: `<remote-url>/commit/<hash>` (using the URL resolved in step 1).

### Commit Message Format

```
<type>(<scope>): <short summary>

<optional body>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
```

### Types

- `feat`: A new feature
- `fix`: A bug fix
- `docs`: Documentation only changes
- `style`: Changes that do not affect the meaning of the code (white-space, formatting)
- `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. Claude config files can be categorized here. Example `chore(claude)`

### Scope

Use the relevant module or area in parentheses:
- `frontend` — SvelteKit or other frontend changes
- `backend` — Spring Boot or other backend changes
- `monitoring` — Prometheus, or Grafana changes
- `server` — Docker, Docker Compose, Kubernetes changes
- Omit scope if the change spans multiple areas
- Append - with application name if available. Example `backend-auth`.

### Rules

- The summary must be lowercase, imperative mood, no period at the end
- Keep the summary under 70 characters
- Use the body for additional context when the summary alone is not sufficient
- Always end with the `Co-Authored-By` trailer
- Use a HEREDOC to pass the commit message to `git commit -m`
- NEVER use `--no-verify` or skip pre-commit hooks
- NEVER amend a previous commit unless explicitly asked