DSH | dsh-plugin-shop | Browse, install and update dsh plugins from a daily, git-auditable catalog

[LivXue]

Unofficial project, independently developed and maintained by community members. It is not reviewed or endorsed by DeepSeek.

Project URL

https://github.com/LivXue/dsh-plugin-shop

Introduction

dsh-plugin-shop is a plugin shop that installs into DSH itself: a tab under
Settings → Plugins, where you can browse the dsh plugin ecosystem, check whether a
plugin will actually run on your profile, and install, enable or update it without
leaving the harness.

The catalog behind it is built by harvesting the whole public registry, once a day:

• every npm package keyed dsh-plugin or deepseek-harness, and every GitHub
  repository using those as topics. Nothing is submitted here — there is no queue,
  no form and no maintainer to convince. Publish with the keyword and the next
  morning's build finds you.
• as of the 2026-09-06 build, that is 9,753 listed plugins and 11,614 filtered out.
  The two badges above read those numbers live, so they are current whenever you are
  reading this.
• every candidate is gated mechanically on every build, and one that fails becomes a
  named rejection carrying an author-readable reason — attached to the build so an
  author can find out why their package is not listed, instead of silently vanishing.
• the whole catalog is committed to git, so every daily change is a reviewable diff
  rather than a row in someone's database.

On honesty, since the guidelines rightly ask readers to vet third-party projects:
today no listing in this catalog has been read by a human. Every entry is
community-tier, and installing one asks you for an explicit acknowledgement first
(third screenshot below). The filtering is mechanical, and it is not a substitute for
reading the code you are about to run. A dsh plugin, once mounted, holds the full
ctx — your filesystem, your shell, and the requests going to the model. The shop is
not a sandbox. It does not change what installing a plugin means; it tries to tell you
the truth before you click.

How it integrates with DSH

It is a dsh plugin, installed the ordinary way:

# Pin the version: pnpm 11 holds back very recent releases, so a bare
# `add dsh-plugin-shop` can hand you an older one for a while.
dsh plugin --profile web add dsh-plugin-shop@0.7.4
# or straight through npx, nothing installed globally:
npx -y @deepseek-ai/dsh plugin --profile web add dsh-plugin-shop@0.7.4

Then open Settings → Plugins → Plugin shop. Three integration points are worth
naming:

1. It uses DSH's own installer. Clicking Install shells out to
   dsh plugin --profile <p> add <spec> (and remove for uninstall). The shop never
   writes to your profile itself, so what it installs is exactly what you would have
   installed by hand — and it will never offer an "install from arbitrary URL" button.
   That capability stays in dsh plugin add, where enabling build scripts and pinning a
   commit are decisions you make explicitly.
2. Compatibility is resolved on your machine, not asserted by the catalog. The build
   records each plugin's declared peer names only, never their version ranges; your
   installation resolves those names against your own profile — the same question dsh's
   loader asks at mount — so a card reads Incompatible only when the modules are
   really missing here.
