Reconcile skill currency, obsolete process routes and framework consumer adoption #4785

Historical current fields before the protected plan and selected source composition update, retained verbatim:

## Current deliverable

The coherent canonical-correction and selected SDD adoption Delivery [#4789](https://github.com/FS-GG/.github/issues/4789) is created and natively linked to this Outcome. The planning worker and root intake operation have retired; qualified membership/planning and protected-enrollment preparation are now active. /root/knowledge_fable_receiver remains accountable for the complete Delivery, waiting for actual implementation admission. SDD is the selected supported framework Kit consumer; Coordination remains outside Kit participation under ADR0078. No implementation, publication, materialization or runtime adoption is accepted.

## Next action

Programme/root completes #4789’s qualified membership/planning, protected enrollment and current-caller qualification, then separately admits the same owner to its exact canonical/receiver scope. That owner carries canonical correction, generated mirrors/manifests, review/CI and normal source delivery through a fresh coherent publication and selected SDD materialization, both declared roots, actual existing Codex discovery/identity checks and deliberate mismatch refusal/restoration. Preserve hub-only operator discovery and explicit unselected-consumer exceptions. Use this one coherent child; no card per finding, global vendored patch or duplicate controller Outcome. #4647 remains the sole future controller-migration owner.

## Blocked on

No obstacle blocks the authorized current audit/source-planning work. Exact consumer rollout, canonical correction scope and global managed-skill routing disposition remain to be selected by the accountable owners before dependent implementation. The future thin-client conversion still depends on the actual qualified controller delivered under #4647. Visible membership and active planning do not supply protected enrollment, publication, consumer materialization, runtime discovery or completed acceptance.

## Acceptance evidence

On 2026-10-21 the user explicitly asked, “cant you add #4785 to your current workload?” Programme/root accepted that priority change and assigned the existing /root/knowledge_fable_receiver to the current scoped planning work. The actual600-second planning clock starts at monotonic193339.851564503 and ends193939.851564503, CPU1/512MiB; its scope is source/native reads and a private coherent Delivery proposal, with no CLR, native writes or source edits. The earlier programme-intake deferral below is historical and superseded by this explicit active-work request; its original wording and the complete audit remain preserved. This priority change does not alter the full Done when, accepted #4701/#4712/#2852 scopes or #4647 controller ownership, and supplies no implementation or adoption acceptance.

### Audit boundary and conclusion — 2026-10-21

User requested a thorough inventory, comparison with current and planned processes, and specific assessment of `padd-item` and `check-board`; then approved writing it up and adding it to the board. This is the durable audit and proposed follow-up, not implementation acceptance.

**Conclusion: source packaging is coherent, but the whole skill estate is not current.** Important current contradictions, stale consumers and a planned architecture transition require distinct treatment. Names missing from an implicit invocation catalog are not necessarily obsolete.

Canonical protected hub snapshot examined: `.github` commit `74cbd6f0b1b598d48556eb854c4ba6a3c3abda54`. Local hub checkout was `9211d3e69a6d0252fe5727aeed2e40a6f94a1143`; protected-source checks used the protected snapshot rather than treating that checkout as current. Findings below are a dated audit, not live deployment assertions.

- 29 hub skills; 154,900 bytes of SKILL.md instructions at the inspected snapshot.
- 477 manifest/file checks passed; tracked `.agents`/`.claude` mirrors matched. Ignored Python cache files were excluded from the tracked comparison.
- 81 registry rows: 21 process, 40 product, 11 driver, 9 operator. All 81 declared SHA-256 values matched the inspected local canonical owner files. This establishes that source snapshot's consistency, not current remote API compatibility or installed fleet adoption.
- Hub composition: 20 registry-listed driver/operator skills, five Kit skills and four advisory/specialist skills.
- `cut-nuget-release`, `drive-board`, `p-add`, `padd-item`, `work-programme` and `work-roadmap` intentionally disable implicit invocation. Their absence from automatic discovery alone is not a defect.

Sources: [canonical skills](https://github.com/FS-GG/.github/tree/74cbd6f0b1b598d48556eb854c4ba6a3c3abda54/.agents/skills), [registry](https://github.com/FS-GG/.github/blob/74cbd6f0b1b598d48556eb854c4ba6a3c3abda54/registry/skills.yml), [delivery channels](https://github.com/FS-GG/.github/blob/74cbd6f0b1b598d48556eb854c4ba6a3c3abda54/registry/skills.delivery-channels.yml). Atlas navigation included `platform/skill-roots`, `platform/skill-delivery-authority`, `github/work-board-parallel-opportunities`, `github/work-board-intake-triage` and `github/work-board-coord`; cited source, rather than remembered knowledge, established authority.

### Complete hub inventory and disposition

| Group | Skills | Proposed disposition |
| --- | --- | --- |
| Driver (11) | atlas; work-roadmap; continue-from-handoff; stop-with-handoff; routine-decisions; agent-handoff; work-programme; work-board; work-board-normal; work-board-best; padd-item | Retain useful entrypoints; simplify compatibility aliases and move future execution authority into the qualified controller. work-programme is already a retired redirect. |
| Operator (9) | drive-board; work-board-coord; drive-board-normal; drive-board-best; p-add; cut-nuget-release; lane-steward; board-analyst; publishing-and-deployment | Retain canonical intake, release and advisory roles. Replace obsolete cut-nuget-release instructions. Keep drive-board variants only as explicit compatibility redirects where needed. |
| Kit (5) | check-board; cross-repo-coordination; initialize-sdd-workspace; intra-repo-parallel-work; pnext-item | Retain; reconcile consumer delivery and make future controller/worker boundaries explicit. |
| Advisory/specialist (4) | show-progress; pipeline-preflight; technical-writer; spectre-console | Retain. No obsolescence established; keep reports and advice separate from dispatch or planning authority. |

### Findings and prepared proposals

**1. Consumer Kit copies lag current producer instructions.** Five shared Kit skills were compared in each of Audio, Game, Governance, Net, Rendering, SDD and Templates: all 35 local copies differed from the current hub. Remote verification also confirmed Game main `.claude/skills/check-board/SKILL.md` blob `47a82254fd495317c39431a677932dd3907410fb` and SDD main `.claude/skills/pnext-item/SKILL.md` blob `5c9ef87a986f933cb323edbc4beb529f113f5086` matched the stale inspected copies. Not every other consumer was independently checked on remote main; these comparisons do not prove which copy each runtime loads.

Old Game/Audio check-board instructions prescribe unscoped `budget`, `reconcile --json`, `lint --json`, `reconcile --apply` and `flush`, with old claim markers. Old SDD pnext-item treats board projection as nonblocking, omits the current guarded Done transition and allows a closing link more broadly than full-promise acceptance permits.

Proposal: use the maintained Kit publication/materialization/adoption route and existing runtime identity mechanism, not hand-copying files. Select concrete framework consumers, inspect the actual discovered instructions and preserve unselected exceptions. Existing #2852 records the same distribution failure class; closed #4712 explicitly qualified selected receivers, not the whole fleet. This is a newly observed remaining consumer population, not grounds to reopen their accepted scopes.

**2. cut-nuget-release contains an obsolete executable release recipe.** Its prepare/component-publish/promote route conflicts with publishing-and-deployment's explicit sealing of those historical routes under GS2-08.9. The current successor uses an immutable candidate/archive, publish=false preflight then publish=true, coherent-set tagging, ordered effects and reconciliation of unknown outcomes.

Proposal: replace the old executable recipe with a narrow entrypoint into the maintained publishing contract; preserve historical guidance only as clearly non-executable history. Qualify discovery so an operator cannot select the sealed route through the old skill name.

**3. padd-item is useful; its legacy appendix needs repair or retirement.** Current explicit product scope, deduplication and file-only intake are appropriate. Its legacy product reference still prescribes apply/flush and queue-flush recovery, while current inspection/intake guidance separates queue-wide replay from authorized individual effects. Other legacy instructions retain old board selectors and claim/status conventions.

Proposal: retain padd-item as the product intake adapter. Determine whether any genuinely supported, qualified legacy product consumer still needs the appendix. Isolate and correct that contract if so; otherwise retire it with explicit disposition. Never expose it as an organization fallback. Renaming the skill alone fixes nothing.

**4. check-board is useful; make its read-only boundary unmistakable.** Current V2 instructions already distinguish organization/product bindings, retain Unknown and avoid treating merge as acceptance. Its reconcile-oriented description/default prompt and substantial inline legacy recipe can nevertheless invite repair behavior or the wrong route. Some reference wording still describes a prepared organization rather than the current cutover boundary.

Proposal: retain check-board as inspect-and-explain. Put current inspection first, make repair a separately authorized guarded operation, and remove unsupported legacy material from the normal path. Under #4647 it becomes a controller inspection client. Judgment guidance must distinguish today's agent decisions from future deterministic policy rather than banning legitimate controller decisions.

**5. Several global skills can conflict with FS.GG delivery.** The installed managed speckit-merge recipe enumerates nontrunk branches, performs direct trunk squash/push and branch deletion, mandates version bumps/local packing, then pushes again and clears shared NuGet caches. Its broad landing triggers conflict with protected, scoped FS.GG delivery. speckit-debug-loop remains useful but its mandatory readiness log, generic retry/escalation and verification assumptions need an FS.GG boundary. The global cross-repo-coordination copy matched the current hub in this audit.

Proposal: exclude speckit-merge from FS.GG routing or provide an explicit FS.GG adapter to canonical delivery. Prepare the exact routing change before asking the managed-package owner to change it; do not silently patch a vendored global package. Keep useful debugging instructions subject to the selected repository contract.

**6. Future process alignment is a real migration, already owned by LEARN.** The accepted amendment in #4647 assigns scheduling, feasibility, resource admission, lifecycle, recovery and acceptance to deterministic F#/Akka machinery. It requires WorkspaceExecutionContract, WorkAssessment, ExecutionProfile, AgentSpecification and ordinary Assignment, with optional ExperimentEnrollment. Current board skills still have the agent root doing much of this work.

Proposal: retain honest current behavior until a qualified replacement exists. Deliver thin start/inspect/steer/stop clients and specialist worker instructions under #4647, with one framework/product contract and actual installed acceptance. Do not create another scheduler, dual authority or a card per migration step. Normal/best selection should become maintained versioned profile preferences, not duplicated independent model policies. pnext-item remains a worker execution contract, not another admission authority.

**7. Reduce redundant wrappers and historical operational state.** drive-board variants overlap work-board-coord and normal/best preferences; work-programme is already a redirect. work-roadmap is useful as selected-plan intake, not a second checkbox scheduler. Generic resume/recovery instructions include incident-specific counts, selected cohort references and broad historical scope. Delivery-channel prose contains dated counts inconsistent with current rows. Fixed model choices and “newest available” guidance also merit one policy owner.

Proposal: keep compatibility names only as clear redirects where callers need them; move incident facts to their durable owner records and retrieve them during recovery. Preserve every original uncertain operation and obligation while removing copied operational state from generic instructions. Refresh descriptive counts from maintained data. Keep optional analysts/stewards advisory. Retain technical critics where acceptance requires them, without imposing a universal fixed phase chain on ordinary work.

### Other registry and installed specialist inventory

All 81 registry entries are accounted for by the 20 hub driver/operator skills above and these owner groups:

- SDD (21, prefix `fs-gg-sdd-`): analyze, authoring-contracts, charter, checklist, clarify, evidence, getting-started, lifecycle, plan, refresh-agents, ship, specify, tasks, troubleshooting, typed-author, typed-correspond, typed-inspect, typed-migrate, typed-reconcile, validate, verify.
- Rendering (20, prefix `fs-gg-`): scene, symbology, elmish, skiaviewer, layout, keyboard-input, styling, ui-widgets, game-shell, collision, grids, line-drawing, visibility, symbol-design, testing, samples, feedback-report, project, svg-assets, svg-performance.
- Game (13, prefix `fs-gg-`): game-core, audio, persistence, model-swap, ballistics, ai, effects, physics, playtest, mapcraft, game-fable, replay, rules.
- Audio (1): fs-gg-browser-audio.
- Templates (6, prefix `fs-gg-`): fable-bindings, interop, project, http-codecs, signalr, testing.

Retain these domain skills; no blanket obsolescence was established. Registry hash verification does not substitute for a per-skill API/toolchain audit. Feedback-report's explicit selected review surface must not silently become a mandatory general delivery chain.

The ten installed fsdocs/fsgrpc specialist skills remain useful: fsdocs-api-doc/build/examples/setup/technical and fsgrpc-client/codefirst/proto/server/setup. Their external API currency was not independently qualified. Three advertised Quint skill paths were absent from the declared local root, and the inspected plugin cache search did not resolve them: availability is unverified, not evidence that formal modeling is obsolete. System imagegen/openai-docs/skill-creator/skill-installer and Pages/Sites/plugin-management/Work Pets skills are external capability surfaces; this process audit does not certify their vendor internals or recommend retiring them merely because FS.GG does not currently need them.

### Delivery proposal, deduplication and limits

Prioritize (1) concrete current contradictions and selected consumer adoption, (2) wrapper/description/recovery cleanup, and (3) #4647's coherent installed controller-client migration. Prefer the correction that directly unblocks PROC, LEARN or UTEL; no additional workspace/provider variants are requested by this audit.

Bounded deduplication covered open hub issues matching skill/skills, current open PRs, recent relevant closed skill issues, and full owning scope in #4730, #2965, #4647, #4712 and #2852. No open hub PR was returned at filing preparation. #4730 owns coordination efficiency and its remaining release/resource/economic acceptance, not this complete skill currency census. #2965 owns fleet cutover/v1 retirement, not a new parallel cutover. #4647 already owns the future controller migration. Closed #4701/#4712 remain accepted for their declared selected process/receiver scope. Reuse those mechanisms and owners; do not claim global absence of related history or undo accepted outcomes.

No source, global skill, release, runtime, protected binding or main-thread worktree was changed by this audit. Repository roadmap/Atlas incorporation belongs to the eventual normal source delivery; until then this native issue is the durable audit pointer and Programme/root retains that capture follow-through.


### Programme intake disposition — 2026-10-21

Programme/root reviewed the complete audit and native authorship. This remains a broader skill-currency and framework-consumer adoption follow-up; implementation is deferred under the current PROC/LEARN/UTEL priority. UTEL already uses the selected canonical release route, the PROC original-custody gap is unaffected, and LEARN controller-client conversion remains owned by #4647. Revisit this follow-up when an exact currently blocked selected-product invocation and receiver are identified, or when the user changes priority. The full acceptance, source/distribution/adoption owners and unselected-consumer exceptions above remain intact; visible membership alone supplies no typed planning, protected enrollment or implementation authority.

Historical current fields before the user-prioritized planning assignment, retained verbatim:

## Current deliverable

None

## Next action

Programme/root reviews this audit and selects the nearest correction that directly unblocks PROC, LEARN or UTEL, keeping unrelated workspace/provider variants deferred. Prepare the canonical skill-owner change and the concrete publication/receiver proposal before any operator decision. Resolve native classification and protected enrollment through the existing qualified routes before board-selected execution. Keep #4647 as sole owner of the controller-client migration; reuse an existing supplier Delivery where its promise covers a correction. Do not create a card for each finding.

## Blocked on

No blocker to reviewing or preparing the corrections. Implementation has not been dispatched. Exact receiver rollout scope and global managed-skill routing disposition require the accountable owner's selection. The future thin-client conversion depends on the actual qualified controller delivered under #4647, not merely its accepted design. Project membership is requested by the user; typed planning and protected enrollment are separate and must be independently established.

Historical current and next fields before child4789 intake, retained verbatim:

## Current deliverable

Programme/root has activated this user-requested skill-currency and selected framework-consumer adoption work alongside PROC, LEARN and UTEL. The existing planning owner /root/knowledge_fable_receiver is actively preparing one coherent canonical-correction and selected-consumer adoption proposal under the admitted600-second read-only/source-planning window (CPU1/512MiB). SDD is the selected supported framework Kit consumer; Coordination remains outside Kit participation under ADR0078. No source implementation, publication or runtime adoption is claimed.

## Next action

The same planning owner completes bounded semantic deduplication and reuses an existing Delivery where its full promise covers the result; otherwise propose only the next independently meaningful Delivery combining coherent canonical correction with selected framework-consumer adoption. Identify exact canonical owners, consumer and touchset, maintained publication/materialization route, actual runtime discovery/identity evidence and deliberate mismatch refusal acceptance, retaining unselected consumers as explicit exceptions or owned follow-through. Programme/root then selects that concrete scope and completes qualified planning and protected enrollment before board-selected implementation. Keep #4647 as the sole future deterministic-controller migration owner; do not create a duplicate Outcome, a card per audit finding or global vendored-package patches. Global managed-skill routing changes require a concrete owner-supported proposal.