/auto-push

name: auto-push
description: "Generate a commit message, stage all changes, and push to remote after scanning for secrets, large files, and protected-branch risks. Skip for opening PRs, code review, or cutting releases/tags."
license: MIT
effort: low
metadata:
  version: 1.1.1
  author: "Luong NGUYEN <luongnv89@gmail.com>"

Commit and Push Everything

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

When to Use

Trigger this skill when the user asks to "commit and push everything", "ship this", "auto-push", or otherwise wants a one-shot stage-commit-push for the current working tree. Skip when they want PRs, code review, releases, or tags.

Prerequisites

• `git` is installed and the current directory is inside a git repository.
• An `origin` remote exists, and the user can push to it.
• `git config user.name` and `user.email` are set, so `git commit` can run.

Repo Sync Before Edits (mandatory)

Before creating/updating/deleting files in an existing repository, sync the current branch with remote:

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

If the working tree is not clean, stash first, sync, then restore:

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

If `origin` is missing, pull is unavailable, or rebase/stash conflicts occur, stop and ask the user before continuing.

Instructions

Step 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

Step 2: Run Safety Checks

**❌ Record a finding 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}

**✅ Also check:** 1. `.gitignore`: no path from `git status --porcelain` matches a secret, build-artifact, or temp-file pattern above. If one does, record it as a finding and suggest the `.gitignore` entry. 2. Merge conflicts: `git diff --name-only --diff-filter=U` prints nothing. If it prints a path, record a finding. 3. Branch: if the current branch is `main` or `master`, record a finding. 4. API keys: every `*_API_KEY`, `*_SECRET`, or `*_TOKEN` value in the changed files is a placeholder. If one is a real value, record a finding.

Each match in the first list above is also a finding. A safety check fails when it records at least one finding.

Step 3: Confirm and Execute

1. Print the dry-run preview below. If a safety check failed, end it with the findings instead of the `Proceeding now` line. 2. If every safety check passed, continue to Step 4. Do not ask a yes/no question. 3. If any safety check failed, list each finding and stop. Continue only after the user explicitly confirms every non-blocking finding and item 4 clears every blocking one. Never bypass a failed safety check without that confirmation. 4. Confirmation does not clear a blocking finding:

• **Secret** (a secret-file match or a real API-key value): continue only when the user states that the match is a false positive, such as a placeholder, test fixture, or example value. For a real secret, stop and tell the user to remove it from the change and rotate it, then re-run `/auto-push`.
• **Large file** (>10 MB without Git LFS): stop. Continue only after a re-run of Step 2 no longer finds the file, because it is tracked with Git LFS, deleted, or listed in `.gitignore`.

📊 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]

Proceeding now: git add . → commit → push

Step 4: Stage Files

Run this step only when no blocking finding from Step 3 remains, so `git add .` never stages a secret or a large file. Run sequentially:

git add .
git status --porcelain

Check that every path listed in Step 1 is now staged. If a path is missing, or a path appears that the safety checks did not cover, stop and report it.

Step 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

Step 6: Commit and Push

git commit -m "$(cat <<'EOF'
[Generated commit message]
EOF
)"
git push
git log -1 --oneline --decorate

• If `git commit` fails (for example, a pre-commit hook), print the hook output and stop. Do not retry.
• If `git push` is rejected as non-fast-forward, run `git pull --rebase && git push` once. If the rebase conflicts or the second push fails, stop and report.
• If `git push` succeeds, check that `git log -1 --oneline --decorate` shows the new commit on `origin/[branch]`.

Step 7: Report the Result

Print the report shown in Expect