How to publish a DSH plugin to a directory

You have a working plugin. Now it needs to be findable. Publishing a DSH plugin has two halves: making the package installable, and making it discoverable. The first is ordinary npm work. The second is where most plugins fail, because discovery in this ecosystem runs on a GitHub topic and the quality of your metadata.

Step 1: finish the package before publishing

A plugin that is ready to be published has four things:

• A published npm package, or a repository spec that installs reliably from git.
• A README that states what the plugin does, the exact install command, and the harness version it targets.
• A license file, because directories filter on declared licenses.
• A dsh.compatibility declaration naming the harness releases you tested, so users can tell whether it matches their harness.

The install command in your README should be copy-pasteable and complete:

dsh plugin --profile web add your-package-name

Step 2: tag the repository for discovery

Directories discover community plugins through the dsh-plugin GitHub topic. Add it to your repository, along with topical tags that describe the capability rather than the technology:

• dsh-plugin and deepseek-harness for discovery.
• A capability tag such as web-search, memory, vision or theme.
• A language tag only if it helps someone decide, such as typescript or python.

The topic is the single highest-leverage thing you can do, because it turns an unindexed repository into a discoverable one without any submission at all.

Step 3: write metadata that survives automation

Directories generate listings from repository metadata. That means your repository description and README are effectively your listing:

Write the repository description as a sentence a developer would search for, not a slogan. “Free web search provider for DeepSeek Harness with a DuckDuckGo backend, no API key needed” beats “Awesome search for agents”.

Step 4: state compatibility honestly

Declare the harness version you tested against. Overstating compatibility leads to install failures and one-star impressions; understating it excludes users who would have been fine. When you update the plugin, update the declaration.

Step 5: submit to directories

Submissions are usually a URL and a short description. Prepare the following before you start:

1. The repository URL.
2. A one-sentence description under 160 characters.
3. The exact install command.
4. The category you believe fits best.
5. Anything a reviewer should know, such as required credentials or a paid endpoint.

You can submit to this directory on the submission page. Expect review to focus on the same four signals used for evaluation: source, install spec, permissions and maintenance.

Step 6: make the listing keep itself accurate

Listings go stale because repositories change and metadata does not. Two habits prevent that: keep the repository description current when scope changes, and keep the install command in the README synchronized with the published package name. A listing that shows a wrong install command is worse than no listing.

FAQ

Do I need to publish to npm?

No. A git install spec works, but an npm package installs faster and more predictably for users behind proxies.

Does adding the topic guarantee being listed?

It makes discovery automatic for directories that scan topics. Manual review may still apply before a listing appears.

Will a directory host my plugin?

No. Directories index metadata and link to your source. Installation always happens from your repository or package.

How do I correct a wrong listing?

Contact the directory. This site accepts corrections through the contact page.

Next steps

Review the security guide so your documentation answers the questions reviewers will ask, then submit through the submit page.