writing-shell

Name: writing-shell
Author: alexei-led

35stars5forks

How to install writing-shell?

alexei-led/cc-thingz/writing-shell

$npx -y skills add alexei-led/cc-thingz --skill writing-shell

Installs into the current project.

Summary

Use for shell scripts, hooks, CI shell blocks, command pipelines, and local automation glue. - In GitHub Actions, own the shell code inside run: blocks. Use operating-infra for workflow YAML structure, jobs, permissions, runners, actions, secrets, caching, concurrency,

Files · 1

View on GitHub

SKILL.md

1	# Shell Development
2
3	## Scope
4
5	- Use for shell scripts, hooks, CI shell blocks, command pipelines, and local automation glue.
6	- In GitHub Actions, own the shell code inside `run:` blocks. Use
7	`operating-infra` for workflow YAML structure, jobs, permissions, runners,
8	actions, secrets, caching, concurrency, and policy. Mixed changes compose both
9	skills.
10	- Do not use for cloud, Kubernetes, Terraform, host, or network operations; use `operating-infra`.
11	- Do not use for application logic that belongs in Python, Rust, Go, TypeScript, or another project language.
12
13	## Read references
14
15	- Read [patterns.md](references/patterns.md) before non-trivial scripts or pipelines.
16	- Read [tools.md](references/tools.md) when choosing external CLI tools or parsing structured data.
17	- Read [testing.md](references/testing.md) before adding or changing shell tests or quality gates.
18
19	## Defaults
20
21	- Follow the existing shebang, shell, style, and project tooling first.
22	- For new portable scripts, use POSIX `sh` when the logic is simple; use Bash when arrays, `pipefail`, regex, or richer functions are needed.
23	- Use Zsh or Fish only for existing files or explicit user intent. Keep Fish/Zsh config separate from portable scripts.
24	- Do not rely on the agent's current shell. Put the intended shell in the shebang or invoke it explicitly in tests.
25	- Prefer small shell scripts that call stable tools. Move complex data modeling or business logic to a real language.
26
27	## Core rules
28
29	- Quote expansions unless word splitting is intentional and documented by structure.
30	- Avoid `eval`, `curl \| sh`, parsing `ls`, unguarded globbing, and unsafe `rm`/`mv`/`cp` paths.
31	- Use arrays for arguments in Bash; use newline/NUL-safe loops for filenames.
32	- Use `mktemp` plus cleanup traps for temporary files and directories.
33	- Check required external commands when a script depends on them. Do not install tools silently.
34	- Account for macOS/BSD versus GNU flag differences when writing portable scripts.
35	- Prefer machine-readable output from tools, then parse it with structured parsers.
36	- Use `looking-up-docs` for exact external CLI flags, syntax, or version behavior; do not guess from memory.
37
38	## Comments
39
40	- Comment only tricky, non-obvious, important, or unusual shell behavior.
41	- Use file and function comments for reusable scripts or functions when the contract is not obvious from names and usage.
42	- Add a short reason after any `shellcheck disable` directive.
43	- Keep comments short. Move longer rationale to docs, issue links, or design notes.
44	- Do not comment obvious commands or narrate each pipeline stage.
45	- Keep shell tests readable without comments; add one only for unobvious fixtures, environment setup, portability constraints, or regression context.
46
47	## Verification
48
49	Run the project-configured shell gates. Prefer:
50
51	- formatting: `shfmt`
52	- linting: `shellcheck`; `checkbashisms` for POSIX `sh`
53	- tests: Bats for Bash-heavy projects; ShellSpec for POSIX or multi-shell behavior
54	- security/policy: Semgrep shell rules when the script handles secrets, downloads, deletion, or user-controlled input
55
56	If a tool is unavailable or unconfigured, state the gap and run the closest available check. If a check fails, quote the diagnostic, fix the cause, and rerun the relevant check.
57
58	## Final response
59
60	Include:
61
62	- changed files
63	- shell target used: POSIX sh, Bash, Zsh, or Fish
64	- checks run and results
65	- checks skipped with reasons
66	- remaining portability or safety risks

