writing-shell

# Shell Development ## Scope - Use for shell scripts, hooks, CI shell blocks, command pipelines, and local automation glue. - Do not use for cloud, Kubernetes, Terraform, host, or network operations; use `operating-infra`. - Do not use for application logic that belongs in Python, Go, TypeScript, or another project language. ## Read references - Read [patterns.md](references/patterns.md) before non-trivial scripts or pipelines. - Read [tools.md](references/tools.md) when choosing external CLI tools or parsing structured data. - Read [testing.md](references/testing.md) before adding or changing shell tests or quality gates. ## Defaults - Follow the existing shebang, shell, style, and project tooling first. - For new portable scripts, use POSIX `sh` when the logic is simple; use Bash when arrays, `pipefail`, regex, or richer functions are needed. - Use Zsh or Fish only for existing files or explicit user intent. Keep Fish/Zsh config separate from portable scripts. - Do not rely on the agent's current shell. Put the intended shell in the shebang or invoke it explicitly in tests. - Prefer small shell scripts that call stable tools. Move complex data modeling or business logic to a real language. ## Core rules - Quote expansions unless word splitting is intentional and documented by structure. - Avoid `eval`, `curl | sh`, parsing `ls`, unguarded globbing, and unsafe `rm`/`mv`/`cp` paths. - Use arrays for arguments in Bash; use newline/NUL-safe loops for filenames. - Use `m...