Commit and Push

Produce logically scoped commits and push the requested branch without absorbing unrelated user changes. Report the commits, pushed ref, verification evidence, and any remaining worktree state.

Workflow

1. Inspect before mutating:

   git rev-parse --show-toplevel
   git status -sb
   git branch --show-current
   git remote -v
   git diff --stat
   git diff
   git diff --cached

2. Read repository instructions such as CONTRIBUTING.md and inspect recent commit style. Repository and user conventions override this skill's fallback.
3. Lock scope from the request and diff. Preserve unrelated tracked, untracked, staged, and unstaged changes. Stage explicit paths; use git add -A only when the whole worktree clearly belongs to the request.
4. Run focused, relevant checks before committing. Reuse results already run against the unchanged intended diff; rerun after a relevant edit, conflict resolution, failed check, or repository requirement. Keep required results and failures; do not expand into an unrelated full-CI campaign unless requested or repository policy requires it.
5. Split changes into independently revertible units. Keep implementation and its tests together; order prerequisite commits before dependents.

6. When committing is requested, commit each unit and inspect what landed:

   git diff --cached --stat
   git diff --cached
   git commit -m "<message>"
   git show --stat --oneline HEAD

7. When pushing is requested, fetch and reconcile the selected upstream (often origin, but do not assume the name):

   git fetch <remote>
   git status -sb

   If the upstream advanced, rebase the local commits onto it. With a dirty worktree, finish only the intended commits first; do not hide unrelated work in an automatic stash. Resolve conflicts only when repository intent is clear, rerun affected checks, and abort with git rebase --abort if safe resolution needs user or product judgment.

8. Push the requested branch only when pushing is authorized. Use tracking when needed:

   git push -u <remote> HEAD

   If an already-pushed, clearly user-owned topic branch was rebased, use git push --force-with-lease, never plain --force. Ask before rewriting a shared or ambiguous branch.

9. Verify the result:

   git status -sb
   git log --oneline -n 5

   Confirm the pushed branch/upstream and retain any unrelated worktree changes.

Commit Shape

One commit should represent one logical change that can be reviewed and reverted on its own. Avoid splitting by arbitrary file count or layer when the files implement one behavior.

Use the repository's message convention. If none exists, use:

<type>(<scope>): <imperative subject>

<why this change is needed and any non-obvious consequence>

Fallback types are feat, fix, refactor, docs, test, chore, ci, perf, and style. Default to concise English when the repository and user do not establish another language. Add a body only when rationale, risk, or a reference would otherwise be lost. Do not add agent branding, Co-Authored-By, or author lines unless explicitly requested.

For a direct default-branch commit without a PR, include enough rationale and verification in the commit body for the log to stand alone, but do not generate a ceremonial report or file-by-file inventory.

Side-Effect Boundary

Honor the requested Git actions: commit-only stops after commits, push-only pushes existing commits, and commit-and-push does both. An established session request for both needs no additional approval between them. None covers issue comments, issue/PR body or title edits, releases, tags, or other remote mutations. Perform those only when the same request explicitly includes them, and use the corresponding specialized skill. Publishing the branch as a pull request belongs to draft-pr, entered only on an explicit request to open or update one.

Output Contract

Lead with whether the requested Git actions succeeded. Include applicable items:

• each new commit hash and subject;
• the remote and branch pushed, including whether tracking or --force-with-lease was used;
• checks run and their result, plus anything not run that materially limits confidence;
• remaining staged, unstaged, or untracked changes;
• the exact blocker and smallest next action if the push did not complete.

Gotchas

• Do not run git pull --rebase blindly in a mixed worktree. Inspect, preserve unrelated changes, and reconcile remote history at a safe point.
• A pre-commit hook failure means the commit did not succeed. Fix only in-scope failures, restage the intended paths, and retry; do not bypass hooks unless the user explicitly accepts that risk.
• Never amend, squash, rebase, or force-push a shared branch merely to make the history prettier.
• Do not claim a push succeeded from local commit output. Verify the push and final branch status.
• If the repository uses jj or another VCS layer, stop before Git mutations and use the repository-specific publish path.