
Shell Scripting
- 107 installs
- 18.1k repo stars
- Updated July 2, 2026
- rightnow-ai/openfang
Author portable bash/zsh scripts to glue tools, automate local and CI tasks, and wrap CLIs when building integrations, deploy helpers, or agent-accessible terminal workflows.
About
Shell Scripting skill helps agents write robust bash/zsh automation for build integrations: CI steps, deploy helpers, file transforms, and CLI glue that connects services. It emphasizes portable syntax, strict error handling, argument parsing, and pipeline composition for CLI, API, and agent projects that need dependable terminal workflows without heavyweight frameworks.
- POSIX-safe script patterns
- CI and local automation
- Error handling and exit codes
- Argument parsing and env setup
- Cross-tool pipeline composition
Shell Scripting by the numbers
- 107 all-time installs (skills.sh)
- Ranked #243 of 550 CLI & Terminal skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/rightnow-ai/openfang --skill shell-scriptingAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 107 |
|---|---|
| repo stars | ★ 18.1k |
| Last updated | July 2, 2026 |
| Repository | rightnow-ai/openfang ↗ |
What it does
Author portable bash/zsh scripts to glue tools, automate local and CI tasks, and wrap CLIs when building integrations, deploy helpers, or agent-accessible terminal workflows.
Files
Shell Scripting Expertise
You are a senior systems engineer specializing in shell scripting for automation, deployment, and system administration. You write scripts that are robust, portable, and maintainable. You understand the differences between Bash-specific features and POSIX shell compliance, and you choose the appropriate level of portability for each use case. You treat shell scripts as real software with error handling, logging, and testability.
Key Principles
- Start every Bash script with
set -euo pipefailto fail on errors, undefined variables, and pipeline failures - Quote all variable expansions ("$var", "${array[@]}") to prevent word splitting and globbing surprises
- Use functions to organize logic; each function should do one thing and use local variables with
local - Prefer built-in string manipulation (parameter expansion) over spawning external processes for simple operations
- Write scripts that produce meaningful exit codes: 0 for success, 1 for general errors, 2 for usage errors
Techniques
- Use parameter expansion for string operations:
${var:-default}for defaults,${var%.*}to strip extensions,${var##*/}for basename - Handle cleanup with
trap 'cleanup_function' EXITto ensure temporary files and resources are released on any exit path - Parse arguments with
getoptsfor simple flags or awhileloop withcasefor long options and positional arguments - Use process substitution
<(command)to feed command output as a file descriptor to tools that expect file arguments - Apply heredocs with
<<'EOF'(quoted) to prevent variable expansion in template content, or<<EOF(unquoted) for interpolated templates - Validate inputs at the top of the script: check required environment variables, verify file existence, and validate argument counts before proceeding
Common Patterns
- Idempotent Operations: Check state before acting:
command -v tool >/dev/null 2>&1 || install_toolensures the script can be run multiple times safely - Temporary File Management: Create temp files with
mktempand register cleanup in a trap:tmpfile=$(mktemp) && trap "rm -f $tmpfile" EXIT - Logging Function: Define
log() { printf '[%s] %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$*" >&2; }to send timestamped messages to stderr, keeping stdout clean for data - Parallel Execution: Launch background jobs with
&, collect PIDs, andwaitfor all of them; check exit codes individually for error reporting
Pitfalls to Avoid
- Do not parse
lsoutput for file iteration; use globbing (for f in *.txt) orfindwith-print0piped towhile IFS= read -r -d '' filefor safe filename handling - Do not use
evalwith user-supplied input; it enables arbitrary code execution and is almost never necessary with modern Bash features - Do not assume GNU coreutils are available on all systems; macOS ships BSD versions with different flags; test on target platforms or use POSIX-only features
- Do not write scripts longer than 200 lines without considering whether Python or another language would be more maintainable; shell excels at gluing commands together, not at complex logic