Commit Changes

Use this skill when the user wants the current local work packaged into a clean commit without taking it through push or GitHub PR creation. Get onto the correct feature branch first when needed, keep commit metadata aligned to the tracked diff, ask before rewriting history on non-default multi-commit branches, and stop after reporting the local commit result.

Boundary Rules

• This skill owns local branch, changeset, and commit preparation only. It does not push or create or update GitHub PRs.
• If the user wants to take the work through push and PR creation, use gh-pr-create after this skill prepares or refreshes the commit.
• If the user wants a deep critique of the branch approach, implementation plan, or test strategy before mutating git state, use gh-plan-review.

Core Workflow

1. If you are not already on the intended feature branch, create it immediately before doing other work. Do not continue on main, master, or another default branch.
2. Name the branch <username>/<descriptive-name>. Do not use feature/, feat/, or fix/. Use the system username when it is clear; otherwise fall back to the agent name.
3. Inspect git status --short, the current diff, existing repo conventions, and branch history before deciding whether to create a new commit or amend.
4. Determine whether the current branch is single-commit or multi-commit. Count branch commits relative to the intended PR base when that base is known; otherwise count relative to the repository default-branch merge-base. More than one branch commit is multi-commit.
5. Complete the requested work and run the smallest relevant verification for the touched files before committing or amending.
6. If the repo uses Changesets, add the smallest accurate changeset before the final commit or amend.
7. On a non-default multi-commit branch, do not assume amend or squash. Ask whether to create a new commit, amend HEAD, or do another explicit history rewrite, and stop until the user answers.