メニュー
Cut a decimal-scaled release. Points to RELEASING.md (the system of record) for the full process — versioning policy, release branch, PR-into-main + approval, mandatory docs + benchmark refresh, and publish steps. Use when preparing or performing any release.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Use to verify the decimal_scaled repo still matches its architecture as defined — a read-only audit against the CLAUDE.md ARCHITECTURE CONSTITUTION (rules 1–6) and docs/ARCHITECTURE.md. Run it periodically, after any structural/perf change, or before a release. Covers the defect taxonomy (const-work-width / build-max leaks / per-tier pollution / layering / dead code / policy hygiene), the read-only protocol, what is legitimately NOT a violation, and a copy-paste launch skeleton for the auditor agent.
Use when the coordinator runs a PARALLEL multi-agent performance-recovery campaign on decimal-scaled — recovering many benched (bench-branch-compare) regressions at once by partitioning the work across worktree agents, one per policy/function area, with CPU-core-pinned concurrent microbenching. Covers the disjoint partition, int-tier-first holistic ordering, the core-pin scheme to keep concurrent benches under load, the per-agent loadout, and the coordinator's review→gate→merge→push→bbc→refresh-table loop. Builds on subagent-dispatch (per-agent rules), algorithim-optimiser (kernels), architectural-review (compliance), hunters (research lenses).
Use when writing or maintaining a DecimalSubject adapter or any golden-harness integration — adding a subject for a new decimal library to golden-competitors, fixing an existing adapter's limits/rounding/overflow declarations, or wiring a library against the decimal-scaled-golden golden set. Covers the typed-vs-erased choice, the Capabilities/FnSupport contract, value-aware limits, round-trip rules, panic capture, the gotchas hit building the seven competitor adapters, and how to validate a new subject.
Use when launching, re-dispatching, or handing over the decimal_scaled background "hunter" agents — the adversarial golden-input hunters (theoretical / competitor / internal lenses), the perf-opportunity hunter, the perf-research hunter, and algorithm candidate-writers. Covers the dispatch protocol, the hard rules (no cargo/bench by agents, cleanroom licensing, no background daemons), the come-back-resend loop, the manifests, the bench seams, and copy-paste launch-prompt skeletons.
Take a COMPLETED, verified policy-map (the table produced by `policy-mapper`) and wire it into ONE function's `policy::<fn>::select` — faithfully reproducing the map, validity-walled, at true crossovers — then prove the wired policy reproduces the map and golden-gate it. The apply half of the measure/apply split; `policy-mapper` measures, `policy-applier` wires.
Empirically MAP ONE function's algorithm policy by N-way-benchmarking every candidate algorithm × LimbSize across the full width/scale surface (+ edge input values) — producing the verified win-region map. DECIMAL sweeps the 5-point scale grid per width and bisects where winners change; INT brute-forces every width. Measure-only: the map is the deliverable; `policy-applier` wires it. One agent per policy; the coordinator verifies the map is complete.
SOC 職業分類に基づく
| name | release |
| description | Cut a decimal-scaled release. Points to RELEASING.md (the system of record) for the full process — versioning policy, release branch, PR-into-main + approval, mandatory docs + benchmark refresh, and publish steps. Use when preparing or performing any release. |
The canonical release process is RELEASING.md at the repo root —
the system of record. Read it and follow it end-to-end when preparing
or performing any release.
Keep in sync: this skill and RELEASING.md must stay aligned — if
you change one, change the other. RELEASING.md is canonical; keep this
file a thin pointer so they cannot drift.
Three things load-bearing enough to repeat here:
cargo publish, git push, tag pushes,
and publishing a GitHub release each need an explicit, separate go.
"Prepare the release" / "bump the version" do not authorise
publishing.python scripts/render_docs.py and commit on the release branch as
part of the PR; the docs-drift gate fails the PR on any drift.main (never push to main directly).
Open the PR with the release checklist template:
gh pr create --base main --head release/<version> --body-file .github/PULL_REQUEST_TEMPLATE/release.md
(web UI: append ?template=release.md to the compare URL), then tick
the checklist.Everything else — the versioning policy, the full release flow, and the
automatic-vs-manual pre-release checklist — is in RELEASING.md.