Menu
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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| 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.