|
| 1 | +# AI Coding Guide for This Repo |
| 2 | + |
| 3 | +Purpose: Make AI contributions precise, minimal, and correct. Follow these rules strictly. Do not expand scope beyond the prompt. |
| 4 | + |
| 5 | +## Bash scripting (applies to all repos) |
| 6 | + |
| 7 | +Do |
| 8 | +- Use `#!/bin/bash` as the shebang for Bash scripts. |
| 9 | +- Use the `.bash` extension for Bash; use `.sh` only for POSIX-only scripts. |
| 10 | +- Prefer `$BASH_SOURCE` over `$0` for script path detection. |
| 11 | +- Use `printf '%s'` for plain strings and `printf '%b'` for escape sequences. Avoid `echo`. |
| 12 | +- Keep changes simple, modular, and scoped to the exact prompt. |
| 13 | +- Write readable code; add concise comments explaining intent and non-obvious logic. |
| 14 | +- Handle errors explicitly (per function is acceptable); return helpful, actionable messages. |
| 15 | +- Structure changes in small stages; keep functions focused. |
| 16 | +- Format using Google’s Shell Style Guide: https://google.github.io/styleguide/shellguide.html |
| 17 | +- For Bash references, consult: https://mywiki.wooledge.org and https://mywiki.wooledge.org/BashFAQ and include a source link when possible. Do not invent links. |
| 18 | + |
| 19 | +Avoid |
| 20 | +- Global “set -euo pipefail”; prefer targeted checks and explicit error handling. |
| 21 | +- Uppercase variable names for general scripting (reserve UPPERCASE for Docker/env settings). |
| 22 | +- Clever one-liners that harm clarity. |
| 23 | +- Generalized or speculative changes not asked for in the prompt. |
| 24 | +- Over-engineering; keep it stable, concise, and C-like in mindset. |
| 25 | + |
| 26 | +Scope and behavior |
| 27 | +- Only implement what the prompt requests. |
| 28 | +- Keep solutions minimal and modular; do not add placeholders or future-proofing unless required. |
| 29 | +- When giving Bash/shell answers, add a relevant wooledge link if helpful; never fabricate links. |
| 30 | + |
| 31 | +## GitHub Workflows (all repos) |
| 32 | + |
| 33 | +- In reusable workflows, any job that uses outputs from another job must declare that job in `needs` to avoid null outputs. |
| 34 | +- Do not use outdated Actions. Check for current recommended versions before editing. |
| 35 | +- 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. |
| 36 | + |
| 37 | +## If repo name matches `*-musl-cross-make` |
| 38 | + |
| 39 | +Toolchain specifics |
| 40 | +- Use both `-static` and `--static` to produce static toolchain binaries. Using only `-static` can miss POSIX threads. |
| 41 | +- When using `../config.mak`, always load options from both `../gcc-configure-options.md` and `../gcc-configure-options-recursive.md`. |
| 42 | +- The binutils gold linker is deprecated. Use `ld=default` and `--disable-gold`. |
| 43 | + |
| 44 | +Fully static toolchains with musl |
| 45 | +- Do not use LTO: avoid `-flto` and `-fuse-linker-plugin`. |
| 46 | +- Do not add any LTO-related settings. |
| 47 | +- Only set linker options such as `LDFLAGS` at link time, not during library builds. |
| 48 | +- GNU libtool redefines `-static`; to ensure static linking, use `--static` or `-Wl,-static` (optionally with `-static`) in `LDFLAGS`. |
| 49 | +- For static OpenSSL: do not use `openssl -static` (it disables threads/PIE/PIC). For `-static-pie` with musl/Alpine, use the correct flags and approach. |
| 50 | +- Do not use glibc-only flags or glibcisms for musl toolchains. |
| 51 | + |
| 52 | +## Debugging with QEMU |
| 53 | + |
| 54 | +- Start the target under QEMU with gdbstub, then attach with gdb: |
| 55 | + - `qemu -g <port> <binary>` (e.g., `qemu -g 1234 ./qbt-nox-static`) |
| 56 | + - In another terminal: `gdb ./qbt-nox-static` and `target remote :1234` |
| 57 | + |
| 58 | +## If repo name matches `*qbittorrent-nox-static` |
| 59 | + |
| 60 | +`qi.bash` script goals |
| 61 | +- Simple installer that verifies installation and binaries. |
| 62 | +- Shebang must be `#!/bin/bash`. |
| 63 | + |
| 64 | +OS detection |
| 65 | +- `source /etc/os-release`. |
| 66 | +- Supported: `ID=alpine`, `ID=debian`, or `ID_LIKE` contains `debian`. Otherwise exit with a clear reason. |
| 67 | + |
| 68 | +Transfer tools |
| 69 | +- Prefer `curl` if present; use `wget` if present and `curl` is not; exit if neither is available. |
| 70 | +- Detect presence of `gh` CLI and use it when available, but it is not required. |
| 71 | + |
| 72 | +Architecture detection |
| 73 | +- Alpine: `apk --print-arch`. |
| 74 | +- Debian-like: `dpkg --print-architecture`. |
| 75 | +- Architectures are the same across distros except `armhf`: Debian uses `armv7`, Alpine uses `armv6`. |
| 76 | +- If architecture is not valid/supported, exit with a reason. |
| 77 | + |
| 78 | +Download function |
| 79 | +- Build the download URL from the detected architecture. |
| 80 | +- Create and store the download’s SHA-256 sum. |
| 81 | + |
| 82 | +Attestation (optional) |
| 83 | +- When `gh` CLI is available and usable, verify downloaded binaries: |
| 84 | + - `gh attestation verify <INSTALL_PATH> --repo <REPO> 2> /dev/null` |
| 85 | + |
| 86 | +Error handling |
| 87 | +- Provide a helper that checks command exit codes and exits with a concise, helpful message on failure. |
| 88 | + |
| 89 | +Output formatting |
| 90 | +- Provide a print helper that supports: |
| 91 | + - `[INFO]` (blue), `[WARNING]` (yellow), `[ERROR]` (red), `[SUCCESS]` (green), `[FAILURE]` (magenta) |
| 92 | +- Use `printf '%s'` and `printf '%b'`; do not use `echo`. |
| 93 | +- Keep messages succinct. Be verbose only on errors to aid troubleshooting. |
| 94 | + |
| 95 | +--- |
| 96 | + |
| 97 | +Meta for AI contributors |
| 98 | +- Be conservative: do only what the prompt requests. No broad refactors. |
| 99 | +- Prefer small, well-named functions and staged changes. |
| 100 | +- Preserve existing public behavior and style unless the prompt requires changes. |
| 101 | +- If something cannot be done with available context/tools, state why and propose the smallest viable alternative. |
1 | 102 | # Bash Scripting - All repos |
2 | 103 |
|
3 | 104 | - use $BASH_SOURCE instead of $0 |
|
10 | 111 | - Always makes changes in stages, a modular approach. |
11 | 112 | - use Google style guide for formatting of bash scripts - https://google.github.io/styleguide/shellguide.html |
12 | 113 | - Always use `#!/bin/bash` as the shebang. |
| 114 | +- Always use the extensions `bash` for bash script and `sh` only for posix shell scripts |
13 | 115 | - Use `printf '%s'` for printing strings and `printf '%b'` for escape sequences. **Avoid using `echo`.** |
14 | 116 | - Comment code to explain changes and logic. |
15 | 117 | - always prefer readability of code over complex one lines. Unless that foramt is promoted by the style guide. |
16 | 118 | - For Bash/shell questions, consult [mywiki.wooledge.org](https://mywiki.wooledge.org) or [BashFAQ](https://mywiki.wooledge.org/BashFAQ) first. **Provide a source link when possible.** |
| 119 | +- Don't hallucinate <mywiki.wooledge.org> links in comments |
| 120 | +- think like a c developer not a javascript developer. stable, concise, elegant and thoughtful. Not edgy and bleeding edge for the sake of it. |
| 121 | +- when providing a solution to a prompt don't provide solutions outside the scope of the prompt nor add loads checks and fallbacks that quickly become redundant in following prompts. |
| 122 | +- it makes me wast premium tokens making you fix the brken things you added or changed that were outside the scope of the prompt to begin with. |
| 123 | +- provide changes specific to the prompt given. |
17 | 124 |
|
18 | 125 | # GitHub Workflows - All repos |
19 | 126 |
|
@@ -80,3 +187,8 @@ ouputs |
80 | 187 | - Use `printf '%s'` for printing strings and `printf '%b'` for escape sequences. **Avoid using `echo`.** |
81 | 188 | - this function will provide end user information understanding or troubleshooting script outcomes. |
82 | 189 | - it should be succinct unless there is an error or failure, then it should be verbose enough to help. |
| 190 | + |
| 191 | +## Astro and Astro starlight template for documentation |
| 192 | + |
| 193 | +- Always use the mcp server https://mcp.docs.astro.build/mcp |
| 194 | +- Always make sure imported mdx components start with an upper case letter. |
0 commit comments