3. Zero-privilege UI. The browser half talks to the host over a small set of
   shop/* RPC methods and touches no network and no filesystem of its own.

Plugins are shelved into seven categories (tool, provider, ui, workflow,
integration, theme, other). An author who declares a dsh.catalog section picks
their own category and writes their own en/zh summary; everyone else gets a listing
derived from their npm description.

Listing your own plugin: add dsh-plugin or deepseek-harness to keywords in
package.json and publish to npm. A plugin that never publishes to npm is listed from
its GitHub repository instead — add the same keyword as a repo topic and keep a
package.json at the root with a name and dsh.bundle.

Screenshots

The shelf — light theme

The same shelf — dark theme

Installing an unreviewed plugin requires an explicit acknowledgement

The interface follows the harness language setting — the Chinese section below shows
the same three screens in zh.

---

非官方项目，由社区成员独立开发和维护，未经 DeepSeek 审核或推荐。

项目地址

https://github.com/LivXue/dsh-plugin-shop

项目介绍

dsh-plugin-shop 把插件商店装进 DSH 本身：在 设置 → 插件 下多出一个页签，可以浏览
dsh 插件生态、确认某个插件在你的 profile 上到底跑不跑得起来，并直接安装、启用和更新，
全程不用离开 harness。

它背后的目录每天重建一次，采集范围是整个公开注册表：

• npm 上带 dsh-plugin 或 deepseek-harness 关键字的每一个包，以及把它们用作 topic 的
  每一个 GitHub 仓库。这里不接受投稿 —— 没有队列、没有表单，也不需要说服任何维护者。
  带上关键字发布，第二天早上的构建就会找到你。
• 截至 2026-09-06 的构建，收录 9,753 个插件，过滤掉 11,614 个。上方两个徽章实时读取
  这两个数字，你看到的永远是当前值。
• 每次构建都会机械地过滤每一个候选包，没通过的会变成一条带作者可读理由的具名拒绝记录，
  随构建一起发布——插件作者能查到自己为什么没被收录，而不是无声消失。
• 整个目录提交进 git，所以每天的变化都是一份可审阅的 diff，而不是某个人数据库里的一行。

关于坦白，既然版规也提醒读者自行甄别第三方项目： 目前这个目录里没有任何一条收录经过
人工阅读。所有条目都是社区等级，安装时会先要求你明确确认一次（下方第三张截图）。过滤是
机械的，它不能替代你亲自读一遍即将运行的代码。dsh 插件一旦挂载就持有完整的 ctx——你的
文件系统、你的 shell、以及发往模型的请求。这个商店不是沙箱，它不改变"安装插件"这件事
的性质，只是尽量在你点下去之前把真相讲清楚。

与 DSH 的集成方式

它就是一个普通的 dsh 插件，按常规方式安装：

# 建议锁版本：pnpm 11 会压一段时间最新发布，直接 add 可能给你一个旧版本。
dsh plugin --profile web add dsh-plugin-shop@0.7.4
# 或者完全不装全局依赖，直接走 npx：
npx -y @deepseek-ai/dsh plugin --profile web add dsh-plugin-shop@0.7.4

装好后打开 设置 → 插件 → 插件商店。三个集成点值得单独说明：

1. 安装动作走的是 DSH 自己的安装器。 点击安装会调用
   dsh plugin --profile <p> add <spec>（卸载则是 remove）。商店自己从不写你的
   profile，所以它装出来的东西和你手动装的完全一致；它也永远不会提供"从任意 URL 安装"
   的按钮——那个能力留在 dsh plugin add 里，是否放行构建脚本、是否锁定某个 commit，
   都由你显式决定。
2. 兼容性在你的机器上判定，而不是由目录断言。 构建只记录插件声明的 peer 名字，
   从不记录版本范围；由你的安装去用自己的 profile 解析这些名字——和 dsh 加载器在挂载时
   问的是同一个问题——所以卡片显示不兼容，一定是这些模块在你这里真的缺失。
3. 零权限 UI。 浏览器一侧只通过一组 shop/* RPC 方法与宿主通信，自身不碰网络、
   不碰文件系统。

插件按七个分类上架（tool、provider、ui、workflow、integration、theme、
other）。声明了 dsh.catalog 的作者可以自己选分类、自己写 en/zh 简介；没声明的，
目录会从 npm description 派生一条条目。

想让自己的插件被收录： 在 package.json 的 keywords 里加上 dsh-plugin 或
deepseek-harness，然后发布到 npm。从不发 npm 的插件也能从 GitHub 仓库收录——把同样的
关键字加成仓库 topic，并在根目录保留一个带 name 和 dsh.bundle 的 package.json。

截图

插件货架——浅色主题

同一个货架——深色主题

安装未经审核的插件前，需要显式确认

[argszero]

Nice to see the no-queue mechanical harvest — named machine rejections attached to each build is a genuinely honest improvement over silent drops. One coverage data point from the plugin-author side, since the catalog's completeness depends on the harvest key:

Your key is dsh-plugin / deepseek-harness (name or topic), but a large part of the ecosystem publishes under the cordis-plugin naming family instead — including official-scope packages (@deepseek-ai/cordis-plugin-group, @deepseek-ai/cordis-plugin-include, @deepseek-ai/cordis-plugin-timer are on npm), and community ones like my six @argszero/cordis-plugin-* (subagent-effort, git-status, session-audit, subagent-wait, schedule-cron, preset-tool-filter). I searched the 2026-09-06 build metadata for argszero and got zero hits — so that family is currently invisible to the shop regardless of quality.

Questions that would make the coverage gap actionable:

1. Do you key on package name prefix or on the keywords field? If keywords, would adding dsh-plugin to a cordis-plugin-* package's keywords get it harvested (one-line fix for authors)?
2. As a self-check: are the official @deepseek-ai/cordis-plugin-* packages listed? If the official scope's own convention is missing, the harvest key is likely too narrow.

Adding the cordis-plugin name family to the key (or documenting that it intentionally targets only dsh-plugin-named packages) would close the split. Also relevant: #5858 (DSH Plugin Manager) is building adjacent tooling — a shared naming/scope convention between shop and manager would help the ecosystem more than either alone.

[LivXue]

Thanks — the per-package detail below is the useful part, and one of your two questions found a real defect on our side.

Q1: the keywords field, never the name. Two keys, dsh-plugin and deepseek-harness: the npm half matches the npm keywords field (HARVEST_KEYWORDS, registry/scripts/src/npm-client.ts:11), the GitHub half matches repository topics (HARVEST_TOPICS, registry/scripts/src/github-client.ts:36). Harvesting by name prefix is ruled out by design — a name pattern is trivially spoofed, so dsh-plugin-* in a name earns nothing. So your one-line fix is real: either keyword in keywords, or either one as a repo topic.

For five of your six, though, the keyword is necessary and not sufficient. Checked against latest today:

package	harvest key	dsh.bundle	what it still needs
@argszero/cordis-plugin-subagent-effort@0.1.0	yes (deepseek-harness)	yes	repository — that's all
@argszero/cordis-plugin-git-status@0.1.0	no	no (dsh.client only)	keyword + dsh.bundle + repository
@argszero/cordis-plugin-session-audit@0.1.3	no	no (dsh absent)	keyword or topic + dsh.bundle
@argszero/cordis-plugin-subagent-wait@0.1.0	no	no (dsh absent)	same
@argszero/cordis-plugin-schedule-cron@0.1.0	no	no (dsh absent)	same
@argszero/cordis-plugin-preset-tool-filter@0.1.0	no	no (dsh absent)	same

subagent-effort is the interesting one: it is already harvested — your deepseek-harness keyword works — and it already has a named rejection, no-repository: "Declares no repository, so the published code cannot be audited." Add "repository" to its package.json and republish; nothing else is in its way. Its GitHub repo isn't a shortcut, incidentally: GitHub reports no license and no description for argszero/cordis-plugin-subagent-effort, so that channel would want a LICENSE file plus a description or a dsh.catalog first. (A rejected npm package does not shadow its own repository, so the two channels really are independent here.)

The other five stop at dsh.bundle. Four declare no dsh field at all — neither on npm nor at the repo root — so dsh would install them as plain dependencies rather than plugins; that field is what the gate reads to tell an installable plugin from a library. git-status declares dsh.client only, which is the shape the official @deepseek-ai/dsh-client-ui-* modules use for injection rather than standalone installation. If a dsh.client-only manifest is meant to be installable on its own, please say so — that would be a gap in our gate, and I would rather hear it from an author than guess.

Q2: no, and that is policy rather than an accident of the key. The shop lists third-party plugins; the official ones are already in dsh's built-in plugin list. All three you named ship inside dsh: a @deepseek-ai/dsh@0.1.2-rc.1 install carries @deepseek-ai/cordis-plugin-group, -include and -timer in its own node_modules (alongside -loader and -hmr), and -timer and -include are direct dependencies of the CLI package. A shelf row for them would advertise something every dsh user already has, with an install button that changes nothing. So the official scope's convention is not missing from the harvest key — it is out of scope for the shelf, and the shop deliberately does not list plugins that ship with the harness.

Nothing had to be hardcoded to get that outcome, which is the part worth knowing: the three declare no keywords at all, so nothing harvests them in the first place; and each declares repository: deepseek-ai/deepseek-harness, which the gate rejects as harness-repository because the host project's repository holds none of the plugin's source and so audits nothing. (The harness repo does carry the dsh-plugin topic, so the GitHub half sees it — it just cannot resolve a plugin from a monorepo root.)

The defect you found. Your "zero hits" is not a search error: the build report is not published. index.json and badge.json are served from Pages; report.md and classification-report.md are only uploaded as a zipped CI artifact on the Actions run. So subagent-effort's no-repository row exists, is accurate, and is unreachable by the one person who needs it — which makes "named machine rejections instead of silent drops" half-true at best, since the half that matters to an author is the half that isn't served. The publish flow will be fixed in the next release so both reports are served next to the catalog.

On scale, for the record. The numbers don't show a split. Measured today: 3,924 packages carry keywords:dsh-plugin and 5,356 carry keywords:deepseek-harness. Of the 438 carrying a cordis-plugin keyword, 436 already carry one of those two. Enumerating all 1,680 keywords:cordis packages, 10 are named *cordis-plugin* and 7 carry neither harvest keyword — five of those seven are yours, and the other two (cordiverse/cron, clinal/cordis-android) are upstream Cordis framework plugins rather than dsh plugins. One honest caveat: npm offers no name-pattern enumeration, so that count is bounded by the keywords:cordis set — a cordis-plugin-* package tagging neither cordis nor a harvest keyword would not appear in it. If you know of ones that fit that description, names would help more than a count.

Agreed on #5858. A shared convention between shop and manager is worth having, and "declare dsh.bundle, tag one of two keywords" is a small enough contract for both to hold.