# Commit Push

> Finalize local git changes into one or more logical commits and optionally push the current branch. Trigger when the user asks to commit, split changes into commits, prepare commit messages, push, or commit+push, including phrases like "закоммить", "закомить", "разбей на коммиты", "сделай коммиты", "подготовь коммиты", "запушь", "коммит+пуш", "commit", "push", "commit and push", or similar. Inspect the working tree, split changes into coherent commit groups, follow the repository's existing commit message style, create the commits, and push once at the end if the user asked to push. Do not use for rebase, merge conflict resolution, revert, cherry-pick, stash management, release tagging, branch renaming, or PR writing.

- Skill: `kirillklem/commit-push` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kirillklem/commit-push`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kirillklem/commit-push/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: KirillKlem (https://skillmd.com/u/kirillklem)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/kirillklem/commit-push

---


# Commit Push

## Purpose

Take the current repository state and turn it into a clean end-of-task git result:
- one or more logical commits
- good commit messages
- one final push if requested

This is an end-of-task workflow for local repository changes that are already implemented.

## Use when

Use this skill when the user wants any of the following:
- commit current work
- split the diff into logical commits
- write proper commit messages
- commit and push
- just push, when local changes may still need to be committed first

Typical trigger phrases:
- "закоммить"
- "разбей на коммиты"
- "сделай нормальные commit messages"
- "запушь"
- "коммит+пуш"
- "commit"
- "push"
- "commit and push"

## Do not use when

Do not use this skill for:
- rebase / interactive rebase
- merge conflict resolution
- cherry-pick
- revert
- stash workflows
- release tagging / version bump releases
- PR title or PR description writing
- history rewriting of existing commits unless the user explicitly asks

If the user asks for any of the above, handle that directly instead of using this skill.

## Inputs

Expected inputs:
- current git repository
- local working tree and index state
- the user's intent:
  - commit only
  - push only
  - commit and push

Optional inputs:
- repository commit message convention
- branch policy from project docs
- `AGENTS.md` repo conventions

## Outputs

Always produce:
1. a short commit plan
2. the actual commits created, with SHAs and messages
3. push result, if push was requested
4. any skipped files or blocked actions

## Constraints

- Read the nearest repo-local `AGENTS.md`, `README`, or workflow docs before changing history behavior.
- Use non-interactive git commands by default.
- Stage precisely; do not sweep unrelated dirty files into a commit.
- Respect existing user changes and do not rewrite history unless explicitly requested.
- Prefer exact staging by file or hunk over blunt "add everything" flows.
- If push target is ambiguous or high-risk, stop and report instead of guessing.

## Procedure

1. Inspect repository state first.
   Run the narrowest commands needed to understand the current state, typically:
   - `git status --short --branch`
   - `git diff --stat`
   - `git diff`
   - `git diff --cached`
   - `git log --oneline -n 20`

2. Infer the commit message convention.
   - Look at recent commit messages.
   - If the repo clearly uses a convention such as Conventional Commits, follow it.
   - Otherwise use concise, precise, imperative commit subjects.
   - Prefer messages that describe the actual behavior or code change, not vague phrases like "fix stuff".

3. Build a commit slicing plan before staging.
   Split the changes into the smallest reasonable set of coherent commits.
   A good commit should represent one logical unit, for example:
   - one bug fix
   - one refactor
   - one feature slice
   - one test addition tied to the same behavior change

4. Follow these slicing rules.
   - Keep tests with the behavior change they validate.
   - Keep docs with the code change only when the docs directly describe that same change.
   - Do not create micro-commits with no independent value.
   - Do not mix unrelated changes into one commit just because they touch nearby files.
   - If unrelated dirty files exist, leave them out unless the user clearly asked to include everything.

5. Stage precisely.
   - Prefer exact staging by file or hunk.
   - Use patch-based staging when needed.
   - Verify the staged diff before every commit.

6. Create commits one by one.
   For each logical group:
   - stage only the intended hunks/files
   - verify staged diff
   - write a strong commit message
   - commit
   - continue until the plan is complete

7. Handle push based on user intent.
   - If the user asked only to commit, stop after commits are created.
   - If the user asked to push, push once at the end, not after every commit.
   - If the working tree is already clean and the branch is ahead, just push.
   - If there is nothing to commit and nothing to push, report a no-op.

8. Push safety rules.
   - Prefer pushing the currently checked out branch.
   - If upstream is configured, use the normal push flow.
   - If upstream is missing and there is exactly one obvious remote/branch target, set upstream and push.
   - If the target is ambiguous, stop and report the exact command that should be run next.
   - Do not push directly to protected or high-risk branches such as `main`, `master`, `release`, or `prod`
     unless the user explicitly asked for that branch.

9. Verification before finishing.
   Before finalizing, check:
   - working tree state after commits
   - branch ahead/behind status
   - created commit list
   - push result, if requested

## Decision rules

### If the user says only "push"

Interpret this as:
- if there are uncommitted local changes, first organize them into logical commits, then push
- if the tree is clean and local commits are ahead, push
- if nothing needs pushing, report that clearly

### If there are multiple plausible ways to split the diff

Choose the cleanest minimal plan that preserves semantic coherence.
Bias toward fewer strong commits over many weak commits.

### If tests are available

Run the narrowest relevant tests when cheap and obvious.
If tests are not run, say that explicitly in the final report.

## Definition of done

- The repository state was inspected before staging.
- The commit slicing plan is coherent and reflects the actual diff.
- Created commits have clear messages and are semantically grouped.
- Push was performed once at the end if requested, or clearly skipped/blocked.
- The final report includes SHAs, messages, push result, and any skipped files or blocked actions.

## Final response format

Return a compact summary in this structure:

- Intent: commit / commit+push / push
- Commit plan:
  - commit 1: ...
  - commit 2: ...
- Created commits:
  - `<sha>` — `<message>`
  - `<sha>` — `<message>`
- Push:
  - pushed / not requested / blocked / no-op
- Notes:
  - skipped files
  - ambiguity handled
  - tests run or not run

## Positive examples

Use this skill for prompts like:
- "Закоммить изменения"
- "Разбей это на логичные коммиты"
- "Сделай нормальные commit messages и запушь"
- "Commit and push this branch"
- "Подготовь коммиты и потом push"

## Negative examples

Do not use this skill for prompts like:
- "Сделай rebase на origin/main"
- "Resolve merge conflicts"
- "Откати последний коммит"
- "Сделай cherry-pick этого коммита"
- "Напиши PR description"