---
name: commit-changes
description: Creates one or more git commits using scoped conventional commit messages. Use when changes are ready to commit and you want the agent to stage only the intended files, follow repository commit rules, and avoid unrelated modifications.
---

# Commit Changes

Create git commits that follow scoped conventional commit format.

## Goals

- Inspect the current git status and relevant diffs
- Identify the files that belong to the completed task
- Stage only the intended files explicitly by path
- Create one or more atomic commits when appropriate
- Use scoped conventional commit messages
- Avoid including unrelated changes
- Never amend unless the user explicitly asks

## Commit Format

Use scoped conventional commit messages by default:
- `feat(scope): ...`
- `fix(scope): ...`
- `refactor(scope): ...`
- `chore(scope): ...`
- `test(scope): ...`
- `docs(scope): ...`

Choose the smallest accurate type and scope based on the actual changes.

If the correct type or scope is not obvious, ask the user.

## Required Workflow

### 1) Inspect git state

Always check `git status` first.

Identify:
- tracked modified files
- new files
- deleted files
- unrelated changes outside the current task

### 2) Determine commit boundaries

Use judgment to decide whether the work should be:
- one atomic commit, or
- split into multiple atomic commits

Split commits when the changes represent clearly separate concerns.

If commit boundaries are ambiguous, ask the user.

### 3) Handle unrelated changes safely

Commit only the files known to belong to the current task.

If unrelated modified files exist:
- exclude them from the commit
- tell the user they were left out
- ask whether they want help with those separately only if useful

Do not accidentally stage unrelated files.

### 4) Stage files explicitly by path

Follow repository rules:
- always stage or commit explicit file paths
- quote any paths containing brackets or parentheses
- never use broad staging that may sweep in unrelated work

For tracked files, prefer:
- `git commit -m "<scoped message>" -- path/to/file1 path/to/file2`

For brand-new files, follow the repository-required flow:
- `git restore --staged :/ && git add "path/to/file1" "path/to/file2" && git commit -m "<scoped message>" -- path/to/file1 path/to/file2`

If a commit contains both tracked and new files, use the safest explicit-path flow that stages only the intended files.

### 5) Message selection

Infer the conventional commit type and scope from the changes.

Examples:
- bug fix in review flow → `fix(review): ...`
- new skill for plan execution → `feat(skills): ...`
- cleanup without behavior change → `refactor(<scope>): ...`

Only ask the user if the message is not reasonably obvious from the diff.

### 6) Commit

Create the commit or commits.

Do not amend existing commits unless the user explicitly asks.

## Scope Heuristics

Prefer concise scopes that match the area changed, such as:
- `skills`
- `review`
- `planning`
- `auth`
- `ui`
- `api`
- `types`

Use a more specific scope when the changed area is clear and useful.

## Output

Reply concisely with:
- the commit message or messages created
- any files intentionally left out because they appeared unrelated

## Safety Rules

- never run destructive git operations
- never commit unrelated files just to “clean up” status
- never amend unless explicitly requested
- if uncertain about file ownership, commit boundaries, or message selection, ask first

## Quality Bar

A good commit operation:
- produces atomic commits
- uses accurate scoped conventional messages
- includes only intended files
- leaves unrelated work untouched