# shell-scripting

> Write safe, portable shell scripts (POSIX/Bash) for automation and CI. Use for scripting, tooling, and DevOps glue code.

- Author: Daniel Montero
- Repository: dmonteroh/curated-agent-skills
- Version: 20260208022942
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-08
- Source: https://github.com/dmonteroh/curated-agent-skills
- Web: https://mule.run/skillshub/@@dmonteroh/curated-agent-skills~shell-scripting:20260208022942

---

---
name: shell-scripting
description: "Write safe, portable shell scripts (POSIX/Bash) for automation and CI. Use for scripting, tooling, and DevOps glue code."
category: workflow
---
# Shell Scripting

Provides guidance for writing safe, portable shell scripts for automation, CI helpers, and command-line glue.

## Use this skill when

- Writing Bash or POSIX shell scripts for automation
- Building CI/CD helpers, installers, or local tooling
- Need portable, reliable command-line glue

## Do not use this skill when

- The task requires another language runtime or SDK
- Building interactive TUI apps or rich UIs
- The job is primarily configuration (use native config instead)

## Required inputs

- Target shell (`/bin/sh` POSIX vs. Bash)
- Target platforms (Linux/macOS/containers)
- Expected inputs/outputs and exit codes
- Files or directories the script should touch

## Non-Negotiable Rules

- Default to portable constructs unless Bash is explicitly required.
- Quote variables and paths; avoid unguarded globbing.
- Keep scripts deterministic and idempotent when practical.

## Workflow (Deterministic)

1. Provide scope and portability confirmation.
   - Decision: if the script must run under `/bin/sh`, choose POSIX; otherwise use Bash.
   - Output: a short checklist of constraints (shell, OS, inputs, outputs).
2. Define interface and usage.
   - Decision: if arguments are required, add `getopts` or simple positional parsing.
   - Output: a usage block and example invocation.
3. Apply safety baseline.
   - Decision: use `set -Eeuo pipefail` for Bash; use `set -eu` for POSIX.
   - Output: strict mode, `IFS` handling where needed, and safe quoting patterns.
4. Implement core logic with clear functions/sections.
   - Output: script body with error handling and deterministic behavior.
5. Add verification guidance.
   - Decision: if tests are practical, include simple fixture commands or `bats` examples.
   - Output: a minimal test or verification command list.

## Common pitfalls

- Unquoted variables causing globbing or word-splitting
- Relying on Bash-only features in `/bin/sh`
- Missing cleanup for temporary files
- Using `echo` for data with escapes or `-n` ambiguity

## Examples

**Input**
- "Write a POSIX shell script that copies `.env.example` to `.env` if missing."

**Expected output**
- Provide the script with a usage block and a short verification command:
  - `sh ./copy-env.sh` then `test -f .env`

## Output contract

- Report in the following order:
  - `Summary`: what the script does and target shell.
  - `Assumptions`: any inferred paths, OS, or tools.
  - `Script`: the full script content or file changes.
  - `Usage`: example command line invocation.
  - `Verification`: commands to validate behavior (no network assumptions).

## Reporting format

````text
Summary:
- ...
Assumptions:
- ...
Script:
```sh
...
```
Usage:
- ...
Verification:
- ...
````

## References (Optional)

- Index: `references/README.md`