本文へ移動
cccskills
無料GitHub で公開

mise

Use Pulp's locked mise toolchain consistently across macOS, Linux, and Windows. Apply this when building Pulp, creating a disposable Windows VM, investigating toolchain drift, or changing the canonical toolchain manifest. Keep mise opt-in at shell entry, fail closed on lock drift, and distinguish pinned toolchain evidence from a build made with host-installed tools.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md5.9 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Pulp mise toolchain

Use this skill whenever a task depends on build-tool versions. The canonical input is tools/toolchain/manifest.toml; .mise.toolchain.toml and mise.toolchain.lock are generated outputs. Never hand-edit generated files.

Reproducible build path

From the repository root, verify the checkout and install only the locked tools:

mise --version
mise trust
MISE_ENV=toolchain mise install --locked
MISE_ENV=toolchain mise exec -- python3 tools/toolchain/check_env.py
MISE_ENV=toolchain mise exec -- pulp build

Use MISE_ENV=toolchain mise exec -- <command> for one-off commands so the versioned PATH is explicit in logs. On Windows, use the same commands from PowerShell (replace python3 with python only when the pinned interpreter's launcher requires it). Do not use mise install without --locked for a Pulp receipt.

A pinned-toolchain claim requires all of the following:

  • the mise version named by [mise].version in the manifest;
  • a successful mise install --locked on the guest's platform;
  • tools/toolchain/check_env.py with no unexpected drift; and
  • the manifest source and lock checksums recorded with the build receipt.

If any item is absent, label the result host-toolchain evidence. Do not infer pinned versions from a generated config that was not actually used.

Checking a host or VM rollout step

A fleet host, an ssh session or a launchd job has neither the pinned mise's directory nor the rustup proxies (~/.cargo/bin) on its PATH, so a plain check_env.py there reports an installed Rust as missing. Rollout steps run the one command that judges them:

MISE_ENV=toolchain mise exec -- python3 tools/toolchain/check_env.py --fleet-path --require-tools

--fleet-path also searches those directories; --require-tools exits 1 on any host-tool difference whatever the manifest's mode, while only reporting the npm trees each checkout installs for itself (pulp deps resolve). tools/toolchain/fleet_report.py runs the check over ssh on several hosts and prints one drift table; it installs nothing.

Read the versions a build actually used from its CMakeCache and configure log (CMAKE_COMMAND, CMAKE_MAKE_PROGRAM, Found Python3), not from the profile. On macOS, CMake's FindPython prefers a Python.framework install over PATH; the configure of a Pulp checkout sets Python3_FIND_FRAMEWORK=LAST when MISE_ENV=toolchain is set so the pinned interpreter wins. A build directory configured before opting in keeps its cached interpreter: configure a fresh one.

The pinned-toolchain golden (CI images)

.shipyard/vm-image.mise.toml bakes a candidate image, pulp-build-runner-mise-candidate, on top of the runner golden with tools/ci/mise-golden-layer.sh (run by tart-provision.sh manifest). Its [mise] table is generated from the manifest; regenerate it with generate.py, never by hand. The layer refuses a host or guest mise binary whose sha256 or --version differs from the pin, and toolchain files that differ from the checkout's commit, so bake from a clean main. It installs with mise install --locked, turns rustup self-update off and installs the manifest's Rust by name, then writes a receipt the guest itself reports (on the host: ~/.cache/pulp-ci/golden-receipts/<vm>-mise.json). The candidate changes no lane: promoting it to :latest or routing a lane to it is a separate, reviewed step.

Platform exceptions in the lock

Some tools are not locked on every platform, by declaration in the manifest's unlocked table: Tart is macOS-only, and conda-forge publishes no windows-arm64 clang-format, so windows-arm64 keeps its own clang-format. The drift test refuses any other missing platform row; never "fix" an exception by hand-editing the lock.

Scope and boundaries

  • Keep MISE_ENV=toolchain opt-in at shell entry. It prevents a checkout from rewriting a developer's PATH or installing tools unexpectedly.
  • Use the locked profile for Pulp builds, cross-platform VM probes, release investigations, and toolchain changes. CI and setup.sh may still run on hosts without mise while their reviewed provisioning migration is incomplete.
  • Never put credentials, VM disk paths, mutable cache directories, or secrets in .mise.toml. Put those in the VM recipe or host configuration.
  • Do not use mise to install or redistribute Skia, Dawn, V8, SDKs, or proprietary vendor tools. Those have their own checksum and licensing paths.
  • Build through pulp build/pulp dev or the governed CI wrapper; mise controls tool versions, not build parallelism or runner admission.

Updating pins

To change a tool, edit the manifest on a branch and regenerate with the exact mise binary named by the manifest:

python3 tools/toolchain/update.py cmake --to 4.3.4 --mise /path/to/mise
python3 tools/toolchain/generate.py --check

Run the toolchain self-tests and dependency audit before publishing. A pin change must update the manifest, generated mise files, lock checksum, and DEPENDENCIES.md/licensing documentation when the dependency inventory changes. Do not claim a pin change is complete until the generated-file check is clean.

Windows VM recipe

For an ephemeral ARM64 or x64 Windows guest, copy only the locked config and use a guest-local mise cache. Keep the guest isolated from the persistent interactive VM, and destroy the overlay after the receipt is copied out. A successful configure or SDK build is useful evidence, but it is not plugin GUI or DAW proof; retain that distinction in the status report.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

aax

無料

Optional AAX support for Pulp, including developer-supplied Avid SDK setup, CMake enablement, DigiShell/AAX Validator workflows, and local AAX builds on macOS or Windows.

日本語の概要は準備中です。原文の説明を表示しています。

Generous-Corp/pulp222026年10月17日 更新

Configure, implement, and test Pulp's optional desktop Ableton Link tempo-sync adapter while preserving the developer-supplied SDK, licensing, realtime, latency-compensation, and no-install boundaries.

日本語の概要は準備中です。原文の説明を表示しています。

Generous-Corp/pulp222026年10月17日 更新

Maintain Pulp's installed design-time agent capability manifest and public-surface ledger. Use when adding, removing, renaming, or materially changing public audio, MIDI, signal, timebase, or sequence APIs; registering a new algorithm for generators; changing capability support or deprecation state; or repairing agent-capabilities freshness, schema, fingerprint, tombstone, or installed-SDK tests.

日本語の概要は準備中です。原文の説明を表示しています。

Generous-Corp/pulp222026年10月17日 更新

android

無料

Android platform development for Pulp — NDK cross-compilation, Oboe audio, Dawn/Skia GPU rendering, JNI bridge, touch interaction, emulator workflows, and end-to-end smoke validation. Covers build, deploy, debug, and the gotchas discovered during bringup.

日本語の概要は準備中です。原文の説明を表示しています。

Generous-Corp/pulp222026年10月17日 更新

ara

無料

Optional ARA support for Pulp, including developer-supplied ARA SDK setup, CMake enablement, adapter companion APIs, validation, and ARA-aware plugin implementation guidance.

日本語の概要は準備中です。原文の説明を表示しています。

Generous-Corp/pulp222026年10月17日 更新

The measurement surface for ALL Pulp DSP and audio-pipeline work — read it BEFORE writing or gating DSP, not only when something already sounds wrong. Covers the C++ harness (signal generators, metrics, assertions, RenderScenario, contracts), the offline Audio Doctor (magnitude/frequency response, THD/THD+N, phase/group delay), and their Python sibling the Audio Quality Lab (tools/audio/quality-lab — null residual + alignment, LTAS log-spectral distance, spectral flux/centroid, HNR, Theil-Sen drift slope, Kaiser-sinc resampling, license-guarded corpus, regression-net ratchet). TRIGGER on AUTHORING work — "build/design an oscillator/filter/synth/effect", "add a DSP module", "what should the acceptance gate be", "how do I measure aliasing / anti-aliasing / alias floor", "null against a reference", "is this DSP correct", "choose a tolerance", "golden/regression corpus for audio", "measure drift or jitter", "A/B two renders" — AND on DEBUGGING work — "is there sound / no audio / I hear nothing", "does this filter/compressor/synth/delay produce the right signal", "prove the DSP / prove the contract", "measure the frequency response", "what's the THD / is it distorting", "what's the group delay / phase response / measured latency", "magnitude response curve", "render a test tone and assert", "audio regression", "64-frame works but 128 is silent", "sample-rate change pitch-shifted it", "describe what's in this buffer", "audio doctor", "compare before/after a DSP refactor". Reach for this BEFORE hand-rolling any FFT, null test, alias measurement, pitch tracker, or golden-render script — most of it already exists in one of the two lanes. Test/tool layer over HeadlessHost — deterministic, no audio device, no speakers. Off the realtime thread entirely.

日本語の概要は準備中です。原文の説明を表示しています。

Generous-Corp/pulp222026年10月17日 更新

Generous-Corp のスキルをすべて見る

このスキルの問題を報告する