diff --git a/The_Steelbore_Standard.md b/The_Steelbore_Standard.md index f63e8f6..20d1783 100644 --- a/The_Steelbore_Standard.md +++ b/The_Steelbore_Standard.md @@ -1,13 +1,13 @@ --- title: The Steelbore Standard author: Mohamed Hammad -date: 2026-06-17 -version: 1.21 +date: 2026-06-18 +version: 1.22 source-format: odt --- @@ -15,7 +15,7 @@ source-format: odt **Engineering specification for Steelbore OS and the Spacecraft Software ecosystem** -**Version:** 1.21 | **Date:** 2026-06-17 | **Author:** Mohamed Hammad +**Version:** 1.22 | **Date:** 2026-06-18 | **Author:** Mohamed Hammad **Maintainer:** Mohamed Hammad | **Contact:** [Mohamed.Hammad@SpacecraftSoftware.org](mailto:Mohamed.Hammad@SpacecraftSoftware.org) **Copyright:** Copyright (C) 2026 Mohamed Hammad & Spacecraft Software | **License:** CC-BY-SA-4.0 **Website:** @@ -30,8 +30,9 @@ The Steelbore Standard defines the engineering principles, compliance requiremen ### Changelog +- **v1.22 (2026-06-18):** **§7 Shell Environment added** — codifies Nushell, Ion, Brush, and Bash as four equally first-class shell environments; §7.1 Script Portability Policy mandates POSIX-compatible scripts by default with Nushell/Ion native variants where needed and prohibits Bashisms in shared scripts. Current §7–§14 renumbered §8–§15 accordingly. Compliance checklist updated with §7 bullet. Skill Cross-References updated with shell-work row. **§14.2:** added email obfuscation note — `[at]` form permitted in plain-text prose; PKGBUILD `# Maintainer:` and SPDX headers must retain the full address. - **v1.21 (2026-06-17):** **§13.1:** registered subdomains for three projects present in `PROJECTS.md` but missing from the table — **Lode** (`Lode.SpacecraftSoftware.org`), **Sonde** (`Sonde.SpacecraftSoftware.org`), and **Vault** (`Vault.SpacecraftSoftware.org`). **§3.1 and Skill Cross-References:** corrected skill reference from `rust-guidelines` to `microsoft-rust-guidelines` to match the actual skill ID in the upstream `spacecraft-standard` skill. -- **v1.20 (2026-06-17):** **§5.5 added:** Package Distribution Requirements — every released package must ship `packaging/guix.scm` (GNU Guix Scheme definition), `packaging/default.nix` (Nix flake/derivation), and `packaging/PKGBUILD` (Arch Linux `makepkg`), all present and buildable before any release tag is pushed; each file must pin the exact release version and SHA-256 checksum in the format native to its package manager, and carry the project's SPDX two-tag header per §4.3. **§14** updated with a corresponding `§5.5` compliance-checklist bullet. +- **v1.20 (2026-06-17):** **§5.5 added:** Package Distribution Requirements — every released package must ship `packaging/guix.scm` (GNU Guix Scheme definition), `packaging/default.nix` (Nix flake/derivation), and `packaging/PKGBUILD` (Arch Linux `makepkg`), all present and buildable before any release tag is pushed; each file must pin the exact release version and SHA-256 checksum in the format native to its package manager, and carry the project's SPDX two-tag header per §4.3. **§15** updated with a corresponding `§5.5` compliance-checklist bullet. - **v1.19 (2026-06-16):** **§13.1:** registered the **MCP Servers** project subdomain (`MCP-Servers.SpacecraftSoftware.org`), paired in the same change-set with its row and GitHub-repo link in Spacecraft-Software/Projects `PROJECTS.md`. The `mcp-servers` repo — MCP (Model Context Protocol) server configuration templates across 12 coding agents/editors — was onboarded to the umbrella with the §5.2 posture files (`NOTICE.md`, `CONTRIBUTING.md`, README posture section) and §4.3 REUSE compliance (`LICENSES/`, `REUSE.toml`, `reuse lint`-clean). - **v1.18 (2026-06-08):** Licensing classification follow-through. (1) **§4.1.1 added:** license-by-artifact-class table — **software** (incl. skills) is `GPL-3.0-or-later`/`AGPL-3.0-or-later`; **documents** (specs, guides, document deliverables, the published Standard) default to `CC-BY-SA-4.0` (`CC-BY-4.0` for max-reuse cases); **third-party-derived** artifacts preserve their upstream license per §4.2. (2) **Skill-license correction:** clarified that skills are software-class — the published Standard document is `CC-BY-SA-4.0` but the `spacecraft-standard` skill encoding is `GPL-3.0-or-later` (the v1.17 skill metadata is corrected back to GPL accordingly). (3) **§4.1 migration policy (replaces v1.17's "no forced re-license"):** existing projects are to be reviewed and relicensed to the best-suited GPL/AGPL, per project, on signed commits. The Standard and Construct repos are now REUSE-compliant (`reuse lint`-clean) with `LICENSES/` directories and `REUSE.toml`. (4) **§2:** added *Equilibrium* and *Dune* to the endorsed sci-fi naming sources. - **v1.17 (2026-06-08):** Licensing & build overhaul. (1) **Standard relicensed** from `GPL-3.0-or-later` to **`CC-BY-SA-4.0`**, effective this version forward — GPL suits software, not a prose specification; CC BY-SA preserves the share-alike copyleft ethos and is purpose-built for documents. This affects the Standard document itself only; the projects it governs are unchanged by this point. (2) **§4.1:** project license is now `GPL-3.0-or-later` **or** `AGPL-3.0-or-later` (AGPL for network-facing software), prospective with no forced re-license. (3) **§4.2 added:** explicit upstream-license-compliance clause — preserve third-party copyright notices, license texts, and `NOTICE`/`AUTHORS` verbatim; ship upstream licenses in `LICENSES/`. (4) **§4.3:** SPDX/REUSE compliance per — two-tag headers (`SPDX-FileCopyrightText` + `SPDX-License-Identifier`), a `LICENSES/` directory, `.license`/`REUSE.toml` coverage for headerless files (replacing the old "documents are exempt" rule), and `reuse lint` as the CI gate. (5) **§3.2:** explicit optimization-flag exception — flags like LTO that break/destabilize a build on a given toolchain/platform (e.g., NixOS, cross-compilation) MUST be disabled and documented, since Stability (P1) outranks Performance (P2). §5.1/§5.2/§6/§13.2 license references and the §4/§12 compliance-checklist items updated to match. @@ -107,7 +108,7 @@ Projects named before the v1.2 convention drew from metallurgy, materials scienc | `Ferrite_OS`| Active | Custom OS / DOS-emulation experiments; ferrite (iron-based material) name. | | `Forge` | Active | Production flavor tooling (forge-cli, forge-build, forge-activate); forging-tool name. | -Existing legacy-named projects MAY be renamed under the v1.2 convention at the maintainer's discretion — renames are optional. When a rename happens, update this table and §13.1's subdomain table in the same commit. +Existing legacy-named projects MAY be renamed under the v1.2 convention at the maintainer's discretion — renames are optional. When a rename happens, update this table and §14.1's subdomain table in the same commit. ### §2.2 — Skill IDs are functional, not codenamed @@ -187,7 +188,7 @@ When a project incorporates, adapts, or links third-party code, it MUST satisfy - **Preserve verbatim** all upstream copyright notices, license texts, `NOTICE`/`AUTHORS` files, and in-file license headers — never strip, rewrite, or relicense them. - **Ship** each distinct upstream license text in the project's `LICENSES/` directory (§4.3). - **Verify compatibility** of the upstream license with the project's GPL/AGPL license before inclusion. -- This is the legal/mechanical obligation; §13.3's `CREDITS.md` is the human-readable narrative counterpart. When both are triggered, both apply. +- This is the legal/mechanical obligation; §14.3's `CREDITS.md` is the human-readable narrative counterpart. When both are triggered, both apply. ### §4.3 — SPDX & REUSE Compliance @@ -250,7 +251,7 @@ A project may declare itself **intended for general use**. When it does: - The no-warranty / no-liability stance from §5.1 still applies in full — general-use status changes audience and intent, **not** legal terms. - General-use projects must hold a higher release-quality bar: semantic versioning, maintained `CHANGELOG.md`, deprecation policy, and a documented support window for the current major version. -**General-use registry** (keep in sync with §13.1 subdomain table): +**General-use registry** (keep in sync with §14.1 subdomain table): | Project | Posture | |--------------|---------------| @@ -313,7 +314,22 @@ Every commit pushed to a Spacecraft Software-controlled Git remote **must** be c --- -## §7 — Privacy-Friendly Application (PFA) Policy +## §7 — Shell Environment + +Spacecraft Software tooling, documentation, and CI pipelines target **four first-class shell environments**: **Nushell**, **Ion**, **Brush**, and **Bash**. All four are equally supported; none is deprecated or downgraded. + +### §7.1 — Script Portability Policy + +| Rule | Detail | +|------|--------| +| Default: POSIX-compatible | Shell scripts in source trees, CI pipelines, `Makefile` targets, and documentation examples **must** be written to the POSIX sh subset unless a shell-native feature is required. POSIX scripts run correctly in Bash and Brush without modification. | +| Nushell / Ion native variants when needed | When a task cannot be expressed cleanly in POSIX sh (structured data pipelines, typed parameters, Nushell modules), provide a Nushell (`.nu`) and/or Ion-native variant alongside the POSIX version. Do not force POSIX-only idioms that degrade the Nushell or Ion experience. | +| No Bashisms in shared scripts | Bash-only extensions (`[[ ]]`, `(( ))`, process substitution `<(...)`, `${var^^}`, indexed arrays) are prohibited in files intended for all four shells. Bash-specific scripts are permitted only when explicitly scoped (e.g., `#!/usr/bin/env bash` shebang, clearly labeled). | +| Graceful shell detection | Tools that need runtime shell detection must inform the user or degrade gracefully rather than silently failing in non-Bash environments. | + +--- + +## §8 — Privacy-Friendly Application (PFA) Policy Every Spacecraft Software application must satisfy **all three** PFA requirements: @@ -327,7 +343,7 @@ When reviewing or designing any feature that touches data handling, permissions, --- -## §8 — Key Bindings +## §9 — Key Bindings All interactive applications must support **both**: @@ -338,7 +354,7 @@ All interactive applications must support **both**: --- -## §9 — Spacecraft Software Color Palette (WCAG-Compliant) +## §10 — Spacecraft Software Color Palette (WCAG-Compliant) The **only** permitted colors for Spacecraft Software interfaces and documents: @@ -355,7 +371,7 @@ The **only** permitted colors for Spacecraft Software interfaces and documents: For document/file generation → load the `spacecraft-document-format` skill. For IDE/terminal themes → load the `spacecraft-theme-factory` skill. -### §9.1 — Steelbore Theme (Application Theming Standard) +### §10.1 — Steelbore Theme (Application Theming Standard) When building a new Spacecraft Software application (GUI, TUI, or web), all palette references **must** be accessed through a named theme called **`Steelbore`** rather than @@ -378,7 +394,7 @@ referenced as bare hex literals. The `Steelbore` theme is the canonical color co --- -## §10 — Typography (FOSS-Licensed Fonts Only) +## §11 — Typography (FOSS-Licensed Fonts Only) Acceptable font licenses: **OFL, Apache 2.0, Ubuntu Font License, CC0-1.0** @@ -392,36 +408,36 @@ Never use proprietary fonts. When suggesting or using fonts in any Spacecraft So --- -## §11 — UI/UX Design System +## §12 — UI/UX Design System -- **Material Design** is the required component system for all graphical applications. Theme Material components with the §9 color palette. +- **Material Design** is the required component system for all graphical applications. Theme Material components with the §10 color palette. - **WCAG 2.1 Level AA** contrast is the minimum for all color pairings. Any new color additions must be WCAG-verified before adoption. - **Accessibility:** screen readers, keyboard-only navigation, and system accessibility preferences (reduced motion, high contrast) must all be respected. --- -## §12 — Date, Time & Units +## §13 — Date, Time & Units -### §12.1 — Date & Time Format Rules +### §13.1 — Date & Time Format Rules | Concern | Rule | Example | |--------------|------------------------------------------------------------------|------------------------------| | Date format | ISO 8601 only: `YYYY-MM-DD` | `2026-03-08` | | Time format | 24-hour only: `HH:MM:SS` — AM/PM is **never** permitted | `14:30:00` | | Timestamp | Combined ISO 8601 UTC: `YYYY-MM-DDTHH:MM:SSZ` | `2026-03-08T14:30:00Z` | -| Timezone | **UTC Z is the default and preferred primary** for general-purpose, cross-system, and machine-readable timestamps. A project whose core domain is inherently local-time-bound (e.g., solar/prayer-time calculations) may declare local time as its primary record instead — a documented exception, not a free choice. See §12.2 and §12.2.1 | `Z` not `+00:00` | +| Timezone | **UTC Z is the default and preferred primary** for general-purpose, cross-system, and machine-readable timestamps. A project whose core domain is inherently local-time-bound (e.g., solar/prayer-time calculations) may declare local time as its primary record instead — a documented exception, not a free choice. See §13.2 and §13.2.1 | `Z` not `+00:00` | | Duration | ISO 8601 duration format only | `PT1H30M` not "1h 30m" | | Units | Metric (SI) primary; imperial in parentheses only if locale requires | `100 km (62 mi)` | Apply these conventions to all generated code, documentation, comments, and any user-facing strings. Never output AM/PM time, non-ISO dates, or imperial-primary units. -### §12.2 — UTC Z Timezone Policy +### §13.2 — UTC Z Timezone Policy **UTC Z is the default and preferred timezone for stored, transmitted, logged, and committed timestamps across Spacecraft Software projects.** It is the convention every project should reach for first — it keeps cross-project tooling, sorting, and interchange simple and unambiguous. Under this default, the `Z` suffix is required on primary timestamps, and local time expressed as a UTC offset (e.g., `2026-05-24T13:34:55+03:00`) may optionally accompany a UTC Z value as a secondary, human-convenience field — but UTC Z remains the authoritative record. -This is a strong default, not a universal mandate forced onto every domain regardless of fit — §12.2.1 documents the exception that lets a project whose domain is genuinely local-time-bound use local time as its primary record instead. +This is a strong default, not a universal mandate forced onto every domain regardless of fit — §13.2.1 documents the exception that lets a project whose domain is genuinely local-time-bound use local time as its primary record instead. -**Rules for projects under the UTC Z default — apply unless a project has filed the §12.2.1 exception:** +**Rules for projects under the UTC Z default — apply unless a project has filed the §13.2.1 exception:** | Rule | Detail | |------|--------| @@ -432,20 +448,20 @@ This is a strong default, not a universal mandate forced onto every domain regar | Commit timestamps use UTC | `GIT_COMMITTER_DATE` and `GIT_AUTHOR_DATE` must be UTC when set programmatically. | | File metadata written by Spacecraft Software tools | mtime/ctime written by Spacecraft Software tools must be UTC-sourced. | -### §12.2.1 — Domain Exception: Inherently Local-Time-Bound Projects +### §13.2.1 — Domain Exception: Inherently Local-Time-Bound Projects A project whose core domain is fundamentally defined by **local civil or solar time** — not by a moment in absolute (UTC) time — may declare local time as the **primary** representation for that domain's data. Examples: prayer-time calculations (`Mawaqit`), sunrise/sunset tables, local event or business-hours scheduling. For data like this, the meaningful value *is* "06:14 local, at this place" — collapsing it to a UTC instant first and treating that as authoritative would misrepresent what the data actually is. **Conditions for the exception:** 1. **Document it.** The project's README or spec must state explicitly which data uses local time as primary, and the *domain* reason why — not developer or user convenience. -2. **Keep the default everywhere else.** General-purpose machinery within the same project — logs, commit timestamps, internal cross-system APIs, telemetry — still follows the §12.2 UTC Z default. The exception covers the domain data itself, not the whole project. +2. **Keep the default everywhere else.** General-purpose machinery within the same project — logs, commit timestamps, internal cross-system APIs, telemetry — still follows the §13.2 UTC Z default. The exception covers the domain data itself, not the whole project. 3. **Preserve UTC derivability.** Store or compute the IANA timezone (e.g., `Africa/Cairo`) alongside the local value, so a UTC instant remains derivable for interchange, comparison, and storage portability. 4. **This is an exception, not an escape hatch.** "Local time is more convenient" or "our users are mostly in one timezone" do not qualify — the domain itself must be inherently local-time-bound. -### §12.3 — Local Time as Optional Companion +### §13.3 — Local Time as Optional Companion -**For projects under the UTC Z default** (§12.2), local time expressed as a UTC offset is permitted as an **optional companion** to the UTC Z primary value — in human-facing display, in API responses (as an additional field, never replacing the UTC Z field), and in stored records where timezone context aids human readers. The UTC Z value is always present and always authoritative; the local-time companion is supplemental only. (A project operating under the §12.2.1 domain exception inverts these roles for its domain data — local time is primary there, with UTC kept derivable rather than displayed as authoritative.) +**For projects under the UTC Z default** (§13.2), local time expressed as a UTC offset is permitted as an **optional companion** to the UTC Z primary value — in human-facing display, in API responses (as an additional field, never replacing the UTC Z field), and in stored records where timezone context aids human readers. The UTC Z value is always present and always authoritative; the local-time companion is supplemental only. (A project operating under the §13.2.1 domain exception inverts these roles for its domain data — local time is primary there, with UTC kept derivable rather than displayed as authoritative.) - The `--absolute-time` flag (defined in `spacecraft-cli-standard` §3) disables relative-time rendering but always renders as UTC, not local time. - If a future CLI wants to show local time in human mode, it MUST: @@ -455,7 +471,7 @@ A project whose core domain is fundamentally defined by **local civil or solar t 4. Never persist or transmit the local-time rendering. - JSON/machine output (`--format json/jsonl/yaml/csv`) MUST always use UTC + `Z`. -### §12.4 — Duration Format +### §13.4 — Duration Format Durations follow ISO 8601 duration notation: @@ -467,7 +483,7 @@ Durations follow ISO 8601 duration notation: Prose forms like "1h 30m", "90 minutes", "1.5 hours" are **forbidden** in machine-readable output. They are acceptable in `--help` text only. -### §12.5 — Rust Implementation Guidance +### §13.5 — Rust Implementation Guidance When writing Rust code that handles time: @@ -483,14 +499,14 @@ When writing Rust code that handles time: --- -## §13 — Attribution, Maintainer & Contact +## §14 — Attribution, Maintainer & Contact **Maintainer:** Mohamed Hammad **Contact:** [Mohamed.Hammad@SpacecraftSoftware.org](mailto:Mohamed.Hammad@SpacecraftSoftware.org) **Copyright:** Copyright (C) 2026 Mohamed Hammad & Spacecraft Software | **License:** CC-BY-SA-4.0 **Website:** -### §13.1 — Project Pages +### §14.1 — Project Pages Each Spacecraft Software project has a dedicated subdomain following the pattern `https://.SpacecraftSoftware.org/`. Use the project-specific URL in all project-level outputs; use `https://SpacecraftSoftware.org/` only for umbrella references. @@ -522,7 +538,7 @@ Each Spacecraft Software project has a dedicated subdomain following the pattern When a new project is created, add its subdomain to this table immediately. -### §13.2 — Mandatory Attribution in Project Outputs +### §14.2 — Mandatory Attribution in Project Outputs Every Spacecraft Software product **must** surface the following attribution in at least one of: `--help` output, `--version` output, README, or About/Info screen. @@ -565,11 +581,13 @@ https://.SpacecraftSoftware.org/ "website": "https://.SpacecraftSoftware.org/" ``` -### §13.3 — Third-Party Attribution +- **Email obfuscation in plain-text prose.** In plain-text prose contexts (README body, CONTRIBUTING.md, human-readable documentation) where the address is not a clickable link, `Mohamed.Hammad [at] SpacecraftSoftware.org` is permitted as a scraper-resistant form. `# Maintainer:` lines in PKGBUILDs and `SPDX-FileCopyrightText` headers **must** always use the full address — those formats are parsed by `makepkg`/`pkgcheck` and `reuse lint` respectively, and obfuscation breaks them. + +### §14.3 — Third-Party Attribution Spacecraft Software artifacts must give credit where credit is due. When a project or skill **substantially builds on third-party work**, that credit appears in a `CREDITS.md` at the artifact's root — `/CREDITS.md` for projects, `/CREDITS.md` for skills. -`CREDITS.md` is the inbound counterpart to §13.2's outbound attribution: §13.2 tells consumers who maintains Spacecraft Software; §13.3 tells consumers whose work Spacecraft Software stands on. +`CREDITS.md` is the inbound counterpart to §14.2's outbound attribution: §14.2 tells consumers who maintains Spacecraft Software; §14.3 tells consumers whose work Spacecraft Software stands on. **Triggers** (any one obligates a `CREDITS.md`): @@ -599,7 +617,7 @@ SPDX headers (§4) cover license compliance mechanically; `CREDITS.md` is the hu --- -## §14 — Compliance Checklist (Audit Gate) +## §15 — Compliance Checklist (Audit Gate) Before finalising **any** Spacecraft Software artifact, mentally verify: @@ -613,14 +631,15 @@ Before finalising **any** Spacecraft Software artifact, mentally verify: - [ ] **§5** Project Posture: README/NOTICE/CONTRIBUTING present; default personal-hobby stance applied; general-use carve-outs declared in project README - [ ] **§5.5** Package distribution: `packaging/guix.scm`, `packaging/default.nix`, and `packaging/PKGBUILD` present, buildable, and carrying correct version + SHA-256 checksum (in each package manager's native format) before any release tag is pushed - [ ] **§6.1** POSIX-compliant CLI/system tools -- [ ] **§7** PFA: no tracking, minimal permissions, local storage default -- [ ] **§8** CUA + Vim-like key bindings planned/implemented -- [ ] **§9** Spacecraft Software color palette used; Void Navy background mandatory; new apps expose colors via a named `Steelbore` theme (§9.1) — no bare hex literals in UI logic -- [ ] **§10** FOSS-licensed fonts only (Share Tech Mono / Inconsolata) -- [ ] **§11** Material Design UI/UX; WCAG 2.1 AA verified -- [ ] **§12** ISO 8601 dates; 24h time; UTC Z is the default primary timestamp (companion local time with UTC offset permitted, never a replacement) — unless the project filed the §12.2.1 domain exception for inherently local-time-bound data; ISO 8601 durations; metric units -- [ ] **§13** Attribution present: maintainer name (`Mohamed Hammad`), contact (`Mohamed.Hammad@SpacecraftSoftware.org`), and project URL in `--version` / README / About -- [ ] **§13.3** Third-party work credited in `CREDITS.md` at project/skill root when triggers apply; deeper `references/ATTRIBUTION.md` present where reference content is adapted from external sources +- [ ] **§7** Shell scripts are POSIX-compatible; Nushell/Ion native variants provided where shell-native idioms are required; no Bashisms in shared scripts +- [ ] **§8** PFA: no tracking, minimal permissions, local storage default +- [ ] **§9** CUA + Vim-like key bindings planned/implemented +- [ ] **§10** Spacecraft Software color palette used; Void Navy background mandatory; new apps expose colors via a named `Steelbore` theme (§10.1) — no bare hex literals in UI logic +- [ ] **§11** FOSS-licensed fonts only (Share Tech Mono / Inconsolata) +- [ ] **§12** Material Design UI/UX; WCAG 2.1 AA verified +- [ ] **§13** ISO 8601 dates; 24h time; UTC Z is the default primary timestamp (companion local time with UTC offset permitted, never a replacement) — unless the project filed the §13.2.1 domain exception for inherently local-time-bound data; ISO 8601 durations; metric units +- [ ] **§14** Attribution present: maintainer name (`Mohamed Hammad`), contact (`Mohamed.Hammad@SpacecraftSoftware.org`), and project URL in `--version` / README / About +- [ ] **§14.3** Third-party work credited in `CREDITS.md` at project/skill root when triggers apply; deeper `references/ATTRIBUTION.md` present where reference content is adapted from external sources - [ ] **§6.3** All commits to Spacecraft Software Git remotes cryptographically signed with the `Mohamed.Hammad@SpacecraftSoftware.org` key and showing "Verified" on the hosting platform; rewrites preserve signatures; programmatic and assistant-driven commits signed too If any item is not applicable to the current artifact type (e.g., color palette for a pure Rust library), note it as N/A rather than silently skipping it. @@ -629,12 +648,13 @@ If any item is not applicable to the current artifact type (e.g., color palette ## Skill Cross-References -| Task | Load this skill | -|---------------------------------------|------------------------------| -| Writing any Rust code | `microsoft-rust-guidelines` | -| Generating DOCX / ODT / PDF documents | `spacecraft-document-format` | -| Creating IDE / terminal themes | `spacecraft-theme-factory` | -| All other Spacecraft Software work | `spacecraft-standard` | +| Task | Load this skill | +|---------------------------------------|----------------------------------------------------| +| Writing any Rust code | `microsoft-rust-guidelines` | +| Writing or reviewing shell scripts | `spacecraft-cli-shell` + `spacecraft-cli-preference` | +| Generating DOCX / ODT / PDF documents | `spacecraft-document-format` | +| Creating IDE / terminal themes | `spacecraft-theme-factory` | +| All other Spacecraft Software work | `spacecraft-standard` | ---