Preface¶

The core philosophy of DeepSeek Harness (hereafter referred to as DSH) is “everything is a plugin”. The official repository deepseek-ai/deepseek-harness packages runtime, tooling, and interface capabilities into composable Cordis plugins; a large number of installable bundles have also emerged in the community. When writing your first plugin, the problem is usually not “whether you can write TypeScript”, but distinguishing three forms: in-process dynamic plugins, workspace packages in the repository, and external bundles loaded into a profile via dsh plugin. The three forms differ in source code format, loading paths, and verification evidence. Applying one set of rules to another can easily lead to packages that compile but cannot be installed or uninstalled properly.

dsh-plugin-development was created for exactly this scenario. It is not another interface plugin for modifying web UI skins, but a portable Agent Skill: it documents the process of designing, implementing, packaging, reviewing, and diagnosing DSH plugins in SKILL.md, allowing Codex, Claude Code, and DSH to share the same specification. The repository also provides an optional DSH bundle adapter to facilitate profile-level installation and uninstallation via dsh plugin. This article is organized after cross-checking against the community catalog page, GitHub README, package.json, SKILL.md, and the v0.2.0-beta.1 release notes.

What is This¶

dsh-plugin-development is maintained by GitHub user w2112515, under the MIT license. The community catalog deepseek-harness-plugin.com categorizes it under “Interface Enhancements”, with the listed installation command being dsh plugin add github:w2112515/dsh-plugin-development. The GitHub repository was created on 2026-08-14, and as of 2026-08-17, it has 10 stars. The current package version is 0.2.0-beta.1 (prerelease).

The repository README clearly defines the product boundary: what is actually maintained is a canonical Skill directory skills/dsh-plugin-development compliant with the Agent Skills Specification; index.js and cordis.patch.yml are just thin adaptation layers that register this Skill into DSH’s ctx.skills. It does not introduce MCP services, nor does it depend on accounts, keys, or remote interfaces. The project declares itself as a Beta, unofficial community project, and has no affiliation or endorsement relationship with DeepSeek; DSH is currently in developer preview, and the plugin manifest, types, and Loader behavior are subject to the current DSH repository, not the memory of this Skill.

It addresses tasks such as:
- Developing dynamic Cordis plugins in a live DSH process via cordis_define / cordis_run
- Modifying workspace plugins in the packages/ directory of the DSH repository that are released with the distribution
- Adding dsh.bundle and cordis.patch.yml to external packages to make them installable bundles
- Reviewing Loader exports, Service/Provider/Consumer ownership, Client Slot, CLI surface, configuration, lifecycle, and profile composition

What it explicitly does NOT do: marketplace listing, integrated packages, dsh.pack.json, or dsh-plugin-pack. That work belongs to another repository dsh-marketplace-publish.

Core Features¶

Classify first, then define rules¶

SKILL.md requires assistants to determine the plugin mode before starting work, and not directly apply the rules of one mode to another:

Choosing the wrong mode will lead to completely different deliverables. When the evidence is insufficient and the three modes require different files, the Skill requires only one question: should the result be in-process, released with the DSH repository, loaded into a profile, or an integrated marketplace package?

Fixed workflow: from discovery to reporting¶

After selecting a mode, the process follows six fixed steps:

1. Discovery: Examine the target, current configuration, adjacent implementations, repository status, and real loading paths.
2. Plan components: Identify consumers, current owners, required plugin roles, configuration owners, lifecycle owners, observable results, and evidence. Use a simple table for cross-role tasks.
3. Finalize decisions: Entry point and preconditions, actions and inputs, results or status, failures and recovery, cleanup, model-visible side effects, authorization boundaries.
4. Implement: Modify only necessary components, and update corresponding documentation according to the selected mode.
5. Verify: Use real dynamic tools, Loader, packaging, or consumer entry points; static checks cannot replace this step.
6. Report: First document the results, selected mode, changes or audit findings, actual executed checks, unresolved risks, and next steps.

Authorization is also hardcoded: Q&A, review, and diagnosis default to read-only; creation and repair can modify local files and run non-destructive checks; publishing, external writes, destructive deletion, and execution of untrusted dependency install scripts require explicit confirmation first.

