dsh-plugin-implement

Implements standalone DSH Cordis plugins with validated configuration and lifecycle-safe registrations.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Implementing a DeepSeek Harness (DSH) plugin requires following many subtle Cordis conventions—inject declarations, fiber-owned effects, Schemastery config validation, invariant companions, and bundle patch metadata—and missing any of them produces plugins that silently fail to load, leak registrations on unload, or break the host's tool scheduler. ## Core Features & Use Cases - Plugin Form Enforcement: Preserves the correct function-plugin namespace export or service-plugin default export, preventing the stray default export that makes the Cordis Loader drop inject, Config, and apply. - Lifecycle-Safe Registrations: Ensures every registry contribution is an effect owned by the plugin fiber so unloading cleanly removes tools, listeners, and services. - Config & Invariant Discipline: Guides Schemastery-validated configuration, credential handling, and the src/invariant.ts companion with positive and negative test paths. - Use Case: After planning and scaffolding a new DSH plugin (such as a background type-checker), use this Skill to implement the approved handoff—writing src/index.ts, src/config.ts, src/runtime.ts, tests, README, and cordis.patch.yml—so the plugin loads correctly in a DSH profile. ## Quick Start Use the dsh-plugin-implement skill to implement the planned standalone DSH plugin including its invariant, documentation, and focused tests.

Frequently Asked Questions about dsh-plugin-implement

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

FAQPage Schema
How do I implement a DSH plugin with Cordis?▼

Keep one ESM namespace entry exporting name, inject, Config, and apply for function plugins, or default-export a Service subclass for service plugins. Place configuration in src/config.ts, host boundaries in src/runtime.ts, and register every contribution through ctx.effect so unloading disposes it.

Why does my Cordis plugin lose its inject and Config exports?▼

The Cordis Loader unwraps exports.default ?? exports, so adding a stray default export to a function plugin drops inject, Config, and apply from the loaded namespace. Keep function plugins as pure named-export namespaces without any default export.

How do I handle optional services in a Cordis plugin?▼

Read optional services through ctx.get(name) instead of listing them in inject. When behavior must attach and detach as the service appears or disappears, use scoped ctx.inject so the effect lifecycle tracks the service availability.

What is the invariant.ts file in a DSH plugin?▼

src/invariant.ts is a function-plugin companion exported as ./invariant that checks an authoritative event or data relationship owned by the package. It must not assert service presence or plugin metadata, and needs positive and deliberately invalid negative test paths.

Why is my cordis.patch.yml config override not applied?▼

Overrides must be flat loader entries with - id: and config: keys, not nested - update: syntax, which the loader silently skips. An id-targeted patch replaces the entire config object, so restate every field you want to keep.