Git Commit Push

Inspect the current repository changes, derive a concise commit subject that matches the repository convention, commit every current modification on the active branch, and push that branch to origin.

This skill is for execution, not just advice. When it triggers, actually run the git workflow unless the repository state makes that unsafe or impossible.

When To Use

The user asks you to commit the current changes, with or without asking for push
The user wants you to write the commit message from the diff instead of inventing one up front
The user mentions the repo's PR or commit naming convention and wants you to follow it
The user says things like "commit the current branch", "help me commit", "commit and push", "generate a commit message and push", or "send these changes to origin"

Core Behavior

Confirm you are inside a Git repository and detect the active branch with git branch --show-current.
Inspect the working tree before committing:
- git status --short --branch
- git diff --stat
- git diff --cached --stat
- git diff -- . ':(exclude)package-lock.json' or narrower path filters only when needed for readability
If the repository contains .github/PULL_REQUEST_TEMPLATE.MD, read it and treat its PR-title rules as the default commit-subject convention.
Generate a commit subject from the actual changed files and diff content, not from the user prompt alone.
Stage every current modification on the branch with git add -A.
Commit once with the generated message.
Push the current branch to origin with git push origin <current-branch>.

Commit Message Rules

The commit message is formatted as follows: <type>[optional scope]: <description> For example, fix(os/gtime): fix time zone issue

<type> is mandatory and can be one of fix, feat, build, ci, docs, style, refactor, perf, test, chore
- fix: Used when a bug has been fixed.
- feat: Used when a new feature has been added.
- build: Used for modifications to the project build system, such as changes to dependencies, external interfaces, or upgrading Node version.
- ci: Used for modifications to continuous integration processes, such as changes to Travis, Jenkins workflow configurations.
- docs: Used for modifications to documentation, such as changes to README files, API documentation, etc.
- style: Used for changes to code style, such as adjustments to indentation, spaces, blank lines, etc.
- refactor: Used for code refactoring, such as changes to code structure, variable names, function names, without altering functionality.
- perf: Used for performance optimization, such as improving code performance, reducing memory usage, etc.
- test: Used for modifications to test cases, such as adding, deleting, or modifying test cases for code.
- chore: Used for modifications to non-business-related code, such as changes to build processes or tool configurations.
After <type>, specify the affected package name or scope in parentheses, for example, (os/gtime).
The part after the colon uses the verb tense + phrase that completes the blank in
Lowercase verb after the colon
No trailing period
Keep the title as short as possible. ideally under 76 characters or shorter
If there is a corresponding issue, add either fixes #1234 (the latter if this is not a complete fix) to this comment

Examples

Commit message with description and breaking change footer

feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files

Commit message with ! to draw attention to breaking change

feat!: send an email to the customer when a product is shipped

Commit message with scope and ! to draw attention to breaking change

feat(api)!: send an email to the customer when a product is shipped

Commit message with both ! and BREAKING CHANGE footer

feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.

Commit message with no body

docs: correct spelling of CHANGELOG

Commit message with scope

feat(lang): add Polish language

Commit message with multi-paragraph body and multiple footers

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Execution Rules

Commit all current tracked and untracked changes in the working tree, because this skill is for "commit the current state" requests
If there are no changes, say so clearly and stop before commit or push
If git branch --show-current is empty, explain that HEAD is detached and stop unless the user explicitly asks you to commit from detached HEAD
Never use --force, --force-with-lease, or history-rewriting commands unless the user explicitly asks
If push fails because the remote branch moved, report the exact failure and stop instead of auto-rebasing or auto-merging
Do not silently drop files from the commit unless the user asked to exclude them

Suggested Command Flow

bash

git status --short --branch
git diff --stat
git diff --cached --stat
test -f .github/PULL_REQUEST_TEMPLATE.MD && sed -n '1,220p' .github/PULL_REQUEST_TEMPLATE.MD
branch_name=$(git branch --show-current)
git add -A
git commit -m "<generated-subject>"
git push origin "$branch_name"

Inspect git diff --cached again after staging if the pre-stage diff was noisy or if untracked files materially change the scope.

Output Contract

When you use this skill:

Tell the user which branch you committed
Provide the final commit subject you used
Mention that you staged all current changes
Report the push target as origin/<branch>
If commit or push did not happen, explain exactly why

Example

User request:

text

Generate a commit message that follows this repository's convention, then commit and push the current branch

Expected behavior:

Inspect the repo status and diff
Generate a conventional subject from the real changes
Run one commit for the whole current working tree
Push the active branch to origin