dsh-plugin-test

Selects and runs minimal behavioral evidence tests for standalone DSH plugins.

21|4|Updated Aug 13, 2026
One-click install
npx skills add https://github.com/0xsline/dsh-spotlight --skill dsh-plugin-test-0xsline
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dsh-plugin-test
Source: https://github.com/0xsline/dsh-spotlight/tree/main/.agents/skills/dsh-plugin-test
Command: npx skills add https://github.com/0xsline/dsh-spotlight --skill dsh-plugin-test-0xsline

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Standalone DSH plugins need proof that their Loader exports, configuration, lifecycle disposal, composition, visible output, and built artifacts actually work, but running every repository test wastes effort while missing the narrowest test that would catch a regression. ## Core Features & Use Cases - Evidence Mapping: Builds a behavior-to-test mapping covering Loader unwrap paths, config defaults and rejections, registration disposal, invariant companions, composition, snapshots, and artifact imports. - Composition Testing: Requires a real Cordis composition booted through the actual Loader and application path, mocking only external services, credentials, time, and randomness. - Artifact Verification: Runs verify:self-contained, typecheck, test, build, and prepare, then imports each public runtime entry from lib/ under plain Node. - Use Case: After adding a new slash command to a DSH Web plugin, use this Skill to select the exact test files proving Loader export, disposal, and browser-visible behavior before claiming the package is tested. ## Quick Start Use the dsh-plugin-test skill to select and run the smallest complete evidence for this standalone DSH plugin.

Frequently Asked Questions about dsh-plugin-test

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test a standalone DSH plugin?▼

Test a DSH plugin by mapping each promised behavior to the narrowest test that observes it: Loader unwrap exports, config defaults and rejections, registration disposal via ctx.plugin fibers, a real Cordis composition boot, visible snapshots, and built artifact imports from lib/.

How to verify Cordis plugin Loader exports?▼

Verify Loader exports by calling Loader.prototype.unwrapExports on the plugin and asserting the unwrapped object is identical, exposes name, inject, Config, and an apply function. Service plugins instead verify the default-exported service class unwraps with its intended metadata.

Does a DSH plugin need a composition test?▼

Yes, a product-visible plugin requires a non-unit test booting a test Cordis composition through the real Loader and application path. Mock only external services, credentials, time, or randomness; hand-built ctx.plugin sequences do not substitute for this test.

Why is fiber.dispose() resolving not enough to prove cleanup?▼

Disposal resolution only signals the fiber ended, not that contributions were removed. Observe each contribution while the fiber is live, dispose it, then confirm removal through the registry or service API, including cancellation of pending async operations.

What commands verify DSH plugin build artifacts?▼

Run pnpm run verify:self-contained, typecheck, test, build, and prepare. After building, import each public runtime entry from lib/ under plain Node to confirm ESM exports, and use pnpm pack --dry-run --json only during release stages.