home / skills / benchflow-ai / skillsbench / git-pushing

git-pushing skill

/registry/terminal_bench_2.0/full_batch_reviewed/terminal_bench_2_0_configure-git-webserver/environment/skills/git-pushing

This skill helps you stage, commit, and push changes with conventional messages, ensuring consistent history and easy remote collaboration.

npx playbooks add skill benchflow-ai/skillsbench --skill git-pushing

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.2 KB
---
name: git-pushing
description: Stage, commit, and push git changes with conventional commit messages. Use when user wants to commit and push changes, mentions pushing to remote, or asks to save and push their work. Also activates when user says "push changes", "commit and push", or similar git workflow requests.
---

# Git Push Workflow

Stage all changes, create a conventional commit, and push to the remote branch.

## When to Use

Automatically activate when the user:
- Explicitly asks to push changes ("push this", "commit and push")
- Mentions saving work to remote ("save to github", "push to remote")
- Completes a feature and wants to share it
- Says phrases like "let's push this up" or "commit these changes"

## Workflow

### 1. Check Git Status

Run `git status` to understand:
- Which files have changed
- What will be committed
- Current branch name

### 2. Stage Changes

- Run `git add .` to stage all changes
- Alternatively, stage specific files if partial commit is needed

### 3. Create Commit Message

**If user provided a message:**
- Use it directly

**If no message provided:**
- Analyze changes using `git diff`
- Generate a conventional commit message:
  - Format: `type(scope): description`
  - Types: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`
  - Keep description concise (50-90 characters)
  - Use imperative mood: "Add" not "Added"
- Always append Claude Code footer:
  ```
  šŸ¤– Generated with [Claude Code](https://claude.com/claude-code)

  Co-Authored-By: Claude <[email protected]>
  ```

**Use heredoc format:**
```bash
git commit -m "$(cat <<'EOF'
commit message here

šŸ¤– Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>
EOF
)"
```

### 4. Push to Remote

- Run `git push` to push commits
- If push fails due to diverged branches, inform user and ask how to proceed

### 5. Confirm Success

- Report commit hash
- Summarize what was committed
- Confirm push succeeded

## Examples

User: "Push these changes"
→ Check status, stage all, generate commit message, push

User: "Commit with message 'fix: resolve table extraction issue'"
→ Use provided message, push

User: "Let's save this to github"
→ Activate workflow, generate appropriate commit message

Overview

This skill stages, commits, and pushes Git changes using conventional commit messages. It activates when you ask to save or push work, or say phrases like "push changes" or "commit and push." It returns the commit summary and confirms the push result.

How this skill works

The skill inspects the current repository state with git status and analyzes diffs when no commit message is provided. It stages changes (all or specific files), creates a conventional commit message (type(scope): description) or uses the user-provided message, appends the required footer, and runs git push. If the push fails due to diverged branches, it reports the problem and asks how you want to proceed.

When to use it

  • When you explicitly ask to push changes (e.g., "push this" or "commit and push").
  • When you mention saving work to a remote repository ("save to github", "push to remote").
  • After completing a feature or fix and you want to share it to the remote branch.
  • When you want a conventional, consistent commit message generated automatically.

Best practices

  • Run git status first to review staged and unstaged changes before pushing.
  • Provide a clear commit message when you can; otherwise let the skill generate one from the diff using conventional commit types (feat, fix, refactor, docs, test, chore).
  • Use git add on specific files if you only want a partial commit rather than git add .
  • If push fails due to divergence, prefer to rebase or merge locally and test before forcing a push; confirm strategy when prompted.
  • Keep commit descriptions concise (50–90 characters) and use imperative mood (e.g., "Add parsing for X").

Example use cases

  • User: "Push these changes" → stages all, generates a conventional commit, pushes, and reports the commit hash.
  • User: "Commit with message 'fix: resolve table extraction issue'" → uses provided message, commits, and pushes.
  • User: "Save this to GitHub" → inspects changes, crafts an appropriate conventional commit if needed, pushes to remote, and confirms success.
  • Partial workflow: user says "only commit src/ and tests/" → stages listed files, generates or uses message, commits, and pushes.

FAQ

What commit message format is used if I don't provide one?

A conventional commit format: type(scope): description. Types include feat, fix, refactor, docs, test, chore. Description is concise and imperative.

Will the skill push automatically to the remote branch?

Yes. It runs git push after committing. If the remote has diverged, it stops and asks how you want to resolve the conflict.

Does the skill include an attribution footer in commits?

Yes. When generating commits it appends the required Claude Code footer and Co-Authored-By line using a heredoc commit command as specified.