Rename skill to spacecraft-steelbore-standard — v1.49

.github/check-skill-refs.py

@@ -77,7 +77,7 @@
 
 # Paths whose document-version pin is legitimate: the skill that encodes the
 # Standard carries its version by design, and changelogs are history.
-VERSION_EXEMPT_PARTS = ("spacecraft-standard-constitution",)
+VERSION_EXEMPT_PARTS = ("spacecraft-steelbore-standard",)
 VERSION_EXEMPT_NAMES = ("CHANGELOG.md",)
 
 # Changelogs also name things that have since been renamed or removed — that is

AGENTS.md

@@ -22,10 +22,10 @@ gnu-* microsoft-*` or check the README table if this drifts) span three
 groups: infra/tooling (`spacecraft-agentic-cli`, `spacecraft-brand-guidelines`,
 `spacecraft-cli-preference`, `spacecraft-cli-shell`, `spacecraft-cli-standard`,
 `spacecraft-document-format`, `spacecraft-markdown-document`,
-`spacecraft-missing-pkg`, `spacecraft-standard-constitution`,
+`spacecraft-missing-pkg`, `spacecraft-steelbore-standard`,
 `spacecraft-texinfo-document`, `spacecraft-theme-factory`, `gnu-coding-standards`,
 `gnu-free-software`), the governing Standard skill
-(`spacecraft-standard-constitution`), and one `spacecraft-<language>-guidelines`
+(`spacecraft-steelbore-standard`), and one `spacecraft-<language>-guidelines`
 skill per supported language (currently: ada, carbon, chez, clang, clojure,
 commonlisp, cpp, dartflutter, elixir, erlang, gleam, golang, guile, java,
 kotlin, lua, nickel, nim, nix, nu, ocamel, python, rust, swift, typescript,
@@ -45,7 +45,7 @@ presence — adding a new skill directory is enough; no flake edit needed.
 (see `excludedDirs` in `flake.nix`).
 
 The authoritative governance document for everything produced in this repo is
-[`spacecraft-standard-constitution/SKILL.md`](spacecraft-standard-constitution/SKILL.md), which encodes
+[`spacecraft-steelbore-standard/SKILL.md`](spacecraft-steelbore-standard/SKILL.md), which encodes
 The Steelbore Standard — it carries the current version in its own masthead, so
 none is repeated here to go stale. Load it before any non-trivial edit — its §14 checklist is the
 audit gate. The skill is the upstream of the published `standard/` document;
@@ -111,7 +111,7 @@ is mechanical — apply it after **any** edit inside a `<skill-name>/` directory
    ```
    Add `<name>/assets` to both lines if the skill has an `assets/` dir
    (today only `spacecraft-agentic-cli` does). Omit any argument the skill
-   doesn't have — `spacecraft-standard-constitution` is SKILL.md-only; many skills omit
+   doesn't have — `spacecraft-steelbore-standard` is SKILL.md-only; many skills omit
    the in-directory LICENSE entirely; `CREDITS.md` exists only where §15.3
    applies (`microsoft-rust-guidelines`, `gnu-coding-standards`,
    `spacecraft-cli-preference`, `spacecraft-rust-guidelines`,
@@ -169,7 +169,7 @@ matching bundle change.
 **Detecting already-committed drift.** A clean working tree does *not* prove the
 bundles are current: a past commit can bump `SKILL.md` while forgetting the
 bundle, leaving a committed `.zip`/`.skill` that silently lags its source (this
-has happened — `spacecraft-standard-constitution` shipped v1.12 against a v1.18 `SKILL.md`).
+has happened — `spacecraft-steelbore-standard` shipped v1.12 against a v1.18 `SKILL.md`).
 `git status` can't see it. Before trusting the install surface, sweep:
 
 ```sh
@@ -194,7 +194,7 @@ Any `DRIFT:` line means rebuild that skill's bundles and commit. The sweep now
 walks the **whole** bundle: `(a)` content-diffs every file the `.zip` contains
 (`SKILL.md`, `references/**`, `LICENSE`, `CREDITS.md`, `assets/**`) against the
 working tree, and `(b)` flags any shippable file on disk that the bundle is
-missing — so adding a `references/` file (e.g. `spacecraft-standard-constitution`'s
+missing — so adding a `references/` file (e.g. `spacecraft-steelbore-standard`'s
 `CHANGELOG.md`) without rebuilding is caught too. It checks `.zip` as the
 canonical surface; `.skill` is built in lockstep from the same args in the same
 commit, so a drifted `.zip` implies a drifted `.skill`.
@@ -336,8 +336,8 @@ does **not** invoke it.
 Verify after rebuild:
 
 ```sh
-readlink -f ~/.claude/skills/spacecraft-standard-constitution
-# → /spacecraft-software/construct/spacecraft-standard-constitution
+readlink -f ~/.claude/skills/spacecraft-steelbore-standard
+# → /spacecraft-software/construct/spacecraft-steelbore-standard
 ```
 
 If the symlink still resolves into a stale `/nix/store/<old-hash>-hm_*` path
@@ -396,7 +396,7 @@ The assistant performs no `rsync`, no symlink setup, and no
     | xargs -0 python3 .githooks/check-description-length.py
   ```
 - **`microsoft-rust-guidelines` is intentionally `user-invocable: false`.** It is
-  the mandatory auto-load Rust base — `spacecraft-standard-constitution` mandates loading it
+  the mandatory auto-load Rust base — `spacecraft-steelbore-standard` mandates loading it
   before any Rust, `spacecraft-rust-guidelines` defers to it as "load first," and
   `gnu-coding-standards` / `spacecraft-cli-standard` / `spacecraft-agentic-cli`
   chain to it. It fires automatically from its own description and those chains,

CONTRIBUTING.md

@@ -217,7 +217,7 @@ consolidated zip intentionally differs from any on-disk tree).
     opt-in per clone, so it is explicitly *not* the gate; §5.6 requires the two
     above precisely because a hook can be skipped.
 - **`microsoft-rust-guidelines` is intentionally `user-invocable: false`.** It is
-  the mandatory auto-load Rust base — `spacecraft-standard-constitution` mandates loading it
+  the mandatory auto-load Rust base — `spacecraft-steelbore-standard` mandates loading it
   before any Rust and `spacecraft-rust-guidelines` defers to it as "load first," so
   it fires automatically and is hidden from the `/` menu on purpose. Do **not**
   remove the field to "fix" a perceived load failure — that is by design.

README.md

@@ -64,7 +64,7 @@ the rules re-attached to every prompt.
 | [`spacecraft-python-guidelines`](spacecraft-python-guidelines/) | Type-safe highly-concurrent Python guidance (targeting Python 3.12+) — strict static typing (`mypy`), boundary validation (`Pydantic v2`), non-blocking asynchronous event loops (`asyncio`), multiprocess CPU scaling (`ProcessPoolExecutor`), memory-optimized slots classes, and Ruff linting rules. |
 | [`spacecraft-qt-guidelines`](spacecraft-qt-guidelines/) | Memory-safe Qt 6 desktop guidance, Rust-first — CXX-Qt bridges for logic and QML models with an honest coverage boundary, `QObject` single-ownership discipline, `deleteLater` and context-object connect rules, worker-object threading (never a `QThread` subclass), named `QMutexLocker` guards, `QAccessibleInterface` for custom paint, `QPalette`/QSS theming, and QML↔C++ ownership. |
 | [`spacecraft-rust-guidelines`](spacecraft-rust-guidelines/) | High-performance concurrent Rust guidance — concurrency model selection, lock-free synchronisation, memory layout, tooling gates, and unsafe hygiene — plus a distilled idiom layer (`references/idioms.md`, adapted from Apollo's Rust Best Practices, MIT) covering borrowing, clippy discipline, testing, dispatch, and type-state. |
-| [`spacecraft-standard-constitution`](spacecraft-standard-constitution/) | Authoritative compliance reference (The Steelbore Standard). |
+| [`spacecraft-steelbore-standard`](spacecraft-steelbore-standard/) | Authoritative compliance reference (The Steelbore Standard). |
 | [`spacecraft-swift-guidelines`](spacecraft-swift-guidelines/) | Type-safe highly-concurrent Swift guidance (targeting Swift 6.2+) — Swift 6.2 concurrency, explicit `@concurrent` background offloading, isolated conformances, `@MainActor` isolated ViewModels, Swift Testing `@Suite` and `@Test` parameterized checks, and ARC reference cycle safety. |
 | [`spacecraft-texinfo-document`](spacecraft-texinfo-document/) | How-to layer for authoring, building, linting, and converting GNU Texinfo — the canonical Spacecraft prose format (one `.texi` → Info/HTML/PDF/DocBook/text/EPUB); house-style header/licensing, node/menu discipline, `@def*` API docs, the `texi2any`/`texi2pdf` toolchain, and HTML/PDF brand theming. |
 | [`spacecraft-theme-factory`](spacecraft-theme-factory/) | Generates Spacecraft Software-compliant themes for IDEs and terminals. |
@@ -154,7 +154,7 @@ To pick up the latest commit, run `nix flake update construct` in the consumer
 flake and rebuild.
 
 Individual skills are also exposed as packages — e.g.
-`nix build github:Spacecraft-Software/Construct#spacecraft-standard-constitution` produces
+`nix build github:Spacecraft-Software/Construct#spacecraft-steelbore-standard` produces
 a `result/` directory with that skill's contents.
 
 ### Grok skills
@@ -191,7 +191,7 @@ regeneration contract.
 ## Standards
 
 All skills in this repository are expected to conform to
-[The Steelbore Standard](spacecraft-standard-constitution/) — including:
+[The Steelbore Standard](spacecraft-steelbore-standard/) — including:
 
 - **§4** SPDX/REUSE-compliant licensing (§4.3): two-tag headers / `REUSE.toml`, a
   `LICENSES/` directory, `reuse lint`-clean. Skills are GPL-3.0-or-later (§4.1.1);
@@ -207,7 +207,7 @@ This repository follows the [REUSE specification](https://reuse.software) — se
 §4.1.1, skills are **GPL-3.0-or-later** by default; third-party-derived skills keep
 their upstream license (e.g. `microsoft-rust-guidelines` is MIT, `gnu-coding-standards`
 is GFDL-1.3-or-later). The published Standard *document* is CC-BY-SA-4.0, but the
-`spacecraft-standard-constitution` *skill* here is GPL-3.0-or-later.
+`spacecraft-steelbore-standard` *skill* here is GPL-3.0-or-later.
 
 ---
 

REUSE.toml

@@ -2,7 +2,7 @@ version = 1
 
 # Default: all Construct skills and tooling are GPL-3.0-or-later (software-class per
 # Standard §4.1.1). "override" precedence so example SPDX headers embedded in skill prose
-# (e.g. spacecraft-standard-constitution's §4.3 example) are not parsed as real license tags.
+# (e.g. spacecraft-steelbore-standard's §4.3 example) are not parsed as real license tags.
 [[annotations]]
 path = "**"
 precedence = "override"

android-skills/README.md

@@ -11,7 +11,7 @@ Google's official **[Android skills](https://github.com/android/skills)**,
 vendored **verbatim and unmodified** into the Construct catalogue. These are
 third-party Apache-2.0 skills authored by Google LLC — not Spacecraft Software
 originals. See [`CREDITS.md`](CREDITS.md) for full provenance and the
-[Standard §4.2](../spacecraft-standard-constitution/) upstream-preservation rationale.
+[Standard §4.2](../spacecraft-steelbore-standard/) upstream-preservation rationale.
 
 Android skills follow the [open-standard agent-skills](https://agentskills.io/)
 `SKILL.md` format — the same format Claude / Gemini / Codex already load — so

gnu-coding-standards/SKILL.md

@@ -56,7 +56,7 @@ GNU intent comes in two strengths:
 
 - **GNU-compatible** — a Spacecraft/Steelbore project that adopts GNU's conventions where
   they aid interoperability while **staying itself**: on GitHub, under the Steelbore
-  palette/brand and `Mohamed.Hammad@SpacecraftSoftware.org` attribution. `spacecraft-standard-constitution`
+  palette/brand and `Mohamed.Hammad@SpacecraftSoftware.org` attribution. `spacecraft-steelbore-standard`
   stays primary; **this skill** supplies the GNU conventions for interop, and the
   free-software *political* mandates are advisory here — Steelbore identity stands. This is
   this skill's home turf.
@@ -69,7 +69,7 @@ GNU intent comes in two strengths:
 
 The differentiator is identity-stripping: producing a real free-software/GNU package →
 `gnu-free-software`; styling Spacecraft code to GNU conventions while staying Steelbore →
-this skill (with `spacecraft-standard-constitution`).
+this skill (with `spacecraft-steelbore-standard`).
 
 ## How to use this skill
 

gnu-coding-standards/references/conventions.md

@@ -235,7 +235,7 @@ build part of the program, never to substitute one behavior for another.
 > explicitly pointing GCC's linker to the LTO plugin via `-fuse-ld=mold` (preferred) or
 > `-fuse-ld=bfd` (fallback) because `/nix/store` isolation keeps the plugin off the default
 > linker path. Just as systemd-specific settings do not apply to non-systemd distros, LTO
-> and linker flags must be adapted to the target platform. See `spacecraft-standard-constitution` §3.2.1.
+> and linker flags must be adapted to the target platform. See `spacecraft-steelbore-standard` §3.2.1.
 
 ### Directory variables
 

grok-skills/README.md

@@ -84,7 +84,7 @@ These skills follow the Steelbore Standard's licensing (§4,
 GPL-3.0-or-later) and ISO 8601 UTC date rules (§14), but use Grok's minimal
 frontmatter schema (`name` + `description`) rather than the
 Claude/Gemini/Codex schema with `license` / `maintainer` / `website` fields.
-See [The Steelbore Standard](../spacecraft-standard-constitution/) for the full
+See [The Steelbore Standard](../spacecraft-steelbore-standard/) for the full
 compliance reference.
 
 <!-- §7 — License -->

microsoft-rust-guidelines/CREDITS.md

@@ -2,7 +2,7 @@
 
 The `microsoft-rust-guidelines` skill is a Spacecraft Software adaptation of publicly released
 work by Microsoft. This file records the upstream source it builds on, in
-accordance with [The Steelbore Standard §15.3](../spacecraft-standard-constitution/SKILL.md).
+accordance with [The Steelbore Standard §15.3](../spacecraft-steelbore-standard/SKILL.md).
 
 ## Microsoft Pragmatic Rust Guidelines
 

microsoft-rust-guidelines/SKILL.md

@@ -166,7 +166,7 @@ Use when:
 ## Steelbore Standard Requirements (Rust)
 
 When writing Rust code for any Spacecraft Software project, these additional rules
-from [The Steelbore Standard](../spacecraft-standard-constitution/SKILL.md) apply on top of the
+from [The Steelbore Standard](../spacecraft-steelbore-standard/SKILL.md) apply on top of the
 Microsoft Pragmatic Rust Guidelines above.
 
 ### §4 — SPDX License Header (mandatory)
@@ -193,7 +193,7 @@ are not manifests) are exempt; software source files are not.
   `build.rs` or a build-time message — so flag state is visible at compile time. Any flag
   that breaks or destabilizes the build on a given platform/toolchain (e.g. LTO under some
   NixOS, cross-compilation, or static-linking setups) MUST be disabled; Stability
-  (Priority 1) outranks Performance. See `spacecraft-standard-constitution` §3.2.1.
+  (Priority 1) outranks Performance. See `spacecraft-steelbore-standard` §3.2.1.
 - Benchmarking is **mandatory** before and after any optimization work; regressions must
   be documented and justified — it is also the evidence for the concurrency-vs-serial
   trade-off above.

spacecraft-accessibility-support/SKILL.md

@@ -268,7 +268,7 @@ enforceable since 2025-06-28, and EN 301 549 V4.1.1 folds in WCAG 2.2.
 |------|-------|
 | CLI structure, `--json`, `NO_COLOR` precedence, TTY detection | `spacecraft-cli-standard` |
 | Emitting theme files for editors/terminals | `spacecraft-theme-factory` |
-| Full Standard compliance | `spacecraft-standard-constitution` |
+| Full Standard compliance | `spacecraft-steelbore-standard` |
 | Documenting the accessible path in a manual | `spacecraft-texinfo-document` |
 
 *— Built by Spacecraft Software —*

spacecraft-ada-guidelines/SKILL.md

@@ -149,6 +149,6 @@ Ada catches at compile/proof time what other languages catch at runtime — *if*
 - **Rule catalogue (cite IDs from here):** `references/AdaCore_Safe_Secure_Rules.md` — all 41 DYN/RCL/CON/RPP/EXU/OOP/SWE rules with Levels and standards mappings.
 - Extended patterns, full worked examples, and a proof-debugging guide: `references/Spacecraft_Ada_SPARK_Guidelines.md`
 - Conceptual sources, the source PDF, and the SPARK Reference Manual: `CREDITS.md` and `references/ATTRIBUTION.md`
-- Related skills: `spacecraft-rust-guidelines` (the Rust side of the same high-assurance posture), `spacecraft-standard-constitution` (cross-cutting compliance); cross-apply the NASA/JPL *Power of Ten* rules (loop/recursion/scope budgets).
+- Related skills: `spacecraft-rust-guidelines` (the Rust side of the same high-assurance posture), `spacecraft-steelbore-standard` (cross-cutting compliance); cross-apply the NASA/JPL *Power of Ten* rules (loop/recursion/scope budgets).
 
 When the user provides Ada/SPARK code for review or asks to write a high-assurance unit, immediately apply the rules above: strengthen the types, add and discharge contracts, declare the assurance target, and produce code that passes `gnatprove` at that level. Cite the exact rule or unproved check in any feedback. Prioritize machine-checked correctness and AoRTE above all else.

spacecraft-ada-guidelines/references/ATTRIBUTION.md

@@ -21,6 +21,6 @@ methodology is credited here as the conceptual basis for the assurance ladder.
 Cross-references within the Spacecraft skill set:
 - The NASA/JPL *Power of Ten* rules — bounded-loop / no-recursion / restricted-scope budgets reused here.
 - `spacecraft-rust-guidelines` — the Rust side of the same high-assurance posture.
-- `spacecraft-standard-constitution` — cross-cutting compliance (licensing, SPDX, ISO 8601, naming).
+- `spacecraft-steelbore-standard` — cross-cutting compliance (licensing, SPDX, ISO 8601, naming).
 
 — Spacecraft Software, 2026

spacecraft-agentic-cli/SKILL.md

@@ -384,7 +384,7 @@ Assets:
 
 This skill is the **agent-UX layer** in the Spacecraft Software CLI skill stack:
 
-- **`spacecraft-standard-constitution`** — master Standard. Master wins on conflict.
+- **`spacecraft-steelbore-standard`** — master Standard. Master wins on conflict.
 - **`spacecraft-cli-standard`** — structural CLI Standard rules (what the CLI must
   be). Authoritative on structure. This skill is subordinate; never
   weakens its rules. Both load together when a Spacecraft Software CLI is in scope.

spacecraft-agentic-cli/assets/claude-md.template.md

@@ -37,7 +37,7 @@
 The following Spacecraft Software skills apply to this project. Consult them
 via the Skill tool when their triggers match:
 
-- `spacecraft-standard-constitution` — master Steelbore Standard
+- `spacecraft-steelbore-standard` — master Steelbore Standard
 - `spacecraft-cli-standard` — structural CLI Standard rules
 - `spacecraft-agentic-cli` — agent-facing UX for the CLI
 - `spacecraft-brand-guidelines` — brand look-and-feel

spacecraft-agentic-cli/references/agents-md-authoring.md

@@ -148,7 +148,7 @@ non-Claude harness cannot act on belongs here:
 > only Claude-Code-only context.
 
 ## Skills referenced
-- `spacecraft-standard-constitution` — master Standard
+- `spacecraft-steelbore-standard` — master Standard
 - `spacecraft-cli-standard` — structural CLI Standard
 - `spacecraft-agentic-cli` — agent-facing UX
 - `spacecraft-brand-guidelines` — color palette

spacecraft-cli-preference/CREDITS.md

@@ -4,7 +4,7 @@ The `spacecraft-cli-preference` skill recommends and documents modern CLI
 tools authored by many upstream projects. While the reference prose is
 original writing, flags and behaviours were cross-checked against the
 sources below. Filed in accordance with
-[The Steelbore Standard §15.3](../spacecraft-standard-constitution/SKILL.md).
+[The Steelbore Standard §15.3](../spacecraft-steelbore-standard/SKILL.md).
 
 ## Upstream sources
 

spacecraft-cli-preference/SKILL.md

@@ -487,7 +487,7 @@ documentation. See `references/ATTRIBUTION.md` for per-tool sourcing.
 ## §8 — Spacecraft Software Compliance Note
 
 This skill itself is a Spacecraft Software artifact and conforms to the relevant parts
-of The Steelbore Standard (see `spacecraft-standard-constitution` skill):
+of The Steelbore Standard (see `spacecraft-steelbore-standard` skill):
 
 - **§4** GPL-3.0-or-later license declared in frontmatter
 - **§12** ISO 8601 dates used throughout

spacecraft-cli-shell/SKILL.md

@@ -224,7 +224,7 @@ Full table: `references/bashisms.md`.
 ## Steelbore Standard Requirements (Shell Scripts)
 
 When writing Spacecraft Software shell script files, these rules from
-[The Steelbore Standard](../spacecraft-standard-constitution/SKILL.md) apply.
+[The Steelbore Standard](../spacecraft-steelbore-standard/SKILL.md) apply.
 
 ### §4 — SPDX License Header (mandatory)