Common pitfalls for each mode¶

Dynamic plugins only exist in the current process. The reference documentation requires first checking the live Host/Client Provider, then defining an immutable package with cordis_define and activating it with cordis_run. The function body must be plain JavaScript, and cannot use import, require, TypeScript, or JSX; client-side code uses React.createElement, and the UI can only be mounted to a queried Slot. When there is no live cordis_inspect_* tooling, the Skill only allows design and diagnosis, and must explicitly state which activation results have not yet been verified, and cannot pretend that the plugin has started running.

Workspace plugins are tied to the DSH repository, and the authoritative source is the documentation, types, and Loader in the current checkout, not outdated manifests copied from tutorials.

Installable bundles are a layer of configuration on top of a profile, not the profile itself. Declare dsh.bundle.patch in package.json, and the profile’s dsh.profile.bundles is maintained by dsh plugin—do not edit it manually. The adapter in this repository itself takes this form: package.json points to ./cordis.patch.yml, and the patch inserts a line id: dsh-plugin-development-skill and name: dsh-plugin-development. index.js reads the packaged SKILL.md frontmatter and calls ctx.skills.register(); when uninstalled, it only revokes this registration, and will not delete Skill copies that users have installed separately in their personal directories or project directories. A local Skill with the same name in the project can still override this runtime registration according to the host discovery rules.

Built-in static preflight script¶

The Skill directory contains a read-only script scripts/check-artifact.mjs for early checks by plugin authors, which cannot be used as complete verification evidence:

node skills/dsh-plugin-development/scripts/check-artifact.mjs workspace-function path/to/index.ts
node skills/dsh-plugin-development/scripts/check-artifact.mjs bundle path/to/package

• workspace-function: Checks workspace function plugin source files
• bundle: Checks that package.json, dsh.bundle.patch, and the patch file are consistent

The reference documentation for bundle mode clarifies that it cannot verify npm packaged file lists, runtime module resolution, patch semantics, profile priority, or startup behavior. Before publishing, you must still install the real artifact in an isolated profile, run dsh --profile --dump-config, and then verify registration, Fiber cleanup, and uninstallation.

Installation and Activation¶

The installation command provided on the community catalog page is as follows, run in the DeepSeek Harness terminal:

dsh plugin add github:w2112515/dsh-plugin-development

For reproducible installations, the catalog page recommends pinning a commit:

dsh plugin add github:w2112515/dsh-plugin-development#commit

Replace commit with the reviewed SHA, do not pin moving branches.

The repository README states that the DSH adapter is an optional path, only used when you want dsh plugin to manage profile installation, versioning, composition, and uninstallation. The current release is v0.2.0-beta.1, and the previous v0.1.0-beta.1 remains immutable. It is recommended to use the release tarball:

dsh plugin --profile web add https://github.com/w2112515/dsh-plugin-development/releases/download/v0.2.0-beta.1/dsh-plugin-development-0.2.0-beta.1.tgz
dsh --profile web --dump-config

The exported configuration should include the dsh-plugin-development section and the line ID dsh-plugin-development-skill. You can also install from Git via a pinned tag; the adapter is plain JavaScript and Markdown, with no prepare, install, or postinstall scripts:

dsh plugin --profile web add github:w2112515/dsh-plugin-development#v0.2.0-beta.1

For local adapter development, run in the repository root:

dsh plugin --profile web add .

You can also skip the bundle and let the host discover the Skill directory directly. DSH will read the same directory from .dsh/skills/dsh-plugin-development, .agents/skills/dsh-plugin-development, or skills/dsh-plugin-development under the project. .agents/skills can be shared with Codex. Codex can also be installed to ~/.codex/skills/dsh-plugin-development and invoked explicitly via $dsh-plugin-development; Claude Code can be installed to ~/.claude/skills/dsh-plugin-development or .claude/skills/dsh-plugin-development within the project, and invoked via /dsh-plugin-development. The repository intentionally does not include .codex-plugin / .claude-plugin, as both hosts do not require an additional wrapper plugin to use this Skill.

