Submit a DeepSeek Harness (DSH) plugin

1. Add a GitHub topic — the collector finds it

The collector runs against the GitHub API and indexes any public repository carrying one of these topics. Adding dsh-plugin to your repository is the fastest path in — it is also what the rest of the DeepSeek Harness ecosystem already searches on.

• dsh-plugin
• deepseek-harness
• dsh
• dsh-skill
• dsh-preset

One caveat, so nobody is surprised: a repository that carries none of those topics and never mentions DSH or DeepSeek Harness in its name or description is dropped as a keyword collision — that filter exists because Dshell, DSharpPlus and DsHidMini were all really being pulled in.

2. Anything the collector missed — open an issue

Wrong verdict, wrong category, a repository that should be here but is not, or an entry that should be removed: open an issue or a pull request against the data repository. Every install verdict is derived from a repository's package.json against the official publish spec, with the evidence stored per entry, so a correction is a factual argument, not a favour.

Both links are placeholders until the public data repository is up — they are marked with a TODO in the source of this page. We would rather show you a placeholder we admit to than a form that quietly goes nowhere.

What makes an entry pass our install check

We do not rate plugins. We check one thing: can a user actually install this, and does anything run on their machine while they do. The rules below are the official DSH publish rules — every verdict on this site comes from them, not from a model's opinion. Of 284 entries checked so far, 124 pass, and 40.5% fail outright.

• Declare dsh.bundle in your package.json

  This is what makes your package a bundle instead of an ordinary dependency. Without it, dsh plugin add warns and activates no layer — the user installs your package and nothing happens. That is the single biggest failure mode in this ecosystem: 79 of the 284 entries we checked are missing it.

• Publish to npm so users get a prebuilt artifact

  An npm install hands the user your build output. A git install hands them your source tree. Only 85 of the 284 entries we have checked are on npm — the denominator here is the checked set, not the 7,210 listed entries, because we cannot know this for a repository whose package.json we never found. That ratio is why the next rule catches so many.

• If you are installed from git and need a build, ship a prepare script

  A git install pulls source, not build output. A TypeScript package with no lib/ output and no prepare script fails to load — we label that Build fails, and 36 entries currently sit there.

• Know what a prepare script costs your users

  pnpm ≥10 refuses to run prepare for a git dependency. Your users have to allowlist your package in pnpm-workspace.yaml by hand — which means explicitly letting your code execute on their machine, outside the agent sandbox. The official guidance is to only allow sources you trust and to pin the commit. We label these entries Needs allowlist (9 so far) and we flag every entry that runs install-time scripts (68 so far). Publishing to npm avoids the whole problem.

{
  "name": "your-dsh-bundle",
  "dsh": {
    "bundle": {}
  }
}

6,962 entries are labelled Not checked — we could not find a package.json for them. That is not the same as fine, and we will not print it as if it were. If yours is one of them and the file exists, tell us where.

No paid placement, and no links for sale