developing-posix-shell-scripts skill¶
Do not use Bash-specific features. See references/common.md for the full list of bash-isms to avoid.
Step 1 - Classify the Script¶
Audit flags before classifying. Ask for each proposed flag: would a real caller ever pass a different value, or can it be a readonly constant? Beyond that, apply common sense - not everything that could vary should be a flag. Internal paths, fixed timeouts, log levels for non-CLI tools, and similar values are typically hardcoded in practice even if they could theoretically differ. When reviewing an existing script, re-classify from scratch; the current number of flags is not evidence of correct classification.
Simple - all of: < 50 lines of logic, 0-2 genuine flags, no structured logging, no -h/help output, no resource cleanup, not shared across systems/environments.
Complex - any of: >= 50 lines, 3+ genuine flags, structured logging, -h/help output, resource cleanup, shared across systems/environments.
When in doubt, prefer Simple.
Step 2 - Follow the Reference Document¶
Load references/common.md first, then load the matching document:
- references/developing-simple-posix-shell-scripts.md - Load this when classified as Simple.
- references/developing-complex-posix-shell-scripts.md - Load this when classified as Complex. Also load references/reference-code-blocks.md to compose only the blocks the script actually needs.