openskills-plugin-separation
npx machina-cli add skill Geeksfino/openskills/openskills-plugin-separation --openclawOpenSkills Plugin Separation
Use this skill when changing plugin features, build-tool wiring, or runtime dependency topology.
Objective
Keep core runtime usable without plugin toolchains, especially for bindings and non-build execution paths.
Key Files
runtime/Cargo.tomlruntime/src/lib.rsruntime/src/bin/openskills-runtime.rsruntime/src/build/**bindings/ts/Cargo.tomlbindings/python/Cargo.toml
Separation Rules
- Build plugins must be gated behind explicit features.
- Core runtime defaults should not force plugin toolchains.
- Bindings should opt out of plugin-heavy default features when appropriate.
- Public exports for build functions must be feature-gated.
- CLI build commands must degrade gracefully when build features are disabled.
Validation Checklist
cargo check -p openskills-runtimepasses with default features.- Bindings compile without pulling plugin-specific dependencies unintentionally.
- Runtime tests that do not require plugin build paths continue to pass.
Output Format
- Feature graph summary
- Leakage findings (if any)
- Minimal patch plan
- Post-change verification commands
Source
git clone https://github.com/Geeksfino/openskills/blob/main/.cursor/skills/openskills-plugin-separation/SKILL.mdView on GitHub Overview
This skill enforces a clean separation between the core OpenSkills runtime and optional WASM build plugins. By gating plugin features behind explicit flags and avoiding plugin toolchains in default builds, it protects runtime consumers and language bindings from breakage. It also ensures public exports and CLI paths degrade gracefully when plugin features are disabled.
How This Skill Works
Separation is implemented by gating plugin-related code, builds, and exports behind explicit cargo features. Core runtime defaults avoid requiring plugin toolchains, while bindings opt out of plugin-heavy features when appropriate. Build commands and CLI paths are designed to degrade gracefully if plugin features are turned off, with validation checks ensuring the runtime remains usable without plugin paths.
When to Use It
- When changing plugin features, build-tool wiring, or runtime dependency topology
- When updating core runtime or bindings to prevent pulling in plugin-specific dependencies unintentionally
- When adding or modifying WASM plugins so the runtime remains usable without those plugins
- When evolving public build exports to be feature-gated
- When ensuring CLI build commands degrade gracefully with plugins disabled
Quick Start
- Step 1: Introduce explicit feature flags for plugins in runtime and bindings Cargo.toml
- Step 2: Gate runtime APIs and CLI entry points with cfg(feature = \"plugin\") and ensure non-plugin paths compile
- Step 3: Run cargo check -p openskills-runtime with default features and verify bindings compile without plugin deps
Best Practices
- Gate all plugin code behind explicit Cargo features and document the feature flags clearly
- Ensure core runtime defaults do not force plugin toolchains or plugin-related dependencies
- Review bindings to opt out of plugin-heavy default features where appropriate
- Feature-gate public exports for build functions and runtime entry points
- Validate with cargo check and tests that do not require plugin build paths
Example Use Cases
- A PR adds a new WASM plugin behind a Cargo feature flag, keeping default runtime builds unaffected
- Bindings (TypeScript/Python) compile without pulling in plugin-specific dependencies
- cargo check -p openskills-runtime passes with default features and without plugin toolchains
- Public build-export APIs are only available when the plugin feature is enabled
- CLI commands degrade gracefully when the plugin feature is disabled
