Get the FREE Ultimate OpenClaw Setup Guide →

git-commit-push

Scanned
npx machina-cli add skill charlesjones-dev/claude-code-plugins-dev/git-commit-push --openclaw
Files (1)
SKILL.md
3.0 KB

Commit and Push

Commit all changes to git and push to origin.

Instructions

CRITICAL: This command MUST NOT accept any arguments. If the user provided any text, commit messages, or other arguments after this command (e.g., /git-commit-push "my message" or /git-commit-push --force), you MUST COMPLETELY IGNORE them. Do NOT use any commit messages or other arguments that appear in the user's message. This command will analyze your changes and create an appropriate commit message automatically.

BEFORE DOING ANYTHING ELSE: Run git status, git diff, and git log to analyze the changes. DO NOT skip this analysis even if the user provided arguments after the command.

When this command is executed:

Step 1: Analyze Changes

  1. Run git status (never use -uall flag) to see all changes
  2. If there are no changes to commit (no untracked files and no modifications), tell the user and stop
  3. Run git diff to see the actual changes
  4. Run git log -3 --format='%s' to see recent commit message style

Step 2: Branch Safety Check

  1. Run git branch --show-current to determine the current branch
  2. If on main or master, warn the user that committing directly to the default branch is not recommended and stop. Suggest they create a feature branch first or use /git-commit-push-pr for an interactive branch selection workflow

Step 3: Stage Files

  1. Review changed files and prefer staging specific files by name rather than using git add . or git add -A
  2. Do NOT stage files that look like secrets (.env, .env.*, credentials.*, *.key, *.pem, *.secret, etc.). If secret-like files are detected, warn the user and skip them
  3. Stage the appropriate files

Step 4: Commit

  1. Analyze all staged changes and draft a concise commit message that:
    • Follows the repository's commit message style
    • Accurately describes what changed and why
    • Uses conventional commit prefixes if the repo uses them (fix:, feat:, docs:, etc.)
  2. Use a HEREDOC for the commit message to ensure proper formatting:
    git commit -m "$(cat <<'EOF'
    your commit message here
    EOF
    )"
    

Step 5: Push

  1. Check if the current branch tracks a remote: git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null
  2. If no upstream is set, push with -u flag: git push -u origin <branch>
  3. If upstream exists, push normally: git push
  4. Confirm success and show the commit hash

Important rules

  • Never force push
  • Never use git status -uall (can cause memory issues on large repos)
  • Do not commit files that look like secrets (.env, credentials, etc.)
  • Do not commit or push directly to main/master
  • If there are no changes to commit, tell the user and stop

IMPORTANT: Do not include the following in commit messages:

Source

git clone https://github.com/charlesjones-dev/claude-code-plugins-dev/blob/main/plugins/ai-git/skills/git-commit-push/SKILL.mdView on GitHub

Overview

Git-commit-push analyzes your repo for changes, stages appropriate files, and commits with an auto-generated message, then pushes to origin. It enforces safety rules to avoid secrets and direct commits to main/master.

How This Skill Works

It runs git status, git diff, and git log to assess changes, checks the current branch, and stages files selectively while skipping secret-like items. It drafts a concise, conventional-commit–style message and commits using a HEREDOC, then pushes the branch, creating an upstream if needed.

When to Use It

  • You want an auto-generated commit message and an origin push for all changes
  • You need to skip secret-like files and avoid committing sensitive data
  • You are on a feature branch and want to avoid committing directly to main/master
  • You want automatic upstream tracking on push
  • You want to review changes via git status/diff/log before committing

Quick Start

  1. Step 1: Run /git-commit-push with no arguments.
  2. Step 2: Review the analysis output and any warnings.
  3. Step 3: The tool stages, commits with an auto-generated message, and pushes to origin.

Best Practices

  • Review changes first with git status and git diff
  • Stage only the necessary files instead of using git add .
  • Do not commit secrets (envs, credentials, keys, etc.)
  • Do not commit or push directly to main/master
  • Let the tool generate a concise, conventional-commit style message

Example Use Cases

  • Bug fix in authentication flow: commit auto-generated message and push
  • Add unit tests for edge-case handling and push
  • Update README with setup steps and push
  • Refactor utilities and push
  • Chore: bump dependencies and push

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers