quick-push

name	quick-push
description	Stage all current changes, optionally bump project versions, update changelog, commit with an appropriate message, push the current or new feature branch, and then save session documentation. Use when the user asks to quick push, commit and push everything, ship current changes, or run a full git add/commit/push workflow with session capture.

Quick Push

Guardrails

• Never force push, delete branches, or bypass hooks unless the user explicitly requests it.
• Stop instead of making a partial commit when version bumping, changelog update, checks, commit, rebase, or push fails.
• If the working tree is clean, report that there is nothing to commit and stop.
• If on main or master, create a descriptive feature branch before committing.
• Respect user changes; do not revert unrelated work.

Workflow

1. Orient:
   • Run git branch --show-current, git status --short, git remote -v, git diff --stat HEAD when HEAD exists, and git log --oneline -5.
   • Determine whether the current branch is new or already tracks a remote.
2. Bump version unless skipped:
   • Skip when the user passed --no-bump.
   • Skip when no supported manifest exists.
   • Skip when the current version is 0.0.0 or 0.0.1.
   • Read the primary version from the first existing manifest in this order: Cargo.toml, package.json, pyproject.toml.
   • Choose bump type from observed changes: breaking API or behavior change means major; new feature or capability means minor; fixes, chores, refactors, tests, docs, and config work mean patch.
   • Update every existing version file: Cargo.toml, package.json, pyproject.toml, .claude-plugin/plugin.json, .codex-plugin/plugin.json, gemini-extension.json.
   • If Rust manifests changed, run cargo check to update Cargo.lock; stop and report if it fails.
   • Report Version: X.Y.Z -> A.B.C (bump type) and list updated files.
3. Update root CHANGELOG.md if present:
   • Locate the most recently documented commit hash in the changelog.
   • Run git log --oneline <sha>..HEAD.
   • If the format is recognizable, add missing commits newest-first and update highlights using the existing style.
   • If the format is unclear, skip rather than guessing.
4. Stage, commit, and push:
   • Run git add ..
   • Write a meaningful commit message that follows repo conventions and matches the bump type when applicable.
   • Include:

     Co-authored-by: Claude <[e-mail]>
     

   • Push with git push -u origin <branch> for new branches; otherwise use git push.
   • If push is rejected because the remote has new commits, run git pull --rebase, resolve conflicts if possible, and retry. Stop and report unresolved conflicts.
5. Save session context:
   • Use the save-to-md skill after push succeeds.
   • Include the session file path in the final response.

Branch Naming

When creating a branch, use a descriptive conventional prefix based on the dominant change:

• feat/<short-name> for new capabilities.
• fix/<short-name> for bug fixes.
• chore/<short-name> for maintenance, config, docs, or scaffolding.
• refactor/<short-name> for internal restructuring without behavior changes.

Final Response

Include:

• Branch name and whether it was newly created.
• Commit SHA and commit subject.
• Remote push target.
• Version bump summary or explicit skip reason.
• Changelog update summary or explicit skip reason.
• Session documentation path.
• Any unfinished tasks and suggested next steps.