dsh-plugin-shop: a git-auditable plugin catalog for DeepSeek Harness
The most comprehensive DeepSeek Harness plugin market — refreshed daily, sourced across the Internet, reviewed before publishing.
At a glance
- What is it?
- The plugin shop for DeepSeek Harness harvests npm and GitHub daily, gates every candidate through five mechanical checks, and ships a catalog you install as an npm package. Here is what the repository documents, where the design has sharp edges, and who should not adopt it yet.
- Who is it for?
- Adopt dsh-plugin-shop if you run DeepSeek Harness with a named profile and want plugin discovery that is version-pinned, diff-reviewable in git, and honest about what is missing on your machine. Do not adopt it if your plugins live outside npm and GitHub topics, or if you cannot accept that a catalog entry appears only after the next daily build and only if it clears five mechanical gates.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What dsh-plugin-shop is for, and who is actually in the audience
DeepSeek Harness loads plugins through bundles, and the repository's own instructions point plugin management at the dsh plugin command, which spawns both dsh and pnpm. That command line is where discovery stops being convenient. If you want to know which dsh plugins exist, you either read npm search output or you keep a list somewhere. The shop exists to replace that list with a catalog that is rebuilt every day, committed to git, and served as static JSON.
The audience splits in two, and the README says so explicitly. The first track is people: install the package into a profile, restart dsh, then open Settings, Plugins, Plugin shop. The second track is agents, which run non-interactively and are told to pin the version because deterministic installs are the point of that path. That second track is the more interesting design decision. A catalog that an agent can query and install from without a human clicking through a shelf is a different product from a plugin browser, and the repository leans into it by documenting the failure modes separately in packages/dsh-plugin-shop/README.md.
There is no submission queue. According to the README, every npm package keyed dsh-plugin or deepseek-harness is harvested, plus every GitHub repository using those strings as topics. Authors do not apply to be listed. That removes a moderation step but it also means the catalog's quality is entirely a function of the gate described below, not of anyone's editorial judgement about whether a plugin is good.
The five-gate pipeline: what a candidate has to prove before it is shelved
The harvest is the easy half. The gate is where the repository spends its complexity. Every candidate must clear five checks on every build, and a failure produces a named rejection carrying one of seventeen recorded reasons, written so the plugin's author can read it. The flow diagram names them: is it a plugin at all (a dsh.bundle the loader can mount), is it auditable (a licence and a live repository), is it installable (not deprecated on npm, and for repository listings no build scripts and no workspace: dependencies), does it match what it claims (tarball integrity, publish time, and not a near-miss of another name), and is there anything to show (a valid dsh.catalog, or an npm description).
Two of those deserve attention. The near-miss check is a typosquatting guard, and it is the kind of thing most small catalogs skip. The no-build-scripts and no-workspace-deps rule for repository listings is stricter than npm itself, and it will reject legitimate monorepo packages that happen to be published from a workspace root. That is a deliberate trade: fewer entries, less chance that installing from the catalog runs arbitrary code at install time.
What gets shelved is deliberately thin. One of seven categories, and the declared peer names, never their version ranges. The README is explicit that version ranges are dropped. That choice is what makes the on-machine dependency check possible at all, because the client can resolve names against your profile instead of guessing at a range.
Install commands, profile resolution and the restart that people forget
The README gives two install forms. With dsh on PATH, dsh plugin --profile web add dsh-plugin-shop@0.8.1. Through npx with nothing installed, npx -y @deepseek-ai/dsh plugin --profile web add dsh-plugin-shop@0.8.1. Both pin 0.8.1, and the README explains why: pnpm 11 holds back very recent releases, so a bare add can hand you an older version for a while. That is a real operational detail, not filler.
Prerequisites are Node.js plus two global tools: npm install -g @deepseek-ai/dsh pnpm, verified with dsh --version and pnpm --version. Running the harness itself needs no install, since the upstream-documented form is npx -y @deepseek-ai/dsh web.
The agent path is where the constraints bite. The README states that --profile is mandatory and that without it dsh plugin exits with error: required option '--profile <name>' not specified. To find a profile name, it suggests listing "${DSH_HOME:-$HOME/.dsh}/profiles" and filtering out node_modules, because node_modules is not a profile. After install, a zero exit only means pnpm resolved the package, so the README asks you to confirm with dsh plugin --profile <profile> list --depth 0 and check that dsh-plugin-shop appears. The same fact is also readable in $DSH_HOME/profiles/<profile>/package.json under dsh.profile.bundles, which is the more reliable check if you are scripting.
Finally, restart. A newly added bundle is not applied to a running process and is not hot-applied. The README repeats this in both tracks, which suggests it is a common first-run mistake.
The dependency check is answered on your machine, not in the catalog
This is the part of the design that most distinguishes the shop from a static plugin list. The catalog records peer names. The npm package resolves each recorded name against your own profile, described in the README as the same question dsh's loader asks at mount. A card reads Incompatible only when the modules are really missing here, and the card names what is missing.
The consequence is that two engineers looking at the same shelf can see different cards for the same plugin, and both are correct. The catalog is shared; the compatibility verdict is local. That is a better model than baking a compatibility matrix into the JSON, because a matrix would be stale the moment someone's profile diverges.
It also means the shelf is only as accurate as your profile is representative. If you maintain several profiles, the verdict you see belongs to the profile the host half is running under, not to the one you intend to install into later. The README does not describe a way to preview a different profile's verdict, so treat the badge as scoped to the current process.
What the architecture deliberately does not do
The repository splits into two halves that share no code, only the schema. Everything under registry/ is the daily build; everything under packages/dsh-plugin-shop/ is the npm package. The catalog is content-addressed JSON (index.json plus plugins.sha256.json), committed to git, then published to GitHub Pages and npm. The host half races every origin, verifies sha256, and caches.
That separation has a cost the README does not hide: a new plugin lands the next morning, and a repository that disappears drops out the same way. If you publish a dsh plugin today and want it discoverable through the shop today, you cannot. There is no submission endpoint to poke and no manual refresh documented. The daily cadence is the product.
The content-addressed catalog does buy something concrete. Because the catalog is committed, every change is a reviewable diff, so you can see what entered and left the shelf between two dates without trusting anyone's changelog. The release notes for v0.8.0 describe audit remediation around one install identity, a self-verifying harvest and bounded artifacts, which suggests the integrity story has already been tightened once.
One thing the material does not establish is how the host half behaves when GitHub Pages and npm disagree, or how long the cache holds a stale index. The README describes caching but gives no TTL, so that is unverified.
A genuine alternative, and where the approaches diverge
The obvious alternative is npm search itself, or a curated list in a repository. The difference is not convenience, it is where the filtering happens. npm search will return anything tagged dsh-plugin, including packages that are deprecated, that have no licence, that have no mountable dsh.bundle, or that are named to look like something else. The shop's gate rejects those and records a reason. If you rely on npm search, that filtering work is yours, every time, and you have no record of what you rejected or why.
A hand-curated list is the other alternative, and it is stronger than npm search on editorial quality. It is weaker in two specific ways. First, it does not rebuild itself, so a repository that goes dark stays listed until someone notices. Second, it cannot answer the peer-resolution question, because a Markdown list has no mechanism to check names against your profile. The shop's Incompatible card is the feature a curated list cannot replicate without becoming software.
The trade you accept in return is mechanical rigidity. A plugin that is perfectly good but published from a workspace root, or without a licence file, or with a name that resembles an existing one, will not appear. The gate is not a reviewer who can be persuaded.
Maintenance cost, licence terms and what to check before you commit
dsh-plugin-shop is Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices, but it is not legal advice and the repository's own LICENSE file is the authority. Note that the licence covers the shop, not the plugins the catalog lists. Those carry their own terms, and the gate only checks that a licence exists, not what it says. A permissively licensed shop can shelve a plugin under any licence, so read the plugin's own terms before installing.
The maintenance surface has two parts. The catalog half is maintained by the daily GitHub Actions workflow (the README's badges reference daily.yml and plugin.yml), so your cost is zero unless you fork it. The package half is an npm dependency you upgrade; the README notes that pnpm 11 holds back recent releases, which is why pinning is recommended and why you should refresh the pin deliberately rather than relying on a bare add. The release notes show v0.8.0 was an audit remediation release and v0.8.1 added install cost visibility and a publisher axis to the harvest, so the project is still changing its catalog schema. If you consume the JSON directly rather than through the package, plan for schema movement between minor versions.
Before adopting, verify the profile wiring end to end: run dsh plugin --profile <profile> list --depth 0 and confirm dsh-plugin-shop appears, and read $DSH_HOME/profiles/<profile>/package.json to confirm the bundle landed where you expect. If those two disagree, the shelf you see is not the shelf you installed.
Who should adopt it, and who should wait
Adopt it if you run DeepSeek Harness with a named profile and you want plugin discovery that is pinned, diff-reviewable and honest about local compatibility. The agent path is the strongest case: mandatory --profile, a documented verify step, and a manifest you can read instead of parsing CLI output make it scriptable without guesswork.
Wait if your plugins are not published to npm and not tagged on GitHub with dsh-plugin or deepseek-harness, because the harvest will not find them and there is no submission route. Wait also if you need a plugin listed the same day you publish it, or if your package is published from a workspace root with build scripts, since the repository-listing gate rejects both.
What to verify first is narrow and testable. Confirm the profile name by listing "${DSH_HOME:-$HOME/.dsh}/profiles" and excluding node_modules. Confirm the install with dsh plugin --profile <profile> list --depth 0. Then restart the profile, because the README states a new bundle is not hot-applied, and check that a card you expect to be installable does not read Incompatible for a peer you know is present. If it does, the mismatch is between the catalog's recorded peer names and your profile, and that is the one failure the shop cannot diagnose for you.
Editorial conclusion
Adopt dsh-plugin-shop if you run DeepSeek Harness with a named profile and want plugin discovery that is version-pinned, diff-reviewable in git, and honest about what is missing on your machine. Do not adopt it if your plugins live outside npm and GitHub topics, or if you cannot accept that a catalog entry appears only after the next daily build and only if it clears five mechanical gates. Verify three things first: that dsh plugin --profile <profile> list --depth 0 shows the package after install, that your profile directory is the one you think it is under $DSH_HOME, and that the peer names on a plugin card resolve against that profile rather than a colleague's.
Community notes