---

name: push-all description: Stage all changes, run quality gates (lint/typecheck), safety checks (secrets/large files), commit, and push to remote version: "1.0.0" license: MIT compatibility: opencode

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

Config File	Project Type	Lint Command	Typecheck Command
package.json	Node.js	Parse scripts for: lint, eslint	Parse scripts for: typecheck, type-check, tsc
pyproject.toml	Python	ruff check . (if [tool.ruff])	mypy . (if [tool.mypy])
Cargo.toml	Rust	cargo clippy	cargo check
go.mod	Go	go vet ./...	(included in vet)
composer.json	PHP	Parse scripts for: lint, phpcs	./vendor/bin/phpstan (if exists)
Gemfile	Ruby	bundle exec rubocop	bundle exec sorbet tc (if sorbet)
deno.json	Deno	deno lint	deno check *.ts
biome.json	Biome	npx biome check .	(included in check)

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.