メニュー
Validate, install, update, list, rescan, remove, and reveal data-only Pulp content packs for installed plugins. Use for presets, themes, samples, sample banks, wavetables, and other end-user data that must be reviewed before install or update.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | content |
| description | Validate, install, update, list, rescan, remove, and reveal data-only Pulp content packs for installed plugins. Use for presets, themes, samples, sample banks, wavetables, and other end-user data that must be reviewed before install or update. |
| requires | {"scripts":["tools/kits/pulp-package.schema.json","tools/kits/pulp-plugin-runtime.schema.json"]} |
Use this skill when a user has a .pulpcontent archive or local content-pack directory for an installed plugin.
Content packs are valuable because:
ContentRegistry or PresetManager content capabilities.pulp add <name> is for curated developer dependency packages.
pulp kit ... is for developer artifacts that may transform a project.
pulp content ... is for end-user data installed into a plugin-specific content directory.
Trust rules:
.pulpcontent archives must include files.sha256.json, and every payload file must be listed and hash-matched before preview/install/update;plugin_id plus manifest_sha256;Removed content pack <id> for <plugin> (removed <path>) — for parity with tool uninstall.Built plugins should embed pulp.plugin-runtime.json via pulp_add_plugin(... CONTENT_CAPABILITIES ... CONTENT_KINDS ...). Agents and in-app installers should preview with that manifest before approval, then install with approved=true. Validate built bundles with ValidationHarness::validate_plugin_runtime_manifest(...).
For generic bundled-audio banks, use capability content.sample-banks.v1,
kind sample-banks, and exports.sampleBanks. Bank manifests use
pulp.sample-bank.v1; their audio paths are relative to the content-pack root
and their lowercase SHA-256 hashes are verified before decode. Preserve future
edit, analysis, and playback metadata under namespaced extensions keys.
Sampler Heritage profile JSON is not a content pack: validate, canonicalize,
inspect, and render it with pulp audio heritage .... Use pulp content only
when a profile and its assets are deliberately packaged as data for an
installed plugin; the Heritage CLI itself neither installs files nor targets a
plugin content root.
./build/pulp content validate <path> --json
./build/pulp content preview <path> --plugin-runtime <manifest> --json
./build/pulp content install <path> --plugin <plugin-id> --yes
./build/pulp content update <path> --plugin <plugin-id> --yes
./build/pulp content list --plugin <plugin-id> --json
./build/pulp content rescan --json
./build/pulp content reveal <package-id> --plugin <plugin-id> --version <version>
./build/pulp content remove <package-id> --plugin <plugin-id> --version <version> --yes
Use --root <dir> only for tests, CI, or explicit sandboxing. Normal installs use the platform user-data root.
reveal or the install plan text.--yes.rescan when the index is missing/stale or after manual repair.--yes.Use MCP tools when available:
pulp_content_validatepulp_content_previewpulp_content_installpulp_content_updatepulp_content_listpulp_content_rescanpulp_content_removepulp_content_revealpackages, kits, content, and installable-tools are Pulp's four ways to
extend a project or machine, and they share one lifecycle contract: add is
validated, remove is confirmed + confined to the surface's own area + names what
it deleted, and both add and remove ship tests. Pick the right surface and read
the shared contract in
extending-pulp.md.
packages — third-party audio DSP libraries → a projectkits — reusable Pulp code/UI/templates → a projectcontent — data-only packs (presets/samples) → an installed plugininstallable-tools — machine-level dev/agent tooling under ~/.pulp/tools/, plus the shared validate-and-uninstall-from-outside-a-checkout barBuild, edit, validate, explain, render, import, or integrate Pulp timeline projects through the CLI, MCP tools, or C++ SDK. Use for sequencers, arrangements, clips or notes, tempo and meter maps, automation, takes and comps, freeze, capture-to-timeline workflows, durable journals, project persistence, DAWproject import, Standard MIDI File import and export, and agent-driven timeline operations.
Pulp in the browser — the WAM v2 and WebCLAP adapters, the wasm runtime, the Skia/WebGL2 browser window host, and the WebGPU (emdawnwebgpu) GPU-audio lane. Covers what does and does not compile to wasm, the worklet-thread constraints (no std::thread, no fetch, no navigator.gpu), the non-realtime tick, memory growth, how to PROVE a GPU lane actually ran rather than silently falling back to CPU, and the silent-failure traps that make a wasm build "work" while producing no audio or no pixels.
Local and cloud CI for Pulp — validate branches, create PRs, merge on green. Handles "push to main", "ship this", "run CI", "check PR", and "list PRs".
Stand up a fast, cached, isolated, disposable macOS CI lane on Tart — layered golden VM images, ephemeral per-job GitHub Actions runners, host-mounted caches, and a reusable per-repo vm-image manifest. Use when setting up VM-based CI for Pulp or generalizing it to another repo, building/refreshing golden images, wiring ephemeral runners, or debugging the VM lane.
Pulp timeline transport, immutable compiled playback programs, bounded arrangement audio rendering, block-level publication latches, stable shells, and ProcessContext projection.
Load, run, and test VST3 / AU / CLAP / LV2 plugins from Pulp code. Use when working on `core/host/` (scanner, plugin_slot, signal_graph), when adding a new format backend, when wiring a plugin into a SignalGraph, or when writing an integration test that needs a real plug-in binary.