Push All Skill

Stage all changes, run quality gates, perform safety checks, and push to remote.

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

Unique Value (Not in Superpowers)

This skill provides capabilities not found in standard Superpowers:

• •Quality Gates: Automatic lint/typecheck verification per project type (Node.js, Python, Rust, Go, PHP, Ruby, Deno, Biome)
• •Safety Checks: Secrets detection, large file warnings, build artifact exclusion
• •Multi-project Support: Handles monorepos with multiple languages

Integration with Superpowers

This skill is called by superpowers/finishing-a-development-branch for:

• •Option 1: Push and create PR
• •Option 2: Merge locally (quality gates before merge)

Workflow

1. Analyze Changes

Run the following commands in parallel to gather information:

git status
git diff --stat
git log -1 --oneline

2. Quality Gates (Lint/Typecheck)

Detect project type and run quality checks before pushing.

Detection Strategy

Check for config files in priority order (stop at first match per type):

# Quick detection
ls package.json pyproject.toml Cargo.toml go.mod composer.json Gemfile deno.json biome.json 2>/dev/null

Project-Specific Gates

Hard Gate Policy

No bypass mechanism - if gates fail, the push is blocked. This ensures:

• •Code quality standards are maintained
• •Type safety is enforced
• •Linting rules are followed
• •No broken code reaches the repository

To proceed after failure:

1. •Fix the reported errors
2. •Re-run the push-all command
3. •Gates will re-check automatically

3. Safety Checks

❌ STOP and WARN if any of the following are detected:

Secrets (file patterns to check):

• •.env*, *.key, *.pem, credentials.json, secrets.yaml, id_rsa, *.p12, *.pfx, *.cer

API Keys (check for real values in modified files):

Patterns that indicate REAL keys (should block):

# Real key patterns:
OPENAI_API_KEY=sk-proj-xxxxx
AWS_SECRET_KEY=AKIA...
STRIPE_API_KEY=sk_live_...
GCP_SA_KEY=eyJhbGci...

Acceptable placeholders (should allow):

API_KEY=your-api-key-here
SECRET_KEY=placeholder
TOKEN=xxx
API_KEY=<your-key>
SECRET=${YOUR_SECRET}

Large files: Check for any file >10MB without Git LFS

Build artifacts to exclude:

• •node_modules/, dist/, build/, __pycache__/, *.pyc, .venv/

Temp files:

• •.DS_Store, thumbs.db, *.swp, *.tmp

✅ Verify:

• •.gitignore properly configured
• •No merge conflicts present
• •Correct branch (warn if committing directly to main/master)

4. Request Confirmation

Present summary to user:

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

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

I will: git add . → commit → push

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

WAIT for explicit "yes" from the user before proceeding.

5. Stage Changes

After confirmation:

git add .
git status  # Verify staging

6. Generate Commit Message

Analyze the changes and create a conventional commit message:

Format:

[type]: Brief summary (max 72 characters)

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

Commit 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

Use Git(haiku) model for generating commit messages:

• •Keep summary under 72 characters
• •Use imperative mood ("add" not "added" or "adds")
• •Reference issues with # if applicable

7. Commit and Push

git commit -m "$(cat <<'EOF'
[Generated commit message]
EOF
)"

git log -1 --oneline --decorate  # Verify commit

git push  # If fails: git pull --rebase && git push

8. Confirm Success

✅ Successfully pushed to remote!

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

Error Handling

git add fails:

• •Check file permissions
• •Check for locked files
• •Verify git repository is initialized

git commit fails:

• •Fix pre-commit hook failures
• •Check git config (user.name, user.email)
• •Resolve merge conflicts if present

git push fails:

• •Non-fast-forward: git pull --rebase && git push
• •No remote branch: git push -u origin [branch]
• •Protected branch: Suggest using PR workflow instead

When to Use

✅ Good for:

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

❌ Avoid when:

• •Uncertain what's being committed
• •Changes contain secrets/sensitive data
• •Committing to protected branches (use PR)
• •Merge conflicts are present
• •Want granular commit history
• •Pre-commit hooks are failing
• •Lint or typecheck errors are present (gates will block)

Alternatives

If the user wants more control, suggest:

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

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