# dsh plugin shop: a catalog rebuilt daily and installed by exact version

> A plugin shop for DeepSeek Harness that discovers candidates automatically from npm keywords and GitHub topics, screens them on every build against three questions with seventeen rejection reasons, and commits the catalog to Git. Compatibility is decided by checking whether a dependency exists at all rather than whether a version range matches, and every documented install pins a version because the package manager holds back fresh releases.

**LivXue/dsh-plugin-shop** — The most comprehensive DeepSeek Harness plugin market — refreshed daily, sourced across the Internet, reviewed before publishing.

- Repository: https://github.com/LivXue/dsh-plugin-shop
- Stars: 1,000 · Forks: 11
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/livxue-dsh-plugin-shop

## The catalog is a committed artifact rebuilt every morning

The catalog is not a runtime query against npm. It is a file in this repository, rebuilt daily and committed to Git.

The page says eligible new plugins are listed the next morning after a build, and that plugins whose repositories are no longer available are removed during the same process. Removal is therefore part of the daily cycle rather than a separate cleanup, which means a repository that disappears takes its listing with it within a day.

Two published artifacts back this. The catalog is an index file plus a separate checksum file covering the plugin records, and the plugin shop verifies the checksum and caches the result when it fetches. The build report is committed too, which is what makes the removal auditable rather than silent.

The code is split in two halves that share a data schema but no code. The catalog build lives in a registry directory and runs in this repository, on a schedule. The shop itself is a local npm package that a profile installs and runs. That split is why a catalog change can land without touching the shop, and why the shop can be updated without waiting for a rebuild.

## Screening asks three questions and rejects with seventeen reasons

Discovery is automatic, so quality control has to be automatic too.

Candidates are collected from npm packages carrying either of two keywords and from GitHub repositories carrying either of the same strings as topics. Authors do not submit an application and do not join a queue. Categories are a similar story: an author can choose one through a field in the plugin manifest, and if they do not, the build assigns one, with seven categories in total.

The gate is three questions, shown as a flowchart. Is it a loadable plugin, meaning it has a valid bundle field? Can it be reviewed, meaning it has a license and an accessible source repository? Can it be installed, meaning it is not deprecated on npm and its repository is in usable shape.

Every candidate is re-checked on every build, and the important detail is what happens on failure. A rejected plugin is recorded by name with one of seventeen predefined reasons plus a detailed explanation aimed at helping the author troubleshoot. Two badges show the current totals of listed and filtered plugins, so the rejection count is public rather than hidden.

That design has an obvious cost: a plugin with a slightly malformed manifest is invisible rather than flagged in place. The published report is the only way to find out.

## Compatibility is decided by presence, not by version range

This is the part of the project that most deserves a close read, because it looks like a shortcut and the page explains why it is not.

The catalog records the names of the peer dependencies a plugin requires, without version ranges. The shop then checks whether each named dependency is available in your profile or provided by the web client, and a card is marked incompatible only when a dependency is missing from your environment, or when the author's declared support for harness versions or profiles does not cover what you are running.

The reason for skipping ranges is stated directly. Nearly all plugins for this harness declare a wildcard, but the harness's own prereleases do not satisfy ordinary version ranges, so a range check would mark working plugins as incompatible. In other words, the ecosystem's own release cadence breaks the standard mechanism, and presence checking is the fallback.

The cost of that choice is real and worth stating: a dependency that exists but at an incompatible version will read as fine. The check answers whether the module is there, not whether it behaves. Note also that a version comparison still happens for the second condition, the author's declared harness support, which is a different axis from peer dependencies.

The catalog also records declared support rather than inferring it, so a plugin with no declaration is not filtered on that axis at all.

## The shop runs locally and the client calls nine host methods

The second flowchart describes the runtime path, and it draws a trust boundary that is easy to miss.

The host fetches from multiple sources concurrently, verifies the checksum and caches the result. That is the only component with network access. The client, which is the plugin shop inside the settings screen, calls nine methods on the host with a common prefix, and is described as having no network or filesystem access of its own.

So the catalog data path is host then client, never the other way round. A user interface that can reach the network and read files is a different security proposition from one that can only ask the process hosting it nine questions, and the project states the restriction rather than implying it.

Two user-facing details sit in the same area. The screenshots caption a confirmation step that appears before installing an unreviewed plugin, which means the shop distinguishes reviewed from unreviewed at the point of install. And the shop appears inside the harness settings rather than as a separate application, at Settings, Plugins, Plugin shop, which is why it has to fit the host's method surface instead of running its own server.

## Every documented install pins a version, and the page explains why

The install command is short, and the comment above it is longer than the command.

```sh
# With dsh installed globally, run the following command.
# Specify the version: pnpm 11 restricts newly published releases by default,
# so omitting the version may install an older release. The current version
# is shown below; check for updates with `npm view dsh-plugin-shop version`.
dsh plugin --profile web add dsh-plugin-shop@0.8.4
# Alternatively, run the installation command through npx:
npx -y @deepseek-ai/dsh plugin --profile web add dsh-plugin-shop@0.8.4
```

The reason for the pin is that the package manager's release cooldown means an unpinned add can resolve to a previous version rather than the newest one. The mitigation is to name the version, and to check what is current with a query against the registry.

The version in the block is 0.8.4 while the newest published release tag on the repository is v0.8.3, so the documentation is ahead of the releases, which is what you would expect if the shop publishes on its own schedule.

The harness itself does not have to be installed globally, since it can be run through npx, but plugin management invokes both the harness command and the package manager, so both are installed together with a global install and then checked individually with their version flags.

## The profile option is required and the error message is quoted

There is a second, longer install path written for an agent that runs without interaction, and it starts with the one thing that is not optional.

The profile option is required, and the page quotes the exact failure when it is missing: the plugin command exits with an error saying the required option was not specified. The first step is listing the profiles that already exist, reading the harness home directory, which defaults to a dot-directory in the user's home, and excluding the node_modules entry.

```sh
# 1. List available profiles ($DSH_HOME defaults to ~/.dsh; exclude node_modules).
ls -1 "${DSH_HOME:-$HOME/.dsh}/profiles" | grep -v '^node_modules$'

# 2. Specify the version to bypass pnpm's release cooldown and ensure
#    that the expected version is installed.
dsh plugin --profile <profile> add dsh-plugin-shop@0.8.4

# 3. Verify the installation; exit code 0 above only means pnpm resolved the package.
dsh plugin --profile <profile> list --depth 0   # The output should include dsh-plugin-shop.

# 4. Restart the profile to load the new plugin.
dsh --profile <profile>
```

Step three carries the sentence that matters most for automation: a zero exit code above only means the package manager resolved the package. So a scripted install cannot treat success as completion, and the page gives a second check, reading the profile's package manifest and confirming the plugin appears in its bundle list.

Step four is a restart, because the harness loads plugins at startup. For troubleshooting the page points at a failure-modes section inside the plugin package's own readme, which is where the mismatch cases live.

## The catalog build runs TypeScript without compiling it

The registry manifest explains itself better than the prose does.

It is private and named for the registry rather than the shop, and it declares two accepted Node versions with a floor and a jump: 22.19 or newer, or 24. That floor is not arbitrary, because all three catalog scripts run TypeScript files directly through Node's type-stripping flag rather than compiling first. There is no build step for the catalog code, no bundler, and no transpiler in the dependency list.

The consequence is that the Node version is effectively part of the toolchain. Type stripping is a feature, so the scripts fail on a runtime without it, and the engine range is the guard.

The dependency list is four packages. A fuzzy string matching library, a semantic version library, a YAML parser and a schema validator. The presence of the version library next to the project's decision not to check version ranges is the interesting detail, and it is consistent: ranges are used for the author's declared harness support matrix, not for peer dependencies.

Around that, the repository splits its TypeScript configuration three ways, a base plus one for the client and one for the host, mirroring the boundary in the runtime flowchart. Tests run on a single runner, type checking is a separate command, and the documentation set is bilingual: the readme, contributing guide, code of conduct and security policy each have a translated counterpart.

## Conclusion

dsh-plugin-shop is a catalog with a review process attached, and the review process is the interesting half. Nothing is submitted by hand, candidates are discovered by keyword and topic, every one is re-checked on every build, and every rejection is written into the repository with a reason and an explanation so an author can fix their plugin rather than guess. Two design choices are worth understanding before you install anything. Compatibility is answered by presence rather than by version range, which means a plugin can be marked ready with a dependency at a version you would consider wrong, and the reasoning given for that choice is that plugins commonly declare a wildcard while harness prereleases would fail an ordinary range check. And the install is pinned on purpose, because an unpinned add can quietly land an older release. Check the daily diff before an upgrade, and read the package's failure-modes section if an install seems to succeed without loading.

## FAQ

### How do I install the DeepSeek Harness plugin shop?

Node.js is the prerequisite. Install the harness and pnpm together with npm install -g @deepseek-ai/dsh pnpm, confirm them with dsh --version and pnpm --version, then run dsh plugin --profile web add dsh-plugin-shop@0.8.4, or the same command through npx -y @deepseek-ai/dsh. Restart the harness and open Settings, then Plugins, then Plugin shop.

### Does a plugin have to be submitted to dsh-plugin-shop?

No. The catalog collects npm packages carrying the dsh-plugin or deepseek-harness keyword and GitHub repositories with either as a topic, and authors do not submit an application or join a queue. Categories are chosen through dsh.catalog, or assigned by the build, with seven categories in total.

### Why does installing a dsh plugin require an exact version?

Because pnpm 11 restricts newly published releases by default, so omitting the version may install an older release than the one documented. The install block pins 0.8.4, and the page tells you to check the current version with npm view dsh-plugin-shop version. The newest repository release tag at the time of writing is v0.8.3.

### How does dsh-plugin-shop decide that a plugin is incompatible?

By checking whether each declared peer dependency is available in your profile or provided by the harness web client, not by comparing version ranges, since plugins commonly declare a wildcard and harness prereleases would fail ordinary range checks. A plugin is also filtered when the author's declared supported harness versions or profiles do not cover what you are running.

### What happens to plugins the catalog rejects?

Every candidate is screened on each build against three questions: whether it is a loadable plugin with a valid bundle, whether it can be reviewed with a license and an accessible source repository, and whether it can be installed given it is not deprecated. Rejections are recorded by name with one of seventeen predefined reasons and an explanation, and two badges show the current listed and filtered totals.

## Sources

- [Issues](https://github.com/LivXue/dsh-plugin-shop/issues)
- [License: Apache-2.0](https://github.com/LivXue/dsh-plugin-shop/blob/main/LICENSE)
- [LivXue/dsh-plugin-shop on GitHub](https://github.com/LivXue/dsh-plugin-shop)
- [README](https://github.com/LivXue/dsh-plugin-shop/blob/main/README.md)
- [Releases](https://github.com/LivXue/dsh-plugin-shop/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/livxue-dsh-plugin-shop