bash-master
Expert bash/shell scripting across environments where Bash is available (Linux, macOS, Git Bash on Windows, WSL, containers). This is a Bash-focused skill - it does not provide PowerShell parity; on Windows the target is the Bash interpreter (Git Bash / WSL), not native PowerShell. PROACTIVELY activate for: (1) ANY bash/shell script task, (2) System automation, (3) DevOps/CI/CD scripts, (4) Build/deployment automation, (5) Script review/debugging, (6) Converting commands to scripts. Provides: Google Shell Style Guide compliance, ShellCheck validation, Bash portability across Linux/macOS/WSL/Git Bash/containers, POSIX compliance, security hardening, error handling, performance optimization, testing with BATS, and production-ready patterns. Ensures professional-grade, secure, portable Bash scripts every time.
What this skill does
# Bash Scripting Mastery
## Scope and platform contract
This skill targets **Bash itself**, wherever Bash runs - Linux, macOS, WSL, Git Bash / MSYS2 on Windows, and Bash-based container images. It does not cover **native PowerShell**: a PowerShell script is a different language and should use `powershell-master`. On Windows, `bash-master` assumes the user is running Bash inside Git Bash, WSL, or a similar Bash environment, and addresses the MSYS path-translation quirks that result.
## Repository conventions
Project-level conventions (Windows backslashes in tool calls, documentation discipline, etc.) live in the agent body and the `windows-path-master` plugin. This skill focuses on Bash content; do not duplicate that boilerplate here.
## Quick reference
```bash
#!/usr/bin/env bash
set -euo pipefail # Exit on error, undefined vars, pipe failures
IFS=$'\n\t' # Safe word splitting
# Run shellcheck your_script.sh before deployment.
# Test on every target platform before production.
```
**Bash-portability quick check:**
```bash
# Linux/macOS: Full bash features
# Git Bash (Windows): Most features, some system calls missing (no systemd, /proc differs)
# WSL: Effectively Linux; /mnt/c for Windows filesystem
# Containers: Depends on base image - alpine ships /bin/sh, not bash
# POSIX mode: Use /bin/sh and avoid bashisms
```
## When to use this skill
**Always activate for:**
- Writing or modifying any bash/shell script
- Reviewing or refactoring existing scripts
- Debugging shell script failures
- DevOps automation, CI/CD pipelines, system administration
- Cross-environment Bash portability (Linux <-> macOS <-> WSL <-> Git Bash <-> container)
**Do not use this skill for:**
- PowerShell scripts - use `powershell-master`
- Batch (`.cmd`/`.bat`) scripting
- Generic command help unrelated to scripting
## Core principles
### 1. Safety first
Every script should open with the safety preamble:
```bash
#!/usr/bin/env bash
set -e # Exit on any error
set -u # Exit on undefined variable
set -o pipefail # Catch failures mid-pipeline
set -E # Inherit ERR trap into functions
IFS=$'\n\t' # Avoid word splitting on spaces
readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly SCRIPT_NAME="$(basename "${BASH_SOURCE[0]}")"
```
### 2. POSIX vs Bash
| Need to run on any UNIX `sh` | `#!/bin/sh`, no `[[ ]]`, no arrays, no process substitution |
|--|--|
| Modern Linux/macOS with Bash | `#!/usr/bin/env bash`, prefer `[[ ]]`, arrays, regex |
| Alpine/minimal containers | Either install bash explicitly or write POSIX-compliant `sh` |
### 3. Quoting
```bash
# Always quote expansions
process "$file_path" # correct
process $file_path # word-splitting bug
# Arrays
files=("file 1.txt" "file 2.txt")
process "${files[@]}" # each element kept separate
process "${files[*]}" # joined as one string - usually wrong
```
### 4. ShellCheck
Run `shellcheck` on every script. Only disable warnings with a justification comment: `# shellcheck disable=SC2086 reason: intentional word splitting`.
See `references/best_practices.md` for the full quoting/style table and `references/patterns_antipatterns.md` for the common pitfalls.
## Platform-specific considerations
### Git Bash / MSYS2 (Windows)
Git Bash auto-converts Unix-style arguments to Windows paths. This is the largest single source of cross-platform Bash bugs on Windows.
```bash
# The conversion: /foo becomes C:/Program Files/Git/usr/foo
# Disable per-command:
MSYS_NO_PATHCONV=1 command /path/that/should/stay/unix
# Manual conversion
unix_path=$(cygpath -u "C:\Windows\System32")
win_path=$(cygpath -w "/c/Users/username")
# Detect Git Bash
if [[ "$OSTYPE" == "msys" ]] || [[ "$OSTYPE" == "mingw"* ]]; then
: # Git Bash
fi
case "${MSYSTEM:-}" in
MINGW64|MINGW32|MSYS) : ;; # MSYS2 / Git Bash environment
esac
# Flags that look like paths
command //e //s # double-slash to suppress conversion
command -e -s # or use dash-options
```
Full Git Bash + Windows path notes live in `references/windows-git-bash-paths.md`.
### Linux
GNU coreutils, `/proc`, systemd integration. Detect via `[[ "$OSTYPE" == "linux-gnu"* ]]`.
### macOS
BSD utilities behave differently from GNU. Most common gotchas: `sed -i ''` (empty string required), `date` flags differ, `readlink -f` not available on stock macOS.
```bash
if command -v gsed >/dev/null; then SED=gsed; else SED=sed; fi
```
### WSL
Effectively Linux. The Windows filesystem is mounted at `/mnt/c/`. Detect via `grep -qi microsoft /proc/version`.
### Containers
Alpine images ship only `/bin/sh` (BusyBox). Write POSIX-compliant scripts or `apk add bash`. Container init quirks: PID 1 must reap children and handle signals. Detect via `[ -f /.dockerenv ]` or `[ -n "$KUBERNETES_SERVICE_HOST" ]`.
### Portable platform-detection template
```bash
detect_platform() {
case "$OSTYPE" in
linux-gnu*) echo "linux" ;;
darwin*) echo "macos" ;;
msys*|cygwin*) echo "windows" ;;
*) echo "unknown" ;;
esac
}
```
Full per-platform tables (BSD-vs-GNU coreutils flags, WSL networking, container init patterns) live in `references/platform_specifics.md`.
## Best practices (summary)
The full patterns - function design, error handling, input validation, argument parsing, logging - live in `references/in-depth-patterns.md`. The headline rules:
- One concern per function; locals declared first; validate input; return non-zero on error.
- Constants `UPPER_CASE`; locals `lower_case`; mark immutable values `readonly`.
- Always check exit codes (`if ! cmd`, `||`, traps, or a central `error_exit` helper).
- Validate every external input - empty, format, length, charset.
- Use `getopts` or a `case`-based argument parser; print usage and exit 1 on bad input.
- Use a leveled logger that writes to stderr.
## Security, performance, testing, debugging, advanced patterns
These each have dedicated sections in `references/in-depth-patterns.md`:
| Topic | What it covers |
|--|--|
| Security | Command-injection prevention, path-traversal guards, privilege management, secure temp files |
| Performance | Avoiding subshells, bash built-ins vs externals, process substitution, array ops |
| Testing | BATS unit tests, integration test patterns, CI/CD wiring |
| Debugging | `set -x`, `PS4`, conditional debug helpers, tracing and profiling |
| Advanced patterns | Safe config parsing, parallel processing, signal handling, retries with backoff |
Read that reference any time you need the canonical code template for one of those topics.
## Reference files
- [`references/platform_specifics.md`](references/platform_specifics.md) - Detailed platform differences and workarounds
- [`references/best_practices.md`](references/best_practices.md) - Comprehensive industry standards and guidelines
- [`references/patterns_antipatterns.md`](references/patterns_antipatterns.md) - Common patterns and pitfalls with solutions
- [`references/windows-git-bash-paths.md`](references/windows-git-bash-paths.md) - Git Bash / MSYS path-translation reference
- [`references/in-depth-patterns.md`](references/in-depth-patterns.md) - Function design, security, performance, testing, debugging, advanced patterns
- [`references/resources.md`](references/resources.md) - Official docs, style guides, tooling, and learning links
## Success criteria
A Bash script written with this skill should:
1. Pass `shellcheck` with no warnings
2. Begin with `set -euo pipefail`
3. Quote every variable expansion
4. Print usage on `-h`/`--help`
5. Decompose into testable functions
6. Handle empty input, missing files, and unexpected arguments
7. Run on every target platform (Linux/macOS/WSL/Git Bash/container) where it claims support
8. Match the Google Shell Style Guide
9. Clean up on exit (`trap EXIT`)
10. Be unit-tested with BATS where logic is non-trivial
```bash
# Pre-Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.