Commit and Push Everything

VerifiedCaution

Stages all changes, creates a commit with a conventional message, and pushes to the remote repository after running safety checks for secrets, large files, and build artifacts. Useful for quickly committing and pushing complete sets of related changes, but requires explicit user confirmation before execution.

Sby Skills Guide Bot
DevelopmentIntermediate
6/2/2026
Claude CodeCursorWindsurfCopilotCodex
#git#commit#push#version-control#safety-checks

Recommended for

Automated summary

Stages all changes, creates a commit with a conventional commit message, and pushes to the remote repository after safety checks and user confirmation.

Strengths

  • Automates the entire commit-and-push workflow in one step.
  • Includes safety checks for secrets, large files, and build artifacts.
  • Generates a conventional commit message based on the changes detected.
  • Requires explicit user confirmation before executing actions.

Limitations

  • Commits all changes at once; not suitable for granular commits.
  • Relies on user vigilance for security checks.
  • Only works with standard Git repositories.
When to use it

When you are confident that all uncommitted changes belong together and you want a fast, automated commit and push with built-in safety checks.

When not to use it

When you need selective staging, when working on a protected branch that requires pull requests, or when secrets or large files should not be committed.

Security analysis

Caution
Quality score88/100

The skill uses only git commands (safe in themselves) but orchestrates a powerful action: committing and pushing all unstaged changes. It includes security checks for secrets, large files, and artifacts, and requires explicit confirmation, reducing but not eliminating the risk of accidental exposure. No network exfiltration or destructive system commands are present.

Findings
  • •Automates staging and pushing all changes, which could accidentally push sensitive data if the user bypasses warnings.
  • •Relies entirely on user confirmation; a careless 'yes' could still result in exposure.
How this analysis is made

Examples

Commit and push everything
I'm sure, commit and push all my changes with a meaningful commit message.
Stage all and push with safety
Run the commit and push workflow, but make sure to check for secrets first.

description: Stage all changes, create commit, and push to remote (use with caution) allowed-tools: Bash(git add:), Bash(git status:), Bash(git commit:), Bash(git push:), Bash(git diff:), Bash(git log:), Bash(git pull:*)

Commit and Push Everything

⚠️ CAUTION: Stage ALL changes, commit, and push to remote. Use only when confident all changes belong together.

Workflow

1. Analyze Changes

Run in parallel:

  • git status - Show modified/added/deleted/untracked files
  • git diff --stat - Show change statistics
  • git log -1 --oneline - Show recent commit for message style

2. Safety Checks

❌ STOP and WARN if detected:

  • Secrets: .env*, *.key, *.pem, credentials.json, secrets.yaml, id_rsa, *.p12, *.pfx, *.cer
  • API Keys: Any *_API_KEY, *_SECRET, *_TOKEN variables with real values (not placeholders like your-api-key, xxx, placeholder)
  • Large files: >10MB without Git LFS
  • Build artifacts: node_modules/, dist/, build/, __pycache__/, *.pyc, .venv/
  • Temp files: .DS_Store, thumbs.db, *.swp, *.tmp

API Key Validation: Check modified files for patterns like:

OPENAI_API_KEY=sk-proj-xxxxx  # ❌ Real key detected!
AWS_SECRET_KEY=AKIA...         # ❌ Real key detected!
STRIPE_API_KEY=sk_live_...    # ❌ Real key detected!

# ✅ Acceptable placeholders:
API_KEY=your-api-key-here
SECRET_KEY=placeholder
TOKEN=xxx
API_KEY=<your-key>
SECRET=${YOUR_SECRET}

✅ Verify:

  • .gitignore properly configured
  • No merge conflicts
  • Correct branch (warn if main/master)
  • API keys are placeholders only

3. Request Confirmation

Present summary:

📊 Changes Summary:
- X files modified, Y added, Z deleted
- Total: +AAA insertions, -BBB deletions

🔒 Safety: ✅ No secrets | ✅ No large files | ⚠️ [warnings]
🌿 Branch: [name] → origin/[name]

I will: git add . → commit → push

Type 'yes' to proceed or 'no' to cancel.

WAIT for explicit "yes" before proceeding.

4. Execute (After Confirmation)

Run sequentially:

git add .
git status  # Verify staging

5. Generate Commit Message

Analyze changes and create conventional commit:

Format:

[type]: Brief summary (max 72 characters)

- Key change 1
- Key change 2
- Key change 3

Types: feat, fix, docs, style, refactor, test, chore, perf, build, ci

Example:

docs: Update concept README files with comprehensive documentation

- Add architecture diagrams and tables
- Include practical examples
- Expand best practices sections

6. Commit and Push

git commit -m "$(cat <<'EOF'
[Generated commit message]
EOF
)"
git push  # If fails: git pull --rebase && git push
git log -1 --oneline --decorate  # Verify

7. Confirm Success

✅ Successfully pushed to remote!

Commit: [hash] [message]
Branch: [branch] → origin/[branch]
Files changed: X (+insertions, -deletions)

Error Handling

  • git add fails: Check permissions, locked files, verify repo initialized
  • git commit fails: Fix pre-commit hooks, check git config (user.name/email)
  • git push fails:
    • Non-fast-forward: git pull --rebase && git push
    • No remote branch: git push -u origin [branch]
    • Protected branch: Use PR workflow instead

When to Use

✅ Good:

  • Multi-file documentation updates
  • Feature with tests and docs
  • Bug fixes across files
  • Project-wide formatting/refactoring
  • Configuration changes

❌ Avoid:

  • Uncertain what's being committed
  • Contains secrets/sensitive data
  • Protected branches without review
  • Merge conflicts present
  • Want granular commit history
  • Pre-commit hooks failing

Alternatives

If user wants control, suggest:

  1. Selective staging: Review/stage specific files
  2. Interactive staging: git add -p for patch selection
  3. PR workflow: Create branch → push → PR (use /pr command)

⚠️ Remember: Always review changes before pushing. When in doubt, use individual git commands for more control.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/commit-and-push-everything-mm5t8ahv/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/commit-and-push-everything-mm5t8ahv' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/commit-and-push-everything-mm5t8ahv/download' --output '.skill-downloads/commit-and-push-everything-mm5t8ahv/SKILL.md.part' && mv '.skill-downloads/commit-and-push-everything-mm5t8ahv/SKILL.md.part' '.skill-downloads/commit-and-push-everything-mm5t8ahv/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

Tools declared by the author (check availability in your agent): Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git push:*), Bash(git diff:*), Bash(git log:*), Bash(git pull:*)

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

This file does not provide a usable name/description header for this native procedure. It remains available to download and inspect; use the manual method below.

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/commit-and-push-everything-mm5t8ahv/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills