Git Pushing Fast

Git Pushing Fast

Overview

Commit and push the current repository's local changes on the current branch with a fast, safe single-branch workflow.

The default output is one focused Conventional Commit plus a push to the tracked remote branch. Analyze the actual diff, stage the requested change set, generate the commit message from the change content, and write a segmented body for non-trivial changes so reviewers can quickly see what changed by topic.

This workflow handles ordinary single-branch handoff requests such as saving current work to the remote, without branch merging, history rewriting, or PR creation.

Conventional Commit Rules

Base format:

<type>[optional scope]: <description>

[body: optional only for trivial changes; required and segmented for non-trivial changes]

[footer(s): required for breaking changes; optional for relevant issue references]

For this skill, the body is optional only for trivial commits. For non-trivial changes, write a segmented body and include a Tests: or localized equivalent section when tests, validators, hooks, or manual verification ran.

Types:

Breaking changes:

• Use ! after the type or scope, such as feat(api)!: remove legacy field.
• Add a BREAKING CHANGE: footer when the behavioral contract changes.

Message style:

• Use the repository's existing commit language.
• Write the subject in present tense and imperative mood, such as fix login redirect.
• Keep the subject under 72 characters when practical.
• Reference issues in the body or footer when relevant, such as Closes #123 or Refs #456.

When to Use

Use this skill when the user asks to:

• Commit and push the current work
• Push this, save to remote, or finish a normal single-branch handoff
• Create one Conventional Commit from staged and unstaged changes
• Include a readable commit body that groups changes by feature area, UI area, tests, docs, or validation

Do Not Use

Do not use this skill for:

• Multi-branch flows that merge a work branch into a primary branch
• Force-push, rebase, squash, amend, or history-rewrite requests
• Pull request creation unless the user explicitly asks for it after the push
• Code review, release notes, weekly reports, or changelog generation
• Destructive commands such as git reset --hard or git checkout -- <file>

Instructions

Follow this workflow in order. Stop and report the blocker instead of guessing when the target repository, branch, or push destination is unclear.

1. Inspect the repository.

   • Run git status --short, git branch --show-current, and git remote -v.
   • Check the upstream with git rev-parse --abbrev-ref --symbolic-full-name @{u} when possible.
   • Review the staged diff with git diff --cached --stat and git diff --cached; if nothing is staged, review git diff --stat and git diff.
   • Use git status --porcelain when script-friendly status parsing is useful.
   • Never discard or revert user changes.

2. Stage changes.

   • If the user asked to commit everything, run git add -A.
   • If the user requested a narrower scope, stage only that scope.
   • Use file-specific adds, path patterns, or git add -p only when the requested scope requires logical grouping.
   • Re-run git status --short and verify the intended files are staged.
   • Never leave known secrets staged for commit, including .env, credential files, private keys, or tokens.

3. Build the commit message.

   • Use Conventional Commits: type(scope): concise summary in the repository's existing commit language.
   • Choose the type and scope from the actual diff, not from filenames alone.
   • For non-trivial changes, include a segmented body with 2-5 short sections.
   • Each section title should name the affected area, followed by bullet points.
   • Include a Tests: or localized equivalent section when tests, validators, hooks, or manual verification ran.

Example segmented body:

fix(module): update component behavior

Behavior:
- Adjust the default state for the affected component.
- Keep existing behavior unchanged for unsupported input.

Implementation:
- Move repeated logic into a small helper.
- Update related configuration to use the new helper.

Tests:
- Add coverage for the updated behavior.
- Run the relevant validator before pushing.

4. Commit.

   • Use git commit with multiple -m arguments or an editor-free equivalent so the body is preserved.
   • Do not use --no-verify.
   • If hooks or validation fail, fix the failure and retry the commit.

5. Push.

   • If the current branch has an upstream, run git push.
   • If there is no upstream, run git push -u origin <current_branch> unless the repository or user specifies another remote.
   • If the push is rejected because the remote moved, run git fetch and inspect before retrying.
   • Do not force-push unless the user explicitly requested force-push and the risk has been confirmed.
   • Never force-push to main or master.

6. Report.

   • Keep the final response concise.
   • Include the commit hash, branch, remote push result, and validation that ran.
   • If the host app supports Git directives, emit them only after the matching action succeeds.

Safety Protocol

• Never update global or system Git config.
• Never run destructive commands such as git reset --hard or git checkout -- <file> unless explicitly requested.
• Never skip hooks.
• Never commit secrets.