GitHub Copilot Bash & Workflow Standards
This skill enforces strict coding standards for bash scripting, GitHub Actions workflows, musl-based toolchain builds, and QEMU debugging. It ensures AI contributions are precise, minimal, and correct without scope creep.
Instructions
General Principles
1. **Scope Control**: Only implement what the prompt explicitly requests. Never add generalized changes, future-proofing, or speculative features outside the prompt scope.
2. **Minimal & Modular**: Keep solutions simple, modular, and focused. Avoid over-engineering.
3. **Readability First**: Think like a C developer: stable, concise, elegant, thoughtful. Prefer readable code over clever one-liners unless the style guide promotes it.
4. **Staged Changes**: Make changes in small, modular stages. Keep functions focused.
5. **Error Handling**: Handle errors explicitly (per function is acceptable). Return helpful, actionable messages.
6. **Comments**: Add concise comments explaining intent and non-obvious logic.
---
Bash Scripting Standards (All Repos)
**Do:**
Use `#!/bin/bash` as the shebang for Bash scriptsUse `.bash` extension for Bash scripts; `.sh` only for POSIX-only scriptsPrefer `$BASH_SOURCE` over `$0` for script path detectionUse `printf '%s'` for plain strings and `printf '%b'` for escape sequences. **Never use `echo`**Format using [Google Shell Style Guide](https://google.github.io/styleguide/shellguide.html)Consult [mywiki.wooledge.org](https://mywiki.wooledge.org) and [BashFAQ](https://mywiki.wooledge.org/BashFAQ) for Bash referencesProvide source links when possible (but never fabricate links)**Avoid:**
Global `set -euo pipefail`; prefer targeted checks and explicit error handlingUppercase variable names for general scripting (reserve for Docker/env settings only)Clever one-liners that harm clarityGeneralized or speculative changes not requested in the promptOver-engineering---
GitHub Workflows (All Repos)
1. **Job Dependencies**: In reusable workflows, any job using outputs from another job **must** declare that job in `needs` to avoid null outputs
2. **Action Versions**: Do not use outdated Actions. Always verify current recommended versions before editing
3. **Workflow Run IDs**: The `gh` CLI cannot fetch the ID of a workflow run it just started via `gh run workflow`. List runs afterward and extract the ID
---
Musl Cross-Make Toolchain Specifics
**For repos matching `*-musl-cross-make`:**
**Toolchain Configuration:**
Use both `-static` and `--static` to produce static toolchain binaries (using only `-static` can miss POSIX threads)When using `../config.mak`, always load options from both `../gcc-configure-options.md` and `../gcc-configure-options-recursive.md`The binutils gold linker is deprecated. Use `ld=default` and `--disable-gold`**Fully Static Toolchains with musl:**
**Do not** use LTO: avoid `-flto` and `-fuse-linker-plugin`**Do not** add any LTO-related settingsOnly set linker options such as `LDFLAGS` at link time, not during library buildsGNU libtool redefines `-static`; to ensure static linking, use `--static` or `-Wl,-static` (optionally with `-static`) in `LDFLAGS`For static OpenSSL: **do not** use `openssl -static` (it disables threads/PIE/PIC). For `-static-pie` with musl/Alpine, use correct flags**Do not** use glibc-only flags or glibcisms for musl toolchains---
QEMU Debugging
**To debug with QEMU:**
1. Start target under QEMU with gdbstub:
```bash
qemu -g 1234 ./binary
```
2. In another terminal, attach with gdb:
```bash
gdb ./binary
target remote :1234
```
---
qBittorrent-nox-static Installer (`qi.bash`)
**For repos matching `*qbittorrent-nox-static`:**
**General Requirements:**
Shebang must be `#!/bin/bash`Simple installer that verifies installation and binaries**OS Detection:**
Source `/etc/os-release`Supported: `ID=alpine`, `ID=debian`, or `ID_LIKE` contains `debian`Exit with clear reason if unsupported**Transfer Tools:**
Prefer `curl` if present; use `wget` if `curl` not availableExit if neither is availableDetect `gh` CLI presence (optional, not required)**Architecture Detection:**
Alpine: `apk --print-arch`Debian-like: `dpkg --print-architecture`Exception: `armhf` = `armv7` on Debian, `armv6` on AlpineExit with reason if invalid architecture**Download Function:**
Build download URL from detected architectureCreate and store SHA-256 sum of download**Attestation (Optional):**
When `gh` CLI available and usable: ```bash
gh attestation verify <INSTALL_PATH> --repo <REPO> 2> /dev/null
```
**Error Handling:**
Provide helper that checks command exit codesExit with concise, helpful message on failure**Output Formatting:**
Print helper supporting: - `[INFO]` (blue)
- `[WARNING]` (yellow)
- `[ERROR]` (red)
- `[SUCCESS]` (green)
- `[FAILURE]` (magenta)
Use `printf '%s'` and `printf '%b'`; **never use `echo`**Keep messages succinct except errors (be verbose for troubleshooting)---
Example Usage
When asked to "add error handling to the download function":
Add targeted error checks only to the download functionUse explicit exit codes and messagesDo not refactor unrelated codeDo not add global error handling unless requestedWhen asked to "create a new workflow":
Check current Action versionsAdd explicit `needs` declarations for jobs using outputsDo not add speculative future jobs---
Constraints
**Never expand scope** beyond the prompt**Never fabricate** URLs or documentation links**Never add** placeholders or future-proofing unless requiredIf something cannot be done with available context, state why and propose the smallest viable alternative