linux-script-developer
Linux Script Developer
Production-ready Bash. Strict mode + input validation + cross-platform.
When to use
- The user asks for any
.shscript, installer, automation, or CLI wrapper. - The user wants to harden, refactor, or review an existing Bash script.
- A task chain ends in "and put it in a shell script".
Required structure
Every script you write starts from this skeleton. Do not omit set -euo pipefail or the main "$@" invocation.
#!/usr/bin/env bash
set -euo pipefail
readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly SCRIPT_NAME="$(basename "$0")"
# Colors only when stdout is a TTY (avoids garbage in pipes/CI logs)
if [ -t 1 ]; then
RED='\033[0;31m'; GREEN='\033[0;32m'; YELLOW='\033[1;33m'; BLUE='\033[0;34m'; NC='\033[0m'
else
RED=''; GREEN=''; YELLOW=''; BLUE=''; NC=''
fi
usage() {
cat <<EOF
Usage: $SCRIPT_NAME [OPTIONS] <args>
EOF
exit "${1:-0}"
}
main() {
[ "$#" -ge 1 ] || { echo -e "${RED}Error: missing args${NC}" >&2; usage 1; }
# logic here
}
main "$@"
Workflow
- Pick a starting template from
assets/templates/— copy and edit, do not rewrite from scratch:script.template.sh— basic single-purpose script.cli-tool.template.sh— multi-subcommand CLI (init / build / deploy style).file-processor.template.sh— batch operations over files.
- Apply the patterns in
references/patterns.mdfor any non-obvious case (traps, getopts, template processing, while-read loops). Read it on demand — don't preload it. - Validate the result. Run
bash scripts/validate-script.sh <your-script.sh>— it grep-scans the script and checks shebang, strict mode, header comment,usage/mainpatterns, quoted positional args, noeval, no hardcoded user-home paths, TTY-guarded ANSI codes, GNU-only flags, and stderr redirection. Aim for ≥ 90%. - Cross-check against the gotchas in
references/anti-patterns.mdbefore finishing — especially unquoted vars, hardcoded paths, and missing input validation. - For cross-platform scripts (running on macOS or Windows), load
references/cross-platform.mdand apply the relevant rules (sed-i'',readlink -freplacements,grep -Enot-P). - Generate man-page-style reference docs for the script using the template in
references/documentation.md. Always do this — either inline as a markdown block or as a sibling<script>.md.
Available resources
assets/templates/{script,cli-tool,file-processor}.template.sh— starting points.assets/examples/scaffold-example.sh— full reference implementation.scripts/validate-script.sh— score a script against the checklist (run after writing).references/patterns.md— load when implementing error handling, parsing, traps, templates, loops.references/anti-patterns.md— load when reviewing or rewriting an existing script.references/cross-platform.md— load when targeting macOS or Windows alongside Linux.references/documentation.md— load when generating script reference docs.
Top gotchas (always inline — do not skip)
- Quote everything.
cat $filebreaks on spaces; alwayscat "$file". set -euo pipefailis the minimum.-eexits on error,-uon undefined vars,pipefailpropagates pipe failures.#!/usr/bin/env bash, never#!/bin/bash. macOS ships an old Bash at/bin/bash; Alpine uses/bin/sh.- Validate args before using them. Fail loudly with a clear message and
usage, not a crypticunbound variable. - Use
[ -t 1 ]before emitting ANSI codes so output is clean when piped or in CI logs. - Use
${SCRIPT_DIR}/ relative paths, never hardcode/home/user/.... - Trap cleanup on EXIT/ERR when creating temp files:
trap 'rm -f "$TMP"' EXIT. - macOS
sed -irequires an empty string:sed -i'' -e 's/a/b/' fileworks on both macOS and Linux.
What you DO
- Start every script from
assets/templates/. - Use
set -euo pipefailfrom the first line of logic. - Quote every variable expansion:
"$var","$@","${arr[@]}". - Validate every input — count, type, file existence — before using it.
- Emit colored messages only when
[ -t 1 ]. - Use functions for any logic block over ~5 lines; keep
main()thin. - Use
${SCRIPT_DIR}and relative paths; never hardcode absolute paths outside the user's project. - Trap cleanup on
EXIT/ERRwhen you create temp files or background processes. - Run
scripts/validate-script.shon the result; iterate until ≥ 90%. - Generate man-page-style reference documentation alongside the script (see
references/documentation.md). - Test cross-platform tooling differences (see
references/cross-platform.md) when the script will run anywhere besides the author's machine.
What you do NOT do
- Skip
set -e, leave bareexcept/no error handling, or useeval/bash -c "$user_input". - Use unquoted variables, hardcoded absolute paths, or
cdwithout a guard. - Use GNU-only flags (
grep -P,date -d,readlink -f,mktemp --suffix) without a portable fallback. - Write monolithic scripts with logic outside functions, or skip the
usagefunction. - Emit ANSI color codes unconditionally — they pollute logs and pipes.
More from mkabumattar/skills
skill-builder
Build a new Agent Skill that follows the agentskills.io specification and best practices — slim `SKILL.md` (≤ 200 lines / 5K tokens), valid kebab-case `name`, imperative `description` under 1024 chars, progressive disclosure via `references/`, bundled `assets/` and `scripts/`, and an MIT `LICENSE`. Use this skill whenever the user asks to create, scaffold, build, write, or author a new Agent Skill — including phrasings like "build a skill for X", "scaffold a new skill", "create an agent skill", "make me a skill that does X", "write a SKILL.md for ...", or "I want to publish a skill on agentskills.io". Also use when reviewing or refactoring an existing oversized `SKILL.md` (a sign that detail should be moved to `references/`).
15python-script-developer
Write production-ready Python CLI tools, automation scripts, and batch file processors with type hints, structured `logging` (never `print` for diagnostics), `argparse` interfaces, `pathlib` for filesystem work, specific exception handling, and cross-platform support (Linux, macOS, Windows). Use this skill whenever the user asks to create a Python script, `.py` utility, CLI tool, automation, batch processor, or data pipeline — including casual phrasings like "write a python script that ...", "automate this in python", "I need a small tool", or "give me a one-off processor". Also use when reviewing or hardening an existing Python script.
15information-architecture
Plan the structural and execution architecture of a feature, app, or site — produce both an `INFORMATION_ARCHITECTURE.md` (site map, navigation, content hierarchy, user flows, URL strategy, naming conventions, component reuse map) AND a phased `PLAN.md` (phases by impact/effort/risk, vertical-slice tasks with sub-tasks, dependencies, estimates, and a detailed task breakdown with Why/How/Impact/Effort). Use this skill whenever the user wants to plan a product or feature, design site structure, lay out information architecture, map user flows, organize content, break work into phases, build a roadmap, plan an implementation order, or hits you with phrases like "plan the IA", "map the structure", "break this into tasks", "give me a roadmap", "phase out the work", "create an enhancement plan", or "what should I build first". Also use when reviewing or refactoring an existing IA or project plan.
15makefile-script-developer
Write production-ready GNU Makefiles with strict shell mode (`SHELL := /bin/bash` + `.SHELLFLAGS := -euo pipefail -c`), validated multi-environment configuration via `$(filter ...)`, pre-flight check targets (`check-tools`, `check-env`), structured logging with timestamps, confirmation gates for destructive ops, layered `.env` includes, platform detection, and self-documenting help. Use this skill whenever the user asks to write a Makefile, harden an existing one, add a target, build a deploy/release pipeline, automate Terraform/Helm/Kubernetes/Docker/build workflows, or expose tasks as `make <target>` — including casual phrasings like "write a Makefile", "add a make target", "automate this in make", "give me a build pipeline", or "clean up the Makefile". Also use when reviewing an existing Makefile for safety, error handling, or organization issues.
15qa
Run an interactive QA session — the user describes bugs and issues conversationally, you ask brief clarifying questions, explore the codebase for domain context, decide whether to file one issue or break it down, and create durable user-focused GitHub issues via `gh issue create` — without referencing internal file paths or line numbers. Use this skill whenever the user wants to do QA, report bugs, file issues, walk through a list of problems, or hits you with phrases like "let's do a QA session", "I found a bug", "this is broken", "file this as an issue", "I have a few things to report", or "let's go through these one by one". Also use when the user is reviewing a deployed feature and wants to track defects.
14gitops-pipeline-developer
Author production-ready GitOps release pipelines (Jenkins-style by default; portable patterns for GitHub Actions, GitLab CI, Drone) that combine Gitflow branching, Conventional Commits, automatic SemVer bumping, a SonarQube quality gate, Grype container image scanning, and an aggregated quality+security scorecard with policy alignment checks. Use this skill whenever the user wants to write or harden a CI/CD pipeline, set up a release flow, automate versioning, enforce conventional commits, gate merges on SonarQube, scan images with Grype, build a release scorecard, or hits you with phrases like "set up the CI", "write me a Jenkinsfile", "add SonarQube", "enforce conventional commits", "wire SemVer", "scan our images for CVEs", "add a quality gate", "CI for this repo", or "I need a release pipeline".
14