Submit DSH plugin to the DSH Plugin Hub (DeepSeek Harness)

Submitting a DSH plugin to the DSH Plugin Hub boils down to two things: publishing a public GitHub repository and adding the dsh-plugin topic. An automated scan picks it up, and once listed, the plugin appears in the plugin center where developers can search and install it.

Overview

This guide covers the full journey of a DSH plugin, from "written" to "discoverable by developers": meet the requirements, go through the submission flow, and appear in the DSH Plugin Hub plugin center. DSH Plugin Hub is a community plugin marketplace DSH plugin built by the dsh-plugin.org team, embedded under Settings → Plugin Center, listing 4,401 human-curated plugins (source). Note that being listed is not the same as being reviewed: the automated scan lists you as unconfirmed first, and the community flips it to verified only after manually checking compatibility and usability — the bar to submit is low, but whether developers actually install your plugin depends on the quality of your README. If you have not written a plugin yet, start with How to develop DSH plugin.

DSH plugin prerequisites: a public repository plus the dsh-plugin topic

Listing recognizes four things: a public repo, the dsh-plugin topic, an install command in the README, and an apply(ctx) plugin that follows the spec. Check each one (source):

1. The repository is public on GitHub — private repos or binary-only plugins cannot pass automated scanning.
2. The repo Topics include dsh-plugin, which crawlers use to recognize a DeepSeek Harness Plugin.
3. The README includes an install command such as dsh plugin --profile web add <package>, so developers can copy and install it.
4. The plugin exports an apply(ctx) module, following the DeepSeek Harness Plugin spec (source).
5. No impersonation — this is a community hub, not affiliated with DeepSeek AI.

The two easiest to miss are the topic and the README install command: a public repo without the dsh-plugin topic is not recognized as a DSH plugin by the crawler, and a README with an install command whose package name does not match the actual repo fails the moment a developer copies it. GitHub Topics support multiple tags — double-check that dsh-plugin is actually in the list before submitting.

Version compatibility is the other thing developers look at: state in the README which DSH preview version (e.g. 0.1.0-rc.6) your plugin targets, and keep it updated. A plugin whose compatibility note is stale gets uninstalled quickly, because preview releases change plugin APIs often — the apply(ctx) spec itself is stable, but the capabilities you register through ctx can shift between preview versions.

DSH plugin submission flow: from GitHub to listing

The submission entry is the Submit page, matching mainstream plugin marketplaces: publish → add topic → document trust signals. Three steps:

1. Publish a public repository: write an accurate description, and a README explaining what the plugin does and how to install and use it.
2. Add the topic: add dsh-plugin to the repository's Topics on GitHub.
3. Document trust signals: in the README, include the install command, supported profile, license, screenshots, permissions, and compatibility notes.

Before submitting, run through the page's requirements and checklist: one-line value (what changes after install), copyable install command, visible proof (screenshots/demo/real output), and clear risk (permissions, external services, compatibility). Submission is completely free.

No review fee and no code package are needed — the public GitHub repository is the only thing you submit, so polish the README like a product; it is the first impression of your plugin.

Naming matters more than it seems: the npm package name (or repo name) is what developers type in the install command, so keep it short, lowercase, and descriptive — avoid generic words that collide with other packages. The repo description is also copied onto the listing card, so write it as a one-line value statement, not a file listing.

After listing: auto-sync, verified, and the DSH Plugin Hub plugin center

Once approved, a listing is generated automatically and the plugin appears in the DSH Plugin Hub plugin center. Four things to know after listing:

• Automatic sync: stars, forks, last-updated time, and other metadata refresh regularly; README and version info update with them — no resubmission needed.
• verified / unconfirmed: newly listed plugins start as unconfirmed (auto-discovered, not yet manually verified); once the community checks compatibility and usability, they become verified. Polish the README and keep the repo active to speed it up.
• Visible in-app: users open the Plugin Center in DSH Plugin Hub to search and install your plugin; the card shows the name, description, stars, and last-updated time.
• Listing badge: the Submit page provides badge code for your README; after listing, replace your-owner and your-plugin-slug with the matching parts of your detail-page URL so readers can click through to your listing.

After listing, search for your plugin name in the plugin center and verify the name, description, and stars on the card — the card data comes from repository metadata, so a vague repo description directly hurts developers' first judgment.

Finally, treat the listing as a living page: when the plugin's APIs or compatibility change, update the README and cut a new release — the metadata syncs automatically, and a repo that looks maintained converts far better than an abandoned one. Developers in the plugin center sort by stars and activity, so steady upkeep is the cheapest way to stay visible.

Notes

1. Submission is free; review time depends on whether the repo meets the requirements, usually one refresh cycle.
2. If not listed, check the four common reasons: non-public repo, missing topic, README without an install command, or missing apply(ctx) export.
3. Keep the repo and releases tidy — metadata syncs automatically, no manual follow-up needed.

Source: Submit page, dshplugin/dsh-plugin-hub, official docs - Your first plugin