People who liked this also viewed

6 picks

Type

writing-shell

35stars5forks

View on GitHub

How to install writing-shell?

alexei-led/cc-thingz/writing-shell

$npx -y skills add alexei-led/cc-thingz --skill writing-shell

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Shell Development
2
3	## Scope
4
5	- Use for shell scripts, hooks, CI shell blocks, command pipelines, and local automation glue.
6	- In GitHub Actions, own the shell code inside `run:` blocks. Use
7	`operating-infra` for workflow YAML structure, jobs, permissions, runners,
8	actions, secrets, caching, concurrency, and policy. Mixed changes compose both
9	skills.
10	- Do not use for cloud, Kubernetes, Terraform, host, or network operations; use `operating-infra`.
11	- Do not use for application logic that belongs in Python, Rust, Go, TypeScript, or another project language.
12
13	## Read references
14
15	- Read [patterns.md](references/patterns.md) before non-trivial scripts or pipelines.
16	- Read [tools.md](references/tools.md) when choosing external CLI tools or parsing structured data.
17	- Read [testing.md](references/testing.md) before adding or changing shell tests or quality gates.
18
19	## Defaults
20
21	- Follow the existing shebang, shell, style, and project tooling first.
22	- For new portable scripts, use POSIX `sh` when the logic is simple; use Bash when arrays, `pipefail`, regex, or richer functions are needed.
23	- Use Zsh or Fish only for existing files or explicit user intent. Keep Fish/Zsh config separate from portable scripts.
24	- Do not rely on the agent's current shell. Put the intended shell in the shebang or invoke it explicitly in tests.
25	- Prefer small shell scripts that call stable tools. Move complex data modeling or business logic to a real language.
26
27	## Core rules
28
29	- Quote expansions unless word splitting is intentional and documented by structure.
30	- Avoid `eval`, `curl \| sh`, parsing `ls`, unguarded globbing, and unsafe `rm`/`mv`/`cp` paths.
31	- Use arrays for arguments in Bash; use newline/NUL-safe loops for filenames.
32	- Use `mktemp` plus cleanup traps for temporary files and directories.
33	- Check required external commands when a script depends on them. Do not install tools silently.
34	- Account for macOS/BSD versus GNU flag differences when writing portable scripts.
35	- Prefer machine-readable output from tools, then parse it with structured parsers.
36	- Use `looking-up-docs` for exact external CLI flags, syntax, or version behavior; do not guess from memory.
37
38	## Comments
39
40	- Comment only tricky, non-obvious, important, or unusual shell behavior.
41	- Use file and function comments for reusable scripts or functions when the contract is not obvious from names and usage.
42	- Add a short reason after any `shellcheck disable` directive.
43	- Keep comments short. Move longer rationale to docs, issue links, or design notes.
44	- Do not comment obvious commands or narrate each pipeline stage.
45	- Keep shell tests readable without comments; add one only for unobvious fixtures, environment setup, portability constraints, or regression context.
46
47	## Verification
48
49	Run the project-configured shell gates. Prefer:
50
51	- formatting: `shfmt`
52	- linting: `shellcheck`; `checkbashisms` for POSIX `sh`
53	- tests: Bats for Bash-heavy projects; ShellSpec for POSIX or multi-shell behavior
54	- security/policy: Semgrep shell rules when the script handles secrets, downloads, deletion, or user-controlled input
55
56	If a tool is unavailable or unconfigured, state the gap and run the closest available check. If a check fails, quote the diagnostic, fix the cause, and rerun the relevant check.
57
58	## Final response
59
60	Include:
61
62	- changed files
63	- shell target used: POSIX sh, Bash, Zsh, or Fish
64	- checks run and results
65	- checks skipped with reasons
66	- remaining portability or safety risks

People who liked this also viewed

6 picks

Type