DeepSeek Harness plugin development

Use this skill to implement real DeepSeek Harness plugins, not generic Node plugins. DeepSeek Harness is composed from Cordis plugins mounted into shared contexts; tools, model adapters, services, storage, policy, and agent behavior are extension points in that plugin tree.

Cordis mental model

Reason in these concepts before designing a non-trivial plugin:

• Plugin — a lifecycle-owned unit mounted by Cordis. Usually a function with apply(ctx); a Service subclass is also a plugin.
• Context (ctx) — the scoped repository of services and the entry point for Cordis registrations, events, effects, and child plugins.
• Service — a named capability exposed as ctx.<key>. Consumers depend on the capability name, not a concrete provider import.
• inject — declarative required service dependencies. It controls readiness and reloading; YAML row order is not dependency management.
• Fiber/lifecycle — every mounted plugin instance owns a Fiber that can be pending, load, become active, unload, and dispose.
• Effect — lifecycle-owned registration/resource. Cordis APIs already create effects; unmanaged resources belong in ctx.effect() with a disposer.
• Event — decoupled runtime communication. Use a service for direct capability calls; use events for announcements, observers, policy/interception, or pipelines.
• Composition — cordis.yml and patches describe a plugin tree; ctx.plugin() creates a child Fiber with independent lifecycle under its parent.

TypeScript declaration merging only adds compile-time knowledge of a service or event. It does not register anything at runtime.