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:
skillsreviewplanningauthuiapitypes
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