
Bash Pro
Install bash-pro when you need production-safe Bash for CI/CD jobs, deploy hooks, and ops automation without eval foot-guns or silent failures.
Overview
bash-pro is an agent skill most often used in Build (also Ship, Operate) that authors and reviews defensive Bash for automation, CI/CD, and ops with strict mode, safe parsing, and test/lint gates.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill bash-proWhat is this skill?
- Defensive strict mode (`set -Eeuo pipefail`) and safe argument parsing as the default baseline
- POSIX-aware portability guidance with explicit limits when Bash-only features are required
- Robust temp files, pipelines, process orchestration, and structured logging for production runs
- Testing with Bats and static analysis with ShellCheck plus shfmt formatting
- CI/CD-oriented workflows with dry-run patterns before destructive operations
- 4-step implementation flow: inputs/outputs/failure modes → strict mode & parsing → defensive logic → Bats + ShellCheck
Adoption & trust: 695 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need shell automation that won't silently corrupt data, hide errors, or break across environments—but most agent-generated scripts skip strict mode, validation, and tests.
Who is it for?
Solo builders maintaining deploy scripts, GitHub Actions steps, backup/cron jobs, or internal CLI wrappers who want ShellCheck-clean, testable shell code.
Skip if: Teams needing POSIX-only `/bin/sh` without Bash extensions, complex business logic better suited to Python/Go, or Windows-native automation where PowerShell is the right tool.
When should I use this skill?
Writing or reviewing Bash scripts for automation, CI/CD, or ops; hardening shell scripts for safety and portability.
What do I get? / Deliverables
You get a hardened Bash script or review with defined failure modes, defensive I/O patterns, and a Bats plus ShellCheck workflow ready to drop into CI or run with dry-run first.
- Reviewed or new Bash script with strict mode and safe parsing
- Suggested Bats test cases and ShellCheck remediation notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Automation scripts are authored while wiring repos and tooling—the canonical shelf is Build → integrations where shell glue connects services, tests, and deploy steps. Integrations subphase covers the scripts that orchestrate builds, hooks, and external commands rather than app business logic in a higher-level language.
Where it fits
Author a release script that tags git, builds artifacts, and uploads with explicit error traps and logged exit codes.
Harden a GitHub Actions step that migrates databases with dry-run and confirmation gates before live runs.
Review a nightly backup cron script for unsafe rm globs, missing pipefail, and missing lock files.
How it compares
Use as a procedural Bash safety playbook—not a substitute for infrastructure-as-code or a hosted CI product.
Common Questions / FAQ
Who is bash-pro for?
bash-pro is for solo and indie developers who write or review Bash for CI/CD, releases, and server ops and want production-grade error handling without relearning shell pitfalls each time.
When should I use bash-pro?
Use it when drafting or reviewing automation during Build integrations wiring, Ship pipeline hardening, or Operate infra scripts—especially before destructive file or deploy actions.
Is bash-pro safe to install?
The skill is marked community-sourced with critical risk because generated scripts can modify systems; review the Security Audits panel on this page and never run destructive commands without dry-run and backups.
SKILL.md
READMESKILL.md - Bash Pro
## Use this skill when - Writing or reviewing Bash scripts for automation, CI/CD, or ops - Hardening shell scripts for safety and portability ## Do not use this skill when - You need POSIX-only shell without Bash features - The task requires a higher-level language for complex logic - You need Windows-native scripting (PowerShell) ## Instructions 1. Define script inputs, outputs, and failure modes. 2. Apply strict mode and safe argument parsing. 3. Implement core logic with defensive patterns. 4. Add tests and linting with Bats and ShellCheck. ## Safety - Treat input as untrusted; avoid eval and unsafe globbing. - Prefer dry-run modes before destructive actions. ## Focus Areas - Defensive programming with strict error handling - POSIX compliance and cross-platform portability - Safe argument parsing and input validation - Robust file operations and temporary resource management - Process orchestration and pipeline safety - Production-grade logging and error reporting - Comprehensive testing with Bats framework - Static analysis with ShellCheck and formatting with shfmt - Modern Bash 5.x features and best practices - CI/CD integration and automation workflows ## Approach - Always use strict mode with `set -Eeuo pipefail` and proper error trapping - Quote all variable expansions to prevent word splitting and globbing issues - Prefer arrays and proper iteration over unsafe patterns like `for f in $(ls)` - Use `[[ ]]` for Bash conditionals, fall back to `[ ]` for POSIX compliance - Implement comprehensive argument parsing with `getopts` and usage functions - Create temporary files and directories safely with `mktemp` and cleanup traps - Prefer `printf` over `echo` for predictable output formatting - Use command substitution `$()` instead of backticks for readability - Implement structured logging with timestamps and configurable verbosity - Design scripts to be idempotent and support dry-run modes - Use `shopt -s inherit_errexit` for better error propagation in Bash 4.4+ - Employ `IFS=$'\n\t'` to prevent unwanted word splitting on spaces - Validate inputs with `: "${VAR:?message}"` for required environment variables - End option parsing with `--` and use `rm -rf -- "$dir"` for safe operations - Support `--trace` mode with `set -x` opt-in for detailed debugging - Use `xargs -0` with NUL boundaries for safe subprocess orchestration - Employ `readarray`/`mapfile` for safe array population from command output - Implement robust script directory detection: `SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd -P)"` - Use NUL-safe patterns: `find -print0 | while IFS= read -r -d '' file; do ...; done` ## Compatibility & Portability - Use `#!/usr/bin/env bash` shebang for portability across systems - Check Bash version at script start: `(( BASH_VERSINFO[0] >= 4 && BASH_VERSINFO[1] >= 4 ))` for Bash 4.4+ features - Validate required external commands exist: `command -v jq &>/dev/null || exit 1` - Detect platform differences: `case "$(uname -s)" in Linux*) ... ;; Darwin*) ... ;; esac` - Handle GNU vs BSD tool differences (e.g., `sed -i` vs `sed -i ''`) - Test scripts on all target platforms (Linux, macOS, BSD variants) - Document minimum version requirements in script header comments - Provide fallback implementations for platform-specific features - Use built-in Bash features over external commands when possible for portability - Avoid bashisms when POSIX compliance is required, document when using Bash-specific features ## Readability & Maintainability - Use long-form options in scripts for clarity: `--verbose` instead of `-v` - Employ consistent naming: snake_case for functions/variables, UPPER_CASE for constants - Add section headers with comment blocks to