@bongos/core 1.19.648 → 1.19.650

package/.claude/skills/builder-stage/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: builder-stage
 description: >-
-  Stage the current working tree on the builder's own live preview (the sandbox) to review a game or UI change in a browser BEFORE shipping — a dev-box sandbox host, or a private localhost preview on a laptop. Triggers: "/builder-stage", "stage my work", "let me see it before shipping", "preview this change". Own-scoped and machine-local.
+  Stage the working tree on the builder's own live preview to see a change in a browser BEFORE shipping. Own-scoped and machine-local. Triggers: "/builder-stage", "stage my work", "let me see it before shipping", "preview this change".
 ---
 
 You are staging a builder's in-progress work on **their own** sandbox — the live game preview running on their dev box (ADR 0044) — so they can see the change in a browser, suggest fixes, and only then decide to ship it to the main game (ADR 0046).

package/.claude/skills/builder-start/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: builder-start
-description: Start a Claude Code session by listing what tasks the builder can claim right now, filtered for parallel-safety against currently active claims across all builders. Triggers when the user says "what can I work on", "/builder-start", "show me tasks", "what's claimable", or at the start of a new session before doing other work.
+description: >-
+  List what the builder can claim right now, filtered for parallel-safety against every active claim. Triggers: "what can I work on", "/builder-start", "show me tasks", "what's claimable", or the start of a session.
 ---
 
 **Script skill (authoritative).** The core action is `node scripts/gds/start.js [--widget]`. Run it and render its output verbatim — do not rebuild the table, reorder rows, or add a recap. The card is the summary.

package/.claude/skills/builder-sync/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: builder-sync
-description: "Sync now — re-fetch the dev box's source immediately so a freshly-claimed task's code materializes within seconds, instead of waiting for the ~10-min cron. Triggers on '/builder-sync', 'sync my box', 're-scope my box', 'pull my task's code now', or right after '/builder-claim N' when the builder wants the code on the box now. Runs ON the box."
+description: >-
+  Re-fetch the dev box's source now instead of waiting for the ~10-min cron. Runs ON the box. Triggers: "/builder-sync", "sync my box", "re-scope my box", "pull my task's code now", or right after "/builder-claim N".
 ---
 
 **Script skill (authoritative).** The core action is `node scripts/gds/box-sync.js`. Run it and relay its output verbatim.

package/.claude/skills/close-box/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: close-box
-description: Tear down the dev box you are working on, from inside the box's terminal. Asks Bongos to deprovision the caller's own box (POST /box/close — the same action as the builders'-hall "Close box" button). Triggers when the user says "/close-box", "close my box", "shut down this box", "I'm done with this box", "tear down my dev box". Own-scoped — it deprovisions only the caller's own box; it never touches another builder's box or any other infrastructure (those live on the operator control plane, node scripts/gds/box.js).
+description: >-
+  Tear down the dev box you are working on, from inside its terminal. Own-scoped — never another builder's box and never any other infrastructure. Triggers: "/close-box", "close my box", "shut down this box", "I'm done with this box", "tear down my dev box".
 ---
 
 You are closing (deprovisioning) the dev box the builder is currently working on. This is the Claude-side twin of the `close-box` shell command (`infra/close-box.sh`) — same endpoint, for builders who'd rather say "/close-box" inside `claude` than drop to the shell. It is own-scoped and destructive (the box is destroyed), so confirm before firing.

package/.claude/skills/design/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: design
 description: >-
-  The UI design session — the operating playbook for ui-discipline work (layouts, pages, components, design systems, the hall / status / landing surfaces) on any Cloud Bongos instance. Show-first like /paint and world-first: the branding pack and DESIGN.md are read before any taste rule. Triggers: "/design", "design this page", "let's work on the UI", or a claimed ui task routing here.
+  The UI design session — the playbook for ui-discipline work: layouts, pages, components, design systems, the hall, status and landing surfaces. World-first: the branding pack and DESIGN.md come before any taste rule. Triggers: "/design", "design this page", "let's work on the UI", or a claimed ui task.
 ---
 
 You are running a **UI design session**. Two things make it different from the Engineer pack (`docs/packs/engineer.md`): the work is judged **by looking at it** (so every step ends in a rendered screen, not a paragraph), and it is done **inside a world that is not yours** — the instance's, which you read first and never override. The `ui-design` module's [CLAUDE.md](../../../modules/ui-design/CLAUDE.md) is the reference; this file is the loop.

package/.claude/skills/design-sync/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: design-sync
-description: Export the repo design system into Claude Design so prototypes start from real tokens and component surfaces, then land Claude Design's generated UI code back as a Bongos task. Triggers when the user says "/design-sync", "sync design", "export tokens to Claude Design", "import to Claude Design", or "push design system".
+description: >-
+  Export the repo design system into Claude Design, then land its generated UI code back as a task. Triggers: "/design-sync", "sync design", "export tokens to Claude Design", "import to Claude Design", "push design system".
 ---
 
 You are helping the builder run the Claude Design sync loop: export the repo's design tokens and surfaces into Claude Design so any prototype starts from real values, not guesses.

package/.claude/skills/feedback/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: feedback
-description: Pull the latest Bongos feedback bundle into this Claude Code session — the prompt.md walkthrough the Bongos app wrote (transcript + the ask) plus the screenshots it captured, loaded by absolute path so the Read tool can see them. Triggers when the user says "/feedback", "pull in my latest feedback", "load my bongos feedback", "I just recorded a walkthrough", "grab the latest feedback bundle", or "act on my screen recording". Local + read-only; no Bongos auth needed.
+description: >-
+  Pull the latest Bongos feedback bundle into this session — the walkthrough transcript and screenshots, by absolute path. Local and read-only. Triggers: "/feedback", "pull in my latest feedback", "load my bongos feedback", "I just recorded a walkthrough", "grab the latest feedback bundle", "act on my screen recording".
 ---
 
 You are pulling in the **latest Bongos feedback bundle** — a self-contained capture the user just recorded with the Bongos desktop app (BV1.R13 / [ADR 0087](../../../docs/adr/<redacted>.md)). The app turns a spoken screen walkthrough into a model-agnostic `prompt.md` (a timestamped transcript + an ask) plus a handful of screenshots, all under `~/CloudBongos/feedback/`. This skill loads that bundle so you can act on it directly — no copy-paste, no clipboard-image fiddling.

package/.claude/skills/figma-design-sync/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: figma-design-sync
-description: Sync the repo's UI design system (tokens + surfaces) with Figma — push current state so a designer never opens a stale file, then land a designer's Figma edit back as committed code. Triggers when the user says "sync design to Figma", "push tokens to Figma", "pull my Figma edit into code", or "figma round-trip". Distinct from otb-figma-sync, which is scoped to pixel-art tile review in the example Figma file only — this skill is the UI-surface round-trip from ADR 0081.
+description: >-
+  Round-trip the UI design system with Figma — push tokens and surfaces, then land a designer's edit back as code. Not otb-figma-sync, which is pixel-art tiles only. Triggers: "sync design to Figma", "push tokens to Figma", "pull my Figma edit into code", "figma round-trip".
 ---
 
 You are helping the builder run the Figma round-trip loop for the `ui` discipline's design surfaces: push the repo's current tokens/surfaces into Figma so a designer always starts from real state, then bring a designer's Figma edit back into the repo as committed-ready code.

package/.claude/skills/goal-create/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: goal-create
 description: >-
-  Plan and create ONE Bongos goal — the module-scoped workspace between a version and its criteria (ADR 0086). Reads the goal board, infers scope from the live module roster, drafts done-when criteria and seed tasks, asks only about gray areas. Triggers: "/goal-create", "create a goal", "what goal should this live in", or a task created with no goal. Metic+ only.
+  Plan and create ONE goal — the module-scoped workspace between a version and its criteria — drafting its done-when criteria and seed tasks. Metic+ only. Triggers: "/goal-create", "create a goal", "what goal should this live in", or a task created with no goal.
 ---
 
 You are running the **goal-create** session for this Cloud Bongos instance. You produce **one goal**: a title, a scope wall, two to four done-when criteria, and a handful of seed tasks — written to Bongos in one sitting.

package/.claude/skills/goal-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: goal-review
 description: >-
-  Walk the criterion review queue. Since ADR 0183 this is not a gate — criteria whose tasks all shipped satisfy themselves; what remains is the residue automation refuses (all linked tasks abandoned, or a criterion not actually met). Confirm, reject, or defer each. Triggers: "/goal-review", "review goals", "confirm criteria". Metic+ only.
+  Walk the criterion review queue — not a gate, since criteria whose tasks all shipped satisfy themselves. Confirm, reject or defer the residue. Metic+ only. Triggers: "/goal-review", "review goals", "confirm criteria".
 ---
 
 You are running the **goal-review** session for this Cloud Bongos instance. It mirrors `/idea-triage`, but for the *closing* end of the work hierarchy (ADR 0086 §6): criteria that have **auto-flagged "met — pending review"** get walked one-at-a-time and dispositioned, so finished work actually closes out instead of sitting in limbo.

package/.claude/skills/grade-audit/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: grade-audit
 description: >-
-  Manual accountability sweep over recent grades: the override ledger (what shipped despite a failing grade), dropped blocker/major findings on passing grades, a false-pass spot-check, an outage roll-up. Describes and queues follow-ups only — never confirms, flips a status, or re-grades (ADR 0162). Triggers: "/grade-audit", "audit recent grades", "what shipped past the grader".
+  Accountability sweep over recent grades: override ledger, dropped findings on passing grades, false-pass spot-check, outage roll-up. Queues follow-ups only — never confirms, flips a status, or re-grades. Triggers: "/grade-audit", "audit recent grades", "what shipped past the grader".
 ---
 
 You are auditing the last week of grades for accountability gaps: work that shipped past a failing grade unaccounted for, real findings that rode passing grades into production and evaporated, and passes the panel structurally could not have judged. You **describe and queue**. You never confirm, flip, re-grade, or add a gate — every follow-up lands as a queued idea or a handoff to another skill.

package/.claude/skills/grade-recover/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: grade-recover
 description: >-
-  Walk a stuck, unavailable, or wrongly-failed grade to resolution: diagnose which of three shapes parked the task at completed (grader outage, fabricated fail, genuine quality fail), name the right recovery, run it. Adds no gate to the ship path (ADR 0162). Triggers: "/grade-recover N", "my grade failed", "grader unavailable", or a ship that landed at completed with a non-pass grade.
+  Diagnose why a ship parked at completed — grader outage, fabricated fail, or genuine quality fail — and run the right recovery. Adds no gate to the ship path. Triggers: "/grade-recover N", "my grade failed", "grader unavailable", or a ship that landed at completed.
 ---
 
 You are recovering a task whose ship parked at `completed` because of its grade. Your job is to diagnose WHICH of three distinct shapes did it — they look similar in a terminal scrollback and need opposite responses — then run the right recovery. You never add a new approval step: everything here is a documented, existing path (ADR 0162).

package/.claude/skills/grader-health/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: grader-health
-description: Read-only health check over recent grades — consecutive outage runs, pass-rate drift vs baseline, per-grade cost anomalies, and stale model pins. The routine that would have caught the 21-outage 0.0-score streak on day one. Triggers when the user says "/grader-health", "check the grader", "is the grader healthy", "grader health check", "why are grades failing lately", or as part of a periodic ops sweep. Reports and emits exact remediation lines; changes nothing (ADR 0162 — no new gates, describe only). Optional --probe runs a live paid calibration (Metic+).
+description: >-
+  Read-only health check over recent grades — outage runs, pass-rate drift, cost anomalies, stale model pins. Changes nothing. --probe runs a live paid calibration (Metic+). Triggers: "/grader-health", "check the grader", "is the grader healthy", "grader health check", "why are grades failing lately".
 ---
 
 You are running a health check over the grading panel. Everything here is **read-only**: you read live surfaces, compare against known baselines, and emit findings + exact remediation commands. You never confirm, flip, or re-grade anything yourself — the builder (or /grade-recover) acts on what you report.

package/.claude/skills/idea-triage/SKILL.md

@@ -1,11 +1,7 @@
 ---
 name: idea-triage
 description: >-
-  Daily walk of the Bongos idea_inbox, which holds only HOMELESS work: a capture
-  naming a goal, and since ADR 0262 a bug from a trusted vector, become a task at
-  filing time and never reach it. Promote, discard or merge each open idea.
-  Triggers on "/idea-triage", "triage ideas", "review the inbox", "walk the idea
-  inbox", or a scheduled daily run. Metic+ only.
+  Daily walk of the idea_inbox, which holds only HOMELESS work — anything naming a goal became a task at filing time. Promote, discard or merge each open idea. Metic+ only. Triggers: "/idea-triage", "triage ideas", "review the inbox", "walk the idea inbox", or a scheduled daily run.
 ---
 
 You are running the daily idea-triage session for Example. Open ideas in the Bongos `idea_inbox` table get walked one-at-a-time and verdicted, so the inbox doesn't accumulate stale entries.

package/.claude/skills/merge-mode/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: merge-mode
-description: Manual fallback for the auto-merge in /builder-ship. Walks every task at status='confirmed' (= verified but not yet on main) and runs the merge + smoke + deploy chain. Triggers when the user says "/merge-mode", "merge the queue", "land confirmed tasks", "land the queue", "do a merge run", or after a /builder-ship reported the auto-merge bailed.
+description: >-
+  Manual fallback for the auto-merge in /builder-ship: walks every task at status='confirmed' through merge, smoke and deploy. Triggers: "/merge-mode", "merge the queue", "land confirmed tasks", "land the queue", "do a merge run", or a /builder-ship that reported the auto-merge bailed.
 requires: [main-checkout, push-credential, gh, droplet-ssh]
 ---
 

package/.claude/skills/new-project/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: new-project
 description: >-
-  Agent-guided runbook from zero to a live, owned STANDALONE Cloud Bongos instance (own repo + pinned @cloudbongos/core, ADR 0108): name and address, bongos init, scaffold, provision core + DB + address + service, GitHub OAuth app and first sign-in, verify, brand. Triggers: "/new-project", "stand up a new instance", "start a new project".
+  Runbook from zero to a live, owned STANDALONE instance: name, address, scaffold, provision, OAuth app, first sign-in, verify, brand. Triggers: "/new-project", "stand up a new instance", "start a new project".
 ---
 
 You are guiding a new owner from **zero to a live, owned Cloud Bongos instance**. This skill is the **canonical step sequence** (goal 35). The `bongos onboard` CLI and the hall wizard are just other front-ends over these same steps — keep them in lockstep by keeping the sequence here.

package/.claude/skills/otb-character-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: otb-character-review
 description: >-
-  Review a painterly character ANIMATION (many frames of one character) against the ADR 0088 criteria — same character throughout, correct anatomy, each frame on its pose, clean edges, smooth in-order motion — with a plain-language verdict per frame and for the sequence. Triggers: "review this animation", "is this animation consistent", "rate these frames". Sibling of otb-design-review (one tile).
+  Score a multi-frame character ANIMATION against the painterly criteria, with a verdict per frame and for the sequence. Sibling of otb-design-review, which scores one tile. Triggers: "review this animation", "is this animation consistent", "rate these frames".
 ---
 
 You are reviewing a painterly **character animation** — a `character_anim` family: many frames of the *same* character in *different* poses (e.g. the Bongo Buddha idle-breathing cycle). This is the animation sibling of `otb-design-review` (which scores one pixel-art tile). Do NOT judge it as pixel art — there is no palette to match, no FireRed reference, no 32×32 grid.

package/.claude/skills/otb-design-review/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: otb-design-review
-description: Score an existing pixel-art tile against the Example rubric. Triggers when user says "review this tile", "score X", "rate Y", or asks how a generated asset stacks up. Returns per-criterion scores, a critique, a verdict (pass/retry/escalate_tier), and a fix_hint. Uses Gemini 2.5 Flash vision plus deterministic palette/grid checks.
+description: >-
+  Score a pixel-art tile against the Example rubric: per-criterion scores, a critique, a pass/retry/escalate verdict and a fix_hint. Triggers: "review this tile", "score X", "rate Y", or asking how a generated asset stacks up.
 ---
 
 You are scoring a generated tile against the Example quality rubric. Do NOT critique freelance — use the rubric in `modules/art-pipeline/template/rubric.json`.

package/.claude/skills/otb-feedback-capture/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: otb-feedback-capture
-description: Convert verbal design feedback into a durable rule appended to the Example style guide. Triggers when Lars gives directional notes ("trees too modern", "saturation too high", "containers should look weathered"). Updates modules/art-pipeline/template/style_guide.md with a dated rule so future generations automatically respect it. This is how the system gets better over time.
+description: >-
+  Turn verbal design feedback into a durable dated rule in the Example style guide. Triggers: directional notes such as "trees too modern", "saturation too high", "containers should look weathered".
 ---
 
 You are turning a one-time piece of feedback into a permanent guardrail. The whole point of this skill is that **Lars should not have to repeat himself**. If he tells you trees should be more gnarled, every future tree generation should bake that in.

package/.claude/skills/otb-figma-sync/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: otb-figma-sync
-description: Push generated tiles into the Example Figma file as a visual review canvas. Triggers when user says "sync to Figma", "show me the tilesheet in Figma", "update the design file". Hard-coded to file ID <redacted>. Refuses to touch any other Figma file. Repo remains the source of truth — Figma is a viewer.
+description: >-
+  Push generated tiles into the Example Figma file as a review canvas. Hard-coded to one file ID; refuses any other. The repo stays the source of truth. Triggers: "sync to Figma", "show me the tilesheet in Figma", "update the design file".
 ---
 
 **Script skill (authoritative).** The core action is the `use_figma` MCP tool call. Execute it with the determined parameters and do not paraphrase or reformat the Figma response — relay the frame name and link verbatim.

package/.claude/skills/otb-tile-generate/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: otb-tile-generate
-description: Generate one or more pixel-art tiles for the Example world. Triggers when user says "generate a tile", "make a sprite for X", "regenerate Y", or asks for new world art. Reads the design template, runs the full generate→post-process→review→retry orchestrator, saves results into modules/art-pipeline/generated/tiles/, logs cost. Always reuses the locked palette and rubric in modules/art-pipeline/template/.
+description: >-
+  Generate pixel-art tiles for the Example world through the generate, review and retry orchestrator. Always reuses the locked palette and rubric. Triggers: "generate a tile", "make a sprite for X", "regenerate Y", or asking for new world art.
 ---
 
 You are operating the Example pixel-art generation pipeline. The user has asked you to produce one or more tiles. Do NOT freelance — use the existing pipeline.

package/.claude/skills/planning-session/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: planning-session
-description: Run a structured planning session for an upcoming Bongos version — set scope criteria, draft a written spec, interview the owner in depth to resolve every non-obvious decision, then seed the ranked task list from that spec. Triggers when the user says "/planning-session", "open a planning session", "let's plan V[N]", "plan the next version", or "scope a new version". Metic+ rank only (Metic and Archon; not Xenos).
+description: >-
+  Structured planning for a version — scope criteria, a written spec, an owner interview on every non-obvious decision, then the seeded task list. Metic+ only. Triggers: "/planning-session", "open a planning session", "let's plan V[N]", "plan the next version", "scope a new version".
 requires: [droplet-ssh]
 ---
 

package/.claude/skills/priority-session/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: priority-session
-description: Run a structured priority session — a trusted builder answers a handful of plain-speech questions, and the answers reweight the Bongos idea_inbox and suggest what to claim next. Triggers when the user says "/priority-session", "run a priority session", "what should I work on next", "reprioritize the inbox", "what feels most important right now", or "help me decide what to claim". Metic+ rank only (Metic and Archon; not Xenos).
+description: >-
+  A trusted builder answers a few plain questions; the answers reweight the idea_inbox and suggest what to claim next. Metic+ only. Triggers: "/priority-session", "run a priority session", "what should I work on next", "reprioritize the inbox", "what feels most important right now", "help me decide what to claim".
 ---
 
 You are running a **priority session** for Bongos. Where a **planning session** sets a *version's* scope (criteria + a fresh ranked task list), a priority session works the *present tense*: it takes the open `idea_inbox` exactly as it stands and reweights it against how the builder actually feels about the work right now — what's stuck, what would unblock the most people, what they're excited to build. The session ends with a **weighted ranking of the open ideas** and a single **"what should I claim next?"** suggestion, and it writes a durable session-log entry so the reweighting is on the audit trail.

package/.claude/skills/read-session-export/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: read-session-export
-description: Read a Claude Code `/export` zip quickly and consistently — the conversation, the assistant's thinking ("the thoughts"), and what the tools did — so you can answer questions about a past session. Triggers when the user drops a `session-export-*.zip` (or names one) and says "read this session", "what happened in this session", "what was I/you thinking here", "summarize this export", "read the latest session export", or "/read-session-export". This READS the existing export — it does not create a new one. Local + read-only, no Bongos auth, no network.
+description: >-
+  Read a Claude Code /export zip — conversation, thinking, and tool calls — to answer questions about a past session. READS an existing export, never creates one. Local and read-only. Triggers: a dropped session-export-*.zip, "read this session", "what happened in this session", "what was I/you thinking here", "summarize this export", "read the latest session export", "/read-session-export".
 ---
 
 The user already has the zip — Claude Code's built-in `/export` made it. Your job is to **read it well**: a session export is the same shape every time, so don't go spelunking through it by hand or load the megabytes of debug logs. Run the reader, which prints a compact transcript (prompts + thinking + replies + one-line tool calls) to stdout, then answer whatever the user actually asked.

package/.claude/skills/recall/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: recall
-description: One-call project-knowledge search across the repo docs + DB prose (tasks, learnings, session logs). Triggers when the user says "/recall", "recall …", "what do we know about X", "have we done X before", "did a past session hit X", "search the docs/ADRs for X", "is there an ADR about X", or before re-solving something that smells already-solved. Read-only; rank-scoped server-side. Run it instead of grepping the tree or asking the user to remember.
+description: >-
+  One-call project-knowledge search over repo docs and DB prose. Read-only, rank-scoped. Use instead of grepping the tree. Triggers: "/recall", "recall …", "what do we know about X", "have we done X before", "did a past session hit X", "search the docs/ADRs for X", "is there an ADR about X".
 ---
 
 You are answering "what do we already know about X?" — the GDS-V4 one-call-recall capability ([ADR 0060](../../../docs/adr/0060-gds-retrieval-layer.md)). Before this existed, recall meant grepping the repo + eyeballing session logs + hoping you remembered the right ADR. Now one call searches the indexed corpus (every repo markdown + nightly-indexed DB prose: task descriptions, learnings, session-log summaries, recent shipped-task summaries) with full-text + typo-tolerant fuzzy matching fused by RRF, and returns the most relevant sections with their breadcrumb (file > heading > subheading).

package/.claude/skills/scan-before-install/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: scan-before-install
 description: >-
-  Scan a third-party GitHub repo or git-hosted Claude plugin BEFORE installing anything: quarantined fetch, deterministic floor, tiered subagent panel over a scrubbed mirror, arithmetic verdict, honest-limits report, three evidence-gated landings. The scanner never installs. Triggers: "/scan-before-install", "is this plugin safe to install", "vet this GitHub repo".
+  Vet a third-party GitHub repo or Claude plugin BEFORE installing: quarantined fetch, deterministic floor, subagent panel over a scrubbed mirror, arithmetic verdict, evidence-gated landings. The scanner never installs. Triggers: "/scan-before-install", "is this plugin safe to install", "vet this GitHub repo".
 ---
 
 You are scanning a third-party artifact someone wants to install. The engine lives in `modules/security/artifact-scan/` — this skill is the orchestration wrapper: it runs the pipeline, spawns the panel, and lands one of three offers. Every load-bearing decision below is an owner decision; do not soften any of them.

package/.claude/skills/session-handoff/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: session-handoff
-description: Emit a clean, paste-ready "next-steps" prompt to start a FRESH session with — so the next session begins with tight, curated context instead of dragging the whole transcript forward. Triggers when the user says "/session-handoff", "hand off to a fresh session", "give me a handoff prompt", "wrap up context for next time", "write the next-steps prompt", "I want to continue this in a new session", or "context is getting heavy, prep a fresh start". Read-only — it composes text, it changes no state.
+description: >-
+  Emit a paste-ready next-steps prompt so a FRESH session starts with curated context. Read-only. Triggers: "/session-handoff", "hand off to a fresh session", "give me a handoff prompt", "wrap up context for next time", "write the next-steps prompt", "I want to continue this in a new session", "context is getting heavy, prep a fresh start".
 ---
 
 You are producing a **handoff prompt**: a single, self-contained block of text the builder will **copy and paste as the first message of a brand-new session** to continue this work with a clean, light context.

package/.claude/skills/ship-check/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ship-check
 description: >-
-  Run every freshness and fitness check ship.js will run, in one command, before shipping — and get the healing command for each stale generated file. Triggers: "/ship-check", "am I ready to ship", "what will ship trip on", "check before I ship", "is anything stale".
+  Run every freshness and fitness check ship.js will run, and get the healing command for each stale file. Triggers: "/ship-check", "am I ready to ship", "what will ship trip on", "check before I ship", "is anything stale".
 ---
 
 # /ship-check — the pre-ship table

package/.claude/skills/status/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: status
-description: Answer "what's the status of X" / "what's left for criterion Cn" in one call. Triggers when the user says "/status", "what's left for C8", "status of GDS-V3", "how far along is the memory criterion", "what tasks remain to complete X", or asks how a version/criterion is progressing. Read-only — rolls up each done-when criterion → its gating tasks → live statuses → what's blocking.
+description: >-
+  Roll up a version or criterion in one call — its gating tasks, their live statuses, and what is blocking. Read-only. Answers "what's the status of X" and "what's left for criterion Cn". Triggers: "/status", "what's left for C8", "status of GDS-V3", "how far along is the memory criterion", "what tasks remain to complete X".
 ---
 
 You are answering a project-status question. Before this skill existed, doing so meant ~10 sequential Bongos calls (grep the seed file for which tasks map to a criterion, eyeball a "Gates R55–R63" sentence, then re-query each task's status). The structured criterion↔task link (`task_criteria`, migration 055) + the `/status` CLI collapse that to one call. See ADR 0025 and task #435.

package/.claude/skills/strand-fix/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: strand-fix
 description: >-
-  Walk ONE stranded ship to landed — a task parked at confirmed that the reconciler gave up on (strand:no_branch_no_tip, strand:land_not_proven). Finds where the work is, makes the one sanctioned move, verifies the flip to shipped. Also the fix for a claim refused 409 REBASE_REQUIRED. Triggers: "/strand-fix N", "task N is stranded", "land the strand", "my claim says REBASE_REQUIRED".
+  Land ONE stranded ship — a task parked at confirmed that the reconciler gave up on. Also the fix for a claim refused 409 REBASE_REQUIRED. Triggers: "/strand-fix N", "task N is stranded", "land the strand", "my claim says REBASE_REQUIRED".
 requires: [gh]
 ---
 

package/.claude/skills/worktree-clean/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: worktree-clean
 description: >-
-  Remove the per-claim worktrees whose work already landed (branch merged into origin/main, or deleted by the ship): lists them, then removes each through the junction-safe worktree.js remove — never raw git worktree remove, which follows the node_modules junction (task 1002809). Triggers: "/worktree-clean", "prune stale worktrees", or the SessionStart line "Stale worktrees: N".
+  Remove per-claim worktrees whose work already landed, via the junction-safe worktree.js remove — never raw git worktree remove, which follows the node_modules junction. Triggers: "/worktree-clean", "prune stale worktrees", or the SessionStart line "Stale worktrees: N".
 ---
 
 **Script skill (authoritative).** Two scripts do the work; this skill only sequences them and shows the list before anything is removed.

package/docs/adr/0276-the-skill-listing-budget-cannot-hold-every-trigger.md

@@ -0,0 +1,121 @@
+# 0276 — The skill-listing budget cannot hold 64 skills and every trigger, so the number is ratcheted and the choice goes to the owner
+
+**Status:** Accepted (the ratchet). The budget question itself is **open and owner-gated** — [blocker #1000139](https://cloudbongos.com/builders#/blocker/1000139), see §5.
+**Task:** [#1003620](https://cloudbongos.com/builders#/task/1003620) · goal 1000095 — *Working area 6*, criterion `wa6-role-experience`
+**Builds on:** [ADR 0274](<redacted>.md) (which measured the listing at 27,022 chars against a ~8,000 budget and sequenced this task behind it), tasks 1003548 and 1003587 (the two earlier trims)
+
+## 1. The problem, and why trimming keeps not solving it
+
+Every SKILL.md `description` is resident in **every session**, for every craft,
+whether or not the skill is invoked. `skill-lint.js` budgets the whole listing —
+each skill's name plus its description — at **8,000 chars** ("~2k tokens ≈ 1% of
+a 200k window") and warns when it is over.
+
+It has been over for a long time, and it has been trimmed twice:
+
+| pass | skills | listing |
+|---|---|---|
+| task 1003548 — "shorten the 9 longest" | ~60 | — |
+| task 1003587 — the 14 module ui-design descriptions | 65 | 26,385 |
+| **task 1003620 — this one, 49 descriptions** | 64 | **25,624 → 19,316** |
+
+Each pass shrank it and each time it grew back, because the per-description aim
+(400 chars) was a **warning that accumulates**: nothing fails, so the number
+drifts up until someone files another cleanup task.
+
+## 2. What this task did
+
+Rewrote 49 of the 50 `.claude/skills/` descriptions — cutting implementation
+paths, ADR and task numbers, script names and second explanatory clauses.
+`skill-lint` goes from 17 warnings to **0 errors, 0 warnings**, and the listing
+from 25,624 to 19,316 chars (~6,400 → ~4,830 tokens): about **1,570 tokens
+returned to every session**.
+
+The 14 `modules/ui-design/` descriptions were deliberately not touched — task
+1003587 rewrote them a week earlier and they sit at ~384 chars each.
+
+**Every trigger phrase was preserved, and that was checked mechanically**, not
+by eye. A checker extracted the quoted phrases from each description at HEAD and
+asserted each still appears in the rewrite. It caught five genuine losses in the
+first pass (builder-reauth's full error string, `read the latest session
+export`, two session-handoff phrases, two status phrases) which were restored.
+Four quoted strings were dropped on purpose because they were never triggers:
+UI button labels (`Close box`, `Re-issue CLI token`, `CLI Access`, `key needed`)
+and one gloss (`the thoughts`).
+
+## 3. Why 8,000 was not reached, stated as arithmetic
+
+This is the part that matters, because the task's DONE WHEN asked for it and
+this record is where the shortfall is declared rather than buried.
+
+With 64 skills:
+
+```
+names                                    880 chars
+quoted trigger phrases (mandatory)     ~5,370 chars
+                                       ------------
+irreducible floor                      ~6,250 chars
+budget                                  8,000 chars
+                                       ------------
+left for saying what each skill DOES   ~1,750 chars  ->  ~27 chars per skill
+```
+
+Twenty-seven characters. Reaching the budget therefore means **trigger-only
+descriptions**: no statement of what the skill is for. That trades one routing
+failure for another — truncation is avoided, and the semantic signal the router
+leans on when the user's words do not literally match a trigger is deleted.
+The scope note on the task forbids exactly this: *"a description is routing
+text, and cutting a trigger silently stops a skill from being found."* The same
+logic applies to the sentence that says what the thing does.
+
+So the shortfall is not a trim left half-finished. **The budget and the roster
+are in conflict**, and no amount of editing resolves it.
+
+## 4. Decision: ratchet the number
+
+`skill_listing_chars` becomes a ratcheted metric in
+`scripts/gds/fitness-ratchets.js`, baselined at **19,316**. CI fails if the
+listing grows; lowering it when a description genuinely tightens is the ordinary
+path. The collector fails **open** if the linter cannot load — this must never
+be the reason a build cannot run.
+
+This answers the question the task raised (*"consider whether the 400-char aim
+should become a hard error at some ratcheted ceiling rather than a warning that
+accumulates"*) in the way the repo already answers it for size, duplication,
+cycles, console calls and doc entropy.
+
+**The baseline is deliberately above skill-lint's own 8,000 budget and is not a
+claim the budget is met.** It records today's real number so it cannot get worse
+while the question in §5 is open.
+
+## 5. Open, and the owner's to decide
+
+Three ways to actually reach 8,000, none of which a cleanup task should pick
+unilaterally:
+
+1. **Delist skills.** 64 is a lot to hold resident. Many are ops routines
+   (`builder-backup`, `close-box`, `otb-figma-sync`) a session almost never
+   needs. If the listing carried 30, the budget fits with room for real prose.
+2. **Scale the budget with the roster** — a per-skill ceiling (say 250 chars)
+   rather than a global 8,000, which was set when the roster was smaller and
+   silently became stricter with every skill added.
+3. **Accept trigger-only descriptions** and take the routing hit.
+
+Recommendation: **(1) then (2)**. The listing is a menu, and a 64-item menu is a
+context cost whatever the wording. Filed for the owner as **blocker [#1000139](https://cloudbongos.com/builders#/blocker/1000139)**
+rather than left in this file, because a decision nobody is asked to make is not
+a decision.
+
+## 6. Consequences
+
+- `fitness.js`'s `skill frontmatter parses` check **still warns** that the
+  listing is over budget. That warning is now correct and load-bearing: it is
+  the visible trace of the open question, and it should stay until §5 is
+  answered.
+- A new skill is no longer free. Adding one costs its name plus its description
+  against a ratchet that fails the build — which is the intended pressure.
+- Rejected: raising skill-lint's `LISTING_BUDGET_CHARS` to 19,316 so the warning
+  goes away. That deletes the signal instead of the debt, and the file's own
+  policy forbids moving a number to make a gate pass.
+- Rejected: cutting the module ui-design descriptions again a week after task
+  1003587 wrote them, to buy ~2,000 chars toward a target still 9,000 away.

package/docs/adr/README.md

@@ -367,3 +367,4 @@ This keeps the decision history honest and traceable.
 | 0272 | [**A craft is an identity, not a toolchain: `artist` becomes core** ([task 1003719](https://cloudbongos.com/builders#/task/1003719) · goal 1000111 — *Government*). Reported from Discord on 2026-08-15 as "cant save preferences of role types in account page"; reproduced live 2026-09-09: `GET /me` returns `preferred_disciplines: ["artist","ideator"]` and `PATCH /me/disciplines` with that SAME array returns `422 invalid_discipline {bad:["artist"]}` — the API handing a builder a value and refusing to accept it back. **Cause:** `updateBuilderDisciplines` validates against `enabledDisciplines()`, and R59 (task 1198) put `artist` in the module half on the reasoning that the craft existed to make the game pixel art, so it rode `art-pipeline`. **That gate had stopped existing** — art-pipeline was never converted to a discovered module, there is no `modules/art-pipeline/module.json`, and so NOTHING declared `contributes.disciplines: ["artist"]`. Measured on a FULL repo checkout with the pipeline present on disk: `["engineer","ideator","ui"]`. The craft was offered by no instance in any configuration, and is unreachable by construction on a published core anyway, since [ADR 0098](<redacted>.md) excludes `modules/art-pipeline/` for a hard copyright reason (ripped reference maps). Meanwhile it stayed first-class everywhere else: the `builders.preferred_disciplines` CHECK (086/176), `tasks.discipline`, and the help-request craft roster all accept it — so a TASK could be an artist task and a PERSON could not be an artist. **The tests were green because they skipped:** the artist assertion sat behind `if (!EFFECTIVE["art-pipeline"]) return;`, always false, so the only real leg never ran. **Decision:** `artist` joins `CORE_DISCIPLINES` → `["engineer","artist","ideator"]` (migration 176 enum order); modules still contribute their own (ui-design → ui). A craft names WHO A BUILDER IS, not which toolchain ships — an instance can have artists without a pixel-art pipeline, and binding the identity to one optional module was the category error. The new invariant, pinned with no skip guard over the widest module set: anything the DB CHECK will store, some instance shape must offer. Rejected: enabling art-pipeline (impossible — absent from the package, and enabling an absent module throws at boot); writing the missing manifest (works only in a full checkout); an instance-declared discipline list (leaves the core CHECK describing a craft core cannot offer, and does not fix the vanilla case); stripping unofferable crafts from stored rows (deletes a builder stated identity to make a validator mistake look consistent). No migration — the rows were always CHECK-valid; only the validator disagreed.](<redacted>.md) | crafts / instance composition |
 | 0274 | [**One kernel, three role packs: the always-loaded instructions stop being an engineer's** ([task 1002990](https://cloudbongos.com/builders#/task/1002990) · goal 1000095 — *Working area 6, Governor / Builder / Artist / Ideator experience*, criterion `wa6-kernel-and-packs`). The root `CLAUDE.md` loads in full every session for every craft, and it was an engineer's document: 250 lines / 32,422 chars of claim-before-working, worktree-per-claim, `DEPS_NOT_SHIPPED`, `touches[]` and `/merge-mode`. An ideator and an artist each paid the full token cost of a pipeline they were not going to run and read it as instructions addressed to them — and it CONTRADICTED the same goal's `wa6-drift-stops-the-session`, which says ideation *"needs no claim"*, while the kernel's hard rule said every change is backed by one. The craft-specific half lived in three SKILLS (`/dev`, `/ideate`, `/paint`), the wrong carrier twice over: a skill's description is resident in every session's listing whatever craft is running (27,022 chars against a ~8,000 budget, three of them over-length), and a skill must be INVOKED — a session that never types the command works from the kernel alone, which is the engineer's document again. **Decision: a role-neutral kernel plus one pack per craft under `docs/packs/`, bound by a registry CI checks.** The kernel keeps what is true for every craft (the lifecycle, the money, the trust boundary, the identity split, the charter, navigation) and drops to 216 lines / 22,572 chars, clearing the character target it had been over; the per-line test gains a second half — *is it true for every craft?* The Engineer pack inherits today's methodology; the Ideator pack absorbs `/ideate` and writes down the two grades the criterion names (a quick idea stays ONE LINE, then Claude ASKS whether to develop it into a Full Idea — five questions drawn out of the conversation, in the ideator's own words, scored on completeness); the Artist pack absorbs `/paint`, generalised off the pixel-art pipeline per [ADR 0272](<redacted>.md) — show-first, as little interpretation as possible, and ARRIVE PRECALCULATED, because a session that opens with intake questions is a form. The three skills are deleted. `scripts/gds/discipline-modes.json` becomes the ROLE REGISTRY: a core craft names a `pack` (a file to read), a module-contributed discipline may still name a `skill` (`ui` → `/design`, unchanged as ADR 0272 requires), and `claim.js` prints whichever with the right verb. **`scripts/gds/role-pack-guard.js` HARD-FAILS CI** on a pack path that resolves to nothing, an entry with neither pointer, fewer than three packs, or a pack over budget (16,000 hard / 13,000 target) — hard precisely BECAUSE `claim.js` fails open: a broken path degrades to silence, the role is hollow, and no error says so, so CI is the only gate ("CI budgets each pack"). `docs/packs/` over `.claude/packs/` because `docs/` is already owned by the `methodology` scope key — a new top-level path resolves to NO key, and the scope map's own comment records the cost (a missing key is an empty wall, and goal-scope-check then denies every member-authored task); it is registered explicitly in the default-deny publish allowlist, in lockstep with the registry, or a released core would print an unresolvable pack path on every claim. `ship-card.js` moved with the claim (it would have shipped an "Open the work" button firing a deleted command — the 1003487 divergence in reverse) and `tests/idea_ideate_full.mjs` moved with its subject, its thirteen Full-Idea assertions passing against the pack unchanged. Governor is deliberately DEFERRED — three packs, not four, until the owner decides; the guard floors at three. Rejected: keeping the skills beside the packs (two homes drift, and the listing cost stays); packs AS skills (the exact failure being fixed); duplicating the safety rules into all three packs (the charter forbids it — three copies drift and the kernel becomes the one nobody trusts); leaving the guard advisory like the doc-comment check (that one gates a judgement, this one gates a resolvable path). **Not done:** the kernel is 216 lines against a ~200 target — still a warning, as it was at 250; the line count is the context-budget cluster's work (tasks 1003620/1003687/1003688), which the goal's audit sequenced behind this one.](<redacted>.md) | methodology / roles / context budget |
 | 0275 | [**A role's written responsibility has one source, and the pack's copy is generated** ([task 1003732](https://cloudbongos.com/builders#/task/1003732) · goal 1000095 — *Working area 6*, criterion `wa6-written-responsibilities`; statements fixed by the area owner 2026-09-08). The criterion is one sentence — *"one source, shown on the profile, injected into the pack, referenced by grading"* — and before this task the three statements existed only in the criterion record, nowhere in the tree. The interesting half is why ONE source and not three good copies: if each consumer holds its own, they drift, and the drift has a specific unfair shape — the project shows a builder one standard on their profile, teaches their session a second, and grades the shipped work against a third, so someone is judged by a rule they were never shown. **Decision: a frozen map at `src/role-responsibilities.js` (verbatim owner text, imports nothing), read by three consumers, with the one copy that CAN drift generated and CI-gated.** The hall reads it through `clientModules()` — already injected into every served page as `window.__MODULES__` and already carrying the discipline roster the statements are keyed by, so the profile renders with no new route, no fetch and no copy. The grader reads `responsibilityFor()` through the module doorway and states the standard in the prompt as the project's, not its own. The PACKS get a generated block: markdown cannot require a JS module, so their copy is the only one that can go stale — and it is the worst to lose, being what a session is actually instructed by. `gen-role-responsibilities.js` writes it from the ROLE REGISTRY (so a renamed pack, or Governor when the owner decides, needs no edit), and `role-pack-guard.js` fails CI on drift. Three consequences worth the record. (1) `fitness.js` needed an EXEMPTION for the owner's own prose: the ideator's statement opens "Make good ideas" and `ideas` is a module key, so the no-module-keys scan flagged an English word — paraphrasing to satisfy a scanner is precisely what the task forbids, so the reason is written down and the file's import DIRECTION is still guarded. (2) Registering the freshness check inside `checkGeneratedArtifactsFresh` pushed `fitness.js` one line past its 1,500-line ratchet; rather than raise the baseline (which the check forbids in its own message) the assertion MOVED into `role-pack-guard.js`, which already owns the packs — one check now answers "are the packs correct". (3) The generator matches each pack's own line ending, because `.md` checks out CRLF on Windows and LF in CI, and a generator that always wrote `\n` would make the gate red on one checkout and green on the other for a file nobody touched. A craft with no statement (`ui`, module-contributed per [ADR 0272](<redacted>.md); Governor, deferred per [ADR 0274](<redacted>.md)) renders NOTHING everywhere — no empty quote, no grader line — because a grader told a role has no written standard would supply its own. The profile's avatar was repinned to the top row (the head grid is `align-items:center`, fine for three short lines, wrong once the block made the column tall); verified in both themes in the hall preview. `tests/role_responsibilities.mjs` asserts the criterion's actual content by sweeping `src/`, `scripts/`, `modules/`, `tests/` and `docs/packs/` for any second copy. Rejected: three hand-written paragraphs (the drift would be invisible); a dedicated route for the hall (a fetch and a failure mode for static text already on a rail); storing the statements in the DB (not live state — a row puts the project's written standard outside code review); letting the grader describe a craft from its name (the invented standard this removes); raising `oversized_file_count` to let `fitness.js` grow.](<redacted>.md) | roles / grading / generated artifacts |
+| 0276 | [**The skill-listing budget cannot hold 64 skills and every trigger, so the number is ratcheted and the choice goes to the owner** ([task 1003620](https://cloudbongos.com/builders#/task/1003620) · goal 1000095 — *Working area 6*, criterion `wa6-role-experience`). Every SKILL.md description is resident in EVERY session for every craft, and `skill-lint` budgets the whole listing at 8,000 chars. It has been trimmed twice ([#1003548], [#1003587]) and grown back both times, because the 400-char per-description aim was a WARNING THAT ACCUMULATES. This task rewrote 49 of the 50 `.claude/skills/` descriptions — 17 warnings to 0, listing 25,624 → 19,316 chars, about 1,570 tokens returned to every session — with every trigger phrase preserved and CHECKED MECHANICALLY (a checker diffed the quoted phrases against HEAD and caught five real losses, all restored; four dropped strings were UI labels, not triggers). **8,000 was not reached, and the arithmetic says it cannot be:** across 64 skills the names (880) plus the mandatory quoted triggers (~5,370) are an irreducible ~6,250, leaving ~27 chars per skill to say what the skill DOES. Reaching the budget means trigger-only descriptions — trading truncation for the loss of the semantic signal routing leans on when the user’s words do not literally match a trigger. **Decision: ratchet `skill_listing_chars` at 19,316** in `fitness-ratchets.js` (fails open if the linter cannot load), so it cannot grow while the real question is open; the baseline is deliberately ABOVE skill-lint’s budget and is not a claim the budget is met. **Open and owner-gated:** delist skills (64 is a menu), scale the budget with the roster, or accept trigger-only text — recommendation is delist then rescale, filed as a blocker. `fitness.js`’s over-budget warning STAYS, as the visible trace of that question. Rejected: raising `LISTING_BUDGET_CHARS` to silence the warning (deletes the signal, not the debt); re-cutting the 14 module ui-design descriptions a week after [#1003587] wrote them, for ~2,000 chars toward a target still 9,000 away.](<redacted>.md) | skills / context budget / routing |

package/docs/module-api-changelog.md

@@ -1745,5 +1745,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.646 with no explicit bump. run 34515733973. (task 1002620)
   1.19.648 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.647 with no explicit bump. run 34518387614. (task 1002620)
+  1.19.649 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.648 with no explicit bump. run 34523111338. (task 1002620)
+  1.19.650 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.649 with no explicit bump. run 34523753119. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.648",
+  "version": "1.19.650",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bongos/core",
-      "version": "1.19.648",
+      "version": "1.19.650",
       "license": "AGPL-3.0-or-later",
       "dependencies": {
         "express": "^4.21.2",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.648",
+  "version": "1.19.650",
   "description": "Cloud Bongos — the AI-first build platform core (GDS + platform surfaces + module system), installed as a versioned dependency (ADR 0108).",
   "license": "AGPL-3.0-or-later",
   "main": "src/platform-server.js",

package/scripts/gds/fitness-ratchets.js

@@ -317,6 +317,29 @@ function gdsMetrics() {
   return { legacy_gds_literals: scanGdsLiterals().total };
 }
 
+// skill_listing_chars — the resident cost of the skill listing (every name +
+// description, both skill homes). Ratcheted rather than merely warned about
+// because this number has now been trimmed three times (tasks 1003548, 1003587,
+// 1003620) and grown back each time: a warning that accumulates is a warning
+// nobody acts on. Every char here sits in EVERY session, so growth is a context
+// tax on all work, not a lint nit.
+//
+// Fails OPEN if the linter cannot load — this ratchet must never be the reason
+// a build cannot run.
+function skillListingMetrics() {
+  try {
+    const lint = require('./skill-lint.js');
+    return { skill_listing_chars: lint.lintSkills(lint.listSkillFiles()).listingChars };
+  } catch (e) {
+    // Fail open, but never SILENTLY: an unenforced ratchet that says nothing is
+    // indistinguishable from a passing one, which is how a budget stops being a
+    // budget. The metric is omitted (so compareToBaselines skips it) and the
+    // reason is on stderr.
+    process.stderr.write(`fitness-ratchets: skill_listing_chars NOT MEASURED — skill-lint unavailable (${e && e.message}); the listing budget is unenforced this run\n`);
+    return {};
+  }
+}
+
 function computeMetrics({ withDocs = true } = {}) {
   const files = trackedJsFiles();
   const contents = new Map(files.map((f) => [f, readRepoFile(f)]));
@@ -326,6 +349,7 @@ function computeMetrics({ withDocs = true } = {}) {
     require_cycle_count: countCycles(requireGraph(contents)),
     console_call_count: consoleCallCount(contents),
     ...gdsMetrics(),
+    ...skillListingMetrics(),
     ...(withDocs ? docMetrics() : {}),
   };
 }

package/src/module-api.js

@@ -71,7 +71,7 @@ const { responsibilityFor, ROLE_RESPONSIBILITIES } = require('./role-responsibil
 // there. scripts/gds/bump-version.js still rewrites the literal below; it appends
 // the entry to that file. Look for a version's history there, not here.
 // ---------------------------------------------------------------------------
-const CORE_VERSION = '1.19.648'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.650'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
 
 // A namespaced logger so a module's log lines are attributable + consistent.
 // Usage: const log = api.logger('dev-box'); log.info('mounted');