dsh-plugin-test

Selects and runs minimal evidence tests for standalone DSH plugin Loader exports, lifecycle, and artifacts.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Testing a standalone DSH plugin requires proving many distinct behaviors—Loader export unwrapping, configuration validation, registration disposal, composition, snapshots, and built artifacts—and it is easy to either miss critical evidence or waste effort on redundant tests. This Skill maps each promised behavior to the narrowest test that would fail for the regression. ## Core Features & Use Cases - Evidence Mapping: Builds a behavior-to-test mapping covering Loader exports, config defaults and rejections, lifecycle disposal, invariants, composition, visible output, and distribution paths. - Real Composition Testing: Requires a non-unit test that boots a real Cordis composition through the actual Loader, catching wrong package names, missing peers, and boot-order defects. - Artifact Verification: Runs verify, typecheck, test, build, and prepare commands, then imports built entries from lib/ under plain Node to confirm ESM exports. - Use Case: After adding a new configuration option to a DSH plugin, use this Skill to identify exactly which test files and assertions prove the default, explicit values, and rejection paths without running the entire suite blindly. ## Quick Start Use the dsh-plugin-test skill to select and run the smallest complete set of tests proving this plugin's Loader exports, disposal, and composition behavior.

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 proves it: Loader export unwrapping, configuration defaults and rejections, registration disposal, composition, and built artifacts. Tests live under tests/ and must run from the plugin repository alone.

How to verify Cordis plugin registration disposal?▼

Mount the real required services, then the plugin through ctx.plugin(), observe every contribution while the fiber is live, dispose that fiber, and confirm removal through the registry or service API. Do not infer cleanup from fiber.dispose() resolving.

Does a DSH plugin need a composition test?▼

Yes, a product-visible plugin requires a non-unit test that boots a test Cordis composition through the real Loader and application path. Hand-built ctx.plugin() sequences are useful unit coverage but cannot substitute for this test.

What commands verify DSH plugin build artifacts?▼

Run pnpm run verify:self-contained, typecheck, test, build, and prepare, then import each public runtime entry from lib/ under plain Node to verify ESM exports. Run prepare separately when Git or tarball installation is supported.

When should plugin tests use snapshots?▼

Use snapshots for stable user- or model-visible text, placing keyless fixtures under tests/snapshots/ owned by the actual example or runner. Keep fixtures portable across Linux and macOS and fix nondeterminism rather than normalizing away meaningful differences.