package.json declares the runtime environment as Node.js ^22.19.0 || >=24.0.0. The repository self-test commands are:

npm test
npm pack --dry-run

If you have a built DSH checkout, you can also run:

node scripts/verify-dsh-runtime.mjs path/to/deepseek-harness

Typical Usage¶

After installation, simply describe your DSH plugin task to the current assistant. The Skill’s description will match requests for design, creation, modification, packaging, installation, review, audit, or diagnosis; you can also write $dsh-plugin-development in Codex, or /dsh-plugin-development in Claude Code.

Below are reproducible usage examples from the README and SKILL.md, not fictional cases.

1. First ask the assistant to determine the mode. For example: “Add a Client Slot panel to the current DSH process” should use the dynamic runtime mode; “Modify a package in packages/ that is released with the repository” should use the workspace mode; “Turn this external npm package into a bundle that can be installed via dsh plugin add” should use the installable bundle mode. If the task is actually for an integrated package or catalog listing, the assistant should stop per the Skill requirements and use dsh-marketplace-publish instead.

2. Follow live tooling for dynamic plugins. The reference documentation gives the following order: cordis_inspect_list to list Providers → only query the required Service/Event/Slot/Tool → use cordis_inspect_self to read source code and diagnostics if an @pluginId already exists → cordis_define to define the package → cordis_run to activate it. awaiting-approval and starting are not success states; this round should end waiting for system guidance instead of polling in the same turn. To deactivate, use cordis_stop; cordis_undefine is a destructive deletion that requires explicit authorization.

3. Perform static precheck first for bundles, then install to an isolated profile. Run the check-artifact.mjs bundle command above in the package root, then run npm pack --dry-run to check if the packaged files include the patch and runtime entry, and do not include keys or local files. For formal verification, follow the release notes: load the exact tarball into a one-time DSH home directory, check --dump-config, load the installed entry point, and verify registration, destruction, and uninstallation. Do not overwrite the user’s active profile for取证 purposes.

4. Review requests default to no code changes. When handing over a repository or patch for auditing, the Skill requires only inspection and reporting, unless modification is explicitly requested.

Applicable Scenarios and Notes¶

This is suitable for:
- Developers writing their first DSH plugin who are confused about dynamic plugins, workspace packages, and bundles
- Developers who have an existing external package and want to package it according to the current DSH dsh.bundle contract for installation and uninstallation
- Developers who need to review other people’s DSH plugins: Loader exports, dependency injection, lifecycle, and whether Git installation will execute build scripts
- Users who use Codex / Claude Code / DSH simultaneously and want all three hosts to follow the same set of plugin development specifications

It is not suitable for, or will actively reject, tasks such as: creating marketplace integrated packages, treating tutorials or outdated Agent Notes as current APIs, or claiming that a dynamic plugin is running without live Cordis tooling.

Please note the following before use.

The plugin runs with the permissions of the current DSH process, and may execute code during installation. Both the catalog and the repository require you to first check the source code and license. This repository’s adapter has no install-time scripts, but this only applies to this specific package; you must still review third-party dependencies separately. Git installations with prepare build scripts allow dependency code execution on your machine, which requires explicit authorization and pinned commits.

Both DSH and this Skill are still in preview/Beta. The Skill explicitly prohibits overriding executable constraints in the current repository with remembered package lists or tutorial manifests; when documentation and implementation conflict, you must cite both, and cannot silently reconcile them. The community plugin catalog is an independent site, not the official app store of DeepSeek / HyperFusion.

Uninstalling the bundle will only revoke the Skill registration added by the adapter, and dsh-plugin-development instances placed separately in personal directories or project directories will not be deleted.

Summary¶

dsh-plugin-development separates the three most confusing parts of DSH plugin development: in-process dynamic plugins, repository workspace packages, and profile-installable bundles, and adds “what is the evidence” instead of “whether the code compiles” for review and diagnosis. The same Skill directory can be used by Codex, Claude Code, and DSH; the optional bundle adapter only handles registering it into the current profile and cleaning up the registration during uninstallation.

Catalog page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-plugin-development/

GitHub: https://github.com/w2112515/dsh-plugin-development