What this prompt does
This prompt generates a production-grade Bash script that performs a [script_purpose], runs on [target_os], and handles [input_type]. It encodes a real hardening checklist: strict mode with set -euo pipefail, a cleanup trap on EXIT, INT, and TERM, argument parsing with --verbose, --dry-run, --config, and --help, structured logging to stdout and [log_file], input validation, progress indicators, and exponential-backoff retries for [retry_operations].
The variables steer what the script automates and how defensively it behaves. [script_purpose] and [input_type] define the core task, [log_file] sets where structured logs land, and [retry_operations] tells the model which steps are flaky enough to wrap in retry logic. The fixed exit-code summary (0 success, 1 general, 2 missing dependencies, 3 permission denied) makes the script's outcomes scriptable by callers.
When to use it
- Writing automation that must survive on a production box without leaving a mess
- Backup or deploy scripts where a half-finished run leaving temp files or stale locks is dangerous
- You want strict mode and a cleanup trap as non-negotiable defaults
- Adding structured, timestamped logging with INFO, WARN, and ERROR levels
- Operations like
[retry_operations]that need exponential backoff on transient failure - You need consistent exit codes so a calling system can react to failures
Example output
You get a single well-commented Bash script: a strict-mode header, a usage function, getopts-based flag parsing, a logging helper writing to stdout and [log_file], a validation block checking files, permissions, disk space, and dependencies via command -v, the core logic for [script_purpose], a retry function, and a final exit-code summary. Inline comments explain the non-obvious idioms.
Pro tips
- Make
[script_purpose]specific (for example "back up PostgreSQL to S3 with compression and encryption") so validation and retry logic target the right steps - Always test the
--dry-runpath first; a destructive[script_purpose]is exactly where you want to preview actions before running for real - Point
[log_file]somewhere writable by the run user, or add a fallback — a log path you cannot write to defeats the structured logging - Wrap only genuinely flaky steps in retries via
[retry_operations]; retrying a logic error just delays the failure - Verify the cleanup trap covers temp files and locks;
set -ecan exit mid-run, and the trap is what prevents stale state - Keep the exit-code contract intact so cron or a CI job can distinguish a missing dependency (2) from a permission problem (3)
- Validate dependencies up front with command -v checks so the script fails fast with a clear message instead of dying halfway through with a cryptic command-not-found
- Use the structured logging levels deliberately: reserve ERROR for conditions that abort the run, and let WARN cover recoverable issues, so scanning
[log_file]after a failure points straight at the cause rather than burying it in noise
