Claude Cursor Skill

writing-shell

Imported from alexei-led/cc-thingz/dist/pi/skills/writing-shell.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download alexei-led-cc-thingz-dist_pi_skills_writing-shell-ce56bb4.zip · 2 KB
Part of alexei-led/cc-thingz — 91 skills

Install

skills CLI npx skills add https://github.com/alexei-led/cc-thingz/tree/master/dist/pi/skills/writing-shell
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install alexei-led-cc-thingz@llmmart
Git git clone https://github.com/alexei-led/cc-thingz.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole alexei-led/cc-thingz collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Shell Development

In GitHub Actions, this skill owns the shell inside run: blocks; operating-infra owns the workflow YAML around it (jobs, permissions, actions, secrets, caching). Mixed changes use both.

Shell Choice

  • Follow the existing shebang and tooling. New portable scripts: POSIX sh for simple logic; Bash when you need arrays, pipefail, [[ ]], or regex.
  • Zsh and Fish only for existing files, interactive config, or explicit requests.
  • Never rely on the agent's own shell. Name the shell in the shebang, and invoke it explicitly in tests.
  • Shell is glue. Move data modeling, business logic, or CPU-heavy work to the project's real language.

Safety and Portability

  • Bash: set -euo pipefail, knowing it does not fire inside conditionals or &&/|| lists. POSIX sh: set -eu and explicit pipeline checks.
  • Build commands with arrays, never strings plus eval. Put -- before user-controlled operands.
  • NUL- or newline-safe loops for filenames; never parse ls or use for x in $(cmd).
  • mktemp plus a cleanup trap for temp files, locks, and partial outputs.
  • No curl | sh: download, verify, then run.
  • Destructive actions list their targets first and require confirmation unless the script runs non-interactively with explicit inputs.
  • macOS/BSD vs GNU: avoid sed -i, date -d, readlink -f, and GNU-only grep flags unless the dependency is documented. Prefer printf to echo.
  • Every shellcheck disable carries a short reason.

CLI Tools

  • Use non-interactive, pipe-friendly tools with stable stdout and exit codes: no TUI, pager, color, or prompts when output is consumed.
  • Parse structured data with jq, yq, mlr, or dasel, not grep/sed scraping. Search with rg and fd.
  • Preview replacements before applying them (sd -p, rg --replace).
  • Check for non-standard tools and fail with a clear message. Never install them silently.
  • Look up exact flags with looking-up-docs instead of guessing.

References

  • testing.md: gate commands (shfmt, ShellCheck, checkbashisms, Bats, ShellSpec) and test design; read when adding tests or choosing checks.

Done when the relevant build/test/lint checks pass on what you changed, or you name each check that did not run and why.

Files (cc-thingz)
  • references
    • testing.md 990 B
      # Shell Testing and Quality Gates
      
      ## Gates
      
      ```bash
      shfmt -d script.sh
      shellcheck script.sh          # set --shell when the shebang is missing
      checkbashisms script.sh       # /bin/sh scripts that claim POSIX
      bats tests/                   # Bash-heavy projects
      shellspec                     # POSIX or multi-shell behavior
      ```
      
      - Semgrep shell rules for scripts that handle secrets, downloads, deletion, permissions, or user input.
      - `bashate` only when the project already runs it. `shellharden` rewrites can change behavior; use it only with tests and a diff review.
      
      ## Test Design
      
      - Drive the script through its entrypoint. Assert exit status, stdout, stderr, and changed files.
      - Cover invalid input, a missing dependency, an unsafe path, and failure propagation.
      - Work in temp directories. Never touch the real home, git config, cloud, or system state.
      - Pin `PATH`, locale, env vars, and working directory so tests are deterministic. Use `PATH` fixtures to stub external commands.
      
  • SKILL.md 3.1 KB
    ---
    {"description":"Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, CI `run:` shell bodies, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, Rust, TypeScript, Go, web code, or GitHub Actions workflow/job/permissions semantics; use operating-infra.","name":"writing-shell"}
    ---
    <!-- Pi platform guidance -->
    <!-- Use installed Pi tool names exactly, including extension toolsets such as Task*, Monitor*, and Loop*. -->
    <!-- When available, track work with Task* (`todo` is the fallback), run long or background commands with MonitorCreate, and schedule follow-up with LoopCreate instead of sleep/poll loops. -->
    
    
    # Shell Development
    
    In GitHub Actions, this skill owns the shell inside `run:` blocks; operating-infra owns the workflow YAML around it (jobs, permissions, actions, secrets, caching). Mixed changes use both.
    
    ## Shell Choice
    
    - Follow the existing shebang and tooling. New portable scripts: POSIX `sh` for simple logic; Bash when you need arrays, `pipefail`, `[[ ]]`, or regex.
    - Zsh and Fish only for existing files, interactive config, or explicit requests.
    - Never rely on the agent's own shell. Name the shell in the shebang, and invoke it explicitly in tests.
    - Shell is glue. Move data modeling, business logic, or CPU-heavy work to the project's real language.
    
    ## Safety and Portability
    
    - Bash: `set -euo pipefail`, knowing it does not fire inside conditionals or `&&`/`||` lists. POSIX sh: `set -eu` and explicit pipeline checks.
    - Build commands with arrays, never strings plus `eval`. Put `--` before user-controlled operands.
    - NUL- or newline-safe loops for filenames; never parse `ls` or use `for x in $(cmd)`.
    - `mktemp` plus a cleanup `trap` for temp files, locks, and partial outputs.
    - No `curl | sh`: download, verify, then run.
    - Destructive actions list their targets first and require confirmation unless the script runs non-interactively with explicit inputs.
    - macOS/BSD vs GNU: avoid `sed -i`, `date -d`, `readlink -f`, and GNU-only `grep` flags unless the dependency is documented. Prefer `printf` to `echo`.
    - Every `shellcheck disable` carries a short reason.
    
    ## CLI Tools
    
    - Use non-interactive, pipe-friendly tools with stable stdout and exit codes: no TUI, pager, color, or prompts when output is consumed.
    - Parse structured data with `jq`, `yq`, `mlr`, or `dasel`, not `grep`/`sed` scraping. Search with `rg` and `fd`.
    - Preview replacements before applying them (`sd -p`, `rg --replace`).
    - Check for non-standard tools and fail with a clear message. Never install them silently.
    - Look up exact flags with looking-up-docs instead of guessing.
    
    ## References
    
    - [testing.md](references/testing.md): gate commands (shfmt, ShellCheck, checkbashisms, Bats, ShellSpec) and test design; read when adding tests or choosing checks.
    
    Done when the relevant build/test/lint checks pass on what you changed, or you name each check that did not run and why.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related