📦 Install the shop
Two tracks. They do the same thing; pick the one that matches who is reading.
🧑 For people
Prerequisites: Node.js. Running the harness itself needs no install — the
upstream-documented form is npx -y @deepseek-ai/dsh web. Plugin management
goes through dsh plugin, which spawns both the dsh command and pnpm —
install them once with npm install -g @deepseek-ai/dsh pnpm and verify with
dsh --version and pnpm --version.
# dsh on PATH (global install). Pin the version: pnpm 11 holds back very
# recent releases, so a bare `add dsh-plugin-shop` can hand you an older
# version for a while. This is the current release — refresh it with
# `npm view dsh-plugin-shop version`.
dsh plugin --profile web add [email protected]
# or straight through npx, nothing installed:
npx -y @deepseek-ai/dsh plugin --profile web add [email protected]
Replace web with your profile if you use another one. Restart dsh once — a newly
added bundle is not applied to a running process — then open
Settings → Plugins → Plugin shop
🤖 For agents
Non-interactive. --profile is mandatory; without it dsh plugin exits with
error: required option '--profile <name>' not specified.
# 1. resolve a profile name ($DSH_HOME defaults to ~/.dsh; node_modules is not a profile)
ls -1 "${DSH_HOME:-$HOME/.dsh}/profiles" | grep -v '^node_modules$'
# 2. install — pin the version: it bypasses pnpm's release cooldown and
# deterministic installs are the point of the agent path
dsh plugin --profile <profile> add [email protected]
# 3. verify — a zero exit above only means pnpm resolved the package
dsh plugin --profile <profile> list --depth 0 # dsh-plugin-shop must appear
# 4. restart the profile; a new bundle is not hot-applied
dsh --profile <profile>
The same fact as step 3 lives in $DSH_HOME/profiles/<profile>/package.json under
dsh.profile.bundles, if you would rather read the manifest than parse CLI output.
Per-failure diagnostics are in the
package README.
🖼️ Screenshots
 |
 |
| Installing an unreviewed plugin requires an explicit acknowledgement |
The same shelf in the dark theme |
✨ Highlights
- 🌐 Whole-registry harvest — every npm package keyed
dsh-plugin or
deepseek-harness, plus every GitHub repository using them as topics. Nothing is
submitted here; there is no queue to join.
- 🧹 Hard filtering — every candidate is gated mechanically on every build, and
one that fails becomes a named rejection carrying one of seventeen recorded reasons,
in words its author can read. The
plugins and filtered badges above count both
sides, live.
- 🔌 Dependency check on your machine — your installation resolves each recorded
peer name against your own profile, the question dsh's loader asks at mount, so a
card reads Incompatible only when the modules are really missing here.
- 🗓️ Daily rebuild — committed to git, so every change is a reviewable diff. A
new plugin lands the next morning; a repository that disappears drops out the same
way.
- 🗂️ Seven categories — an author who declares
dsh.catalog picks their own; the
rest are classified for them.
🗺️ How it fits together
In this repository — the daily build. Everything here is registry/.
flowchart TB
subgraph HARVEST["1 · Harvest — the whole public registry, every day"]
direction LR
NPM(["npm packages<br/>keyword dsh-plugin<br/>keyword deepseek-harness"])
GH(["GitHub repositories<br/>the same keywords,<br/>used as topics"])
end
subgraph GATE["2 · Gate — every candidate must clear all five, on every build"]
direction LR
G1["a plugin at all?<br/><br/>a dsh.bundle the<br/>loader can mount"]
G2["auditable?<br/><br/>a license,<br/>a live repository"]
G3["installable?<br/><br/>not deprecated on npm ·<br/>repo listings also need<br/>no build scripts and<br/>no workspace: deps"]
G4["what it claims?<br/><br/>tarball integrity, publish time,<br/>not a near-miss of another name"]
G5["anything to show?<br/><br/>a valid dsh.catalog,<br/>or an npm description"]
end
subgraph SHELVE["3 · Shelve — what the catalog records"]
direction LR
CAT["one of 7 categories"]
PEER["the declared peer NAMES,<br/>never their version ranges"]
end
NPM --> G1
GH --> G1
G1 -.-> REJ
G2 -.-> REJ
G3 -.-> REJ
G4 -.-> REJ
G5 -.-> REJ
REJ[["rejected — one author-readable reason per name"]]
G5 ==>|"all five clear"| CAT
PEER ==> PUB[["4 · Publish — content-addressed JSON, committed to git, then GitHub Pages and npm"]]
On your machine — the npm package. Everything here is packages/dsh-plugin-shop/.
The two halves share no code, only the schema.
flowchart LR
CAT[["the catalog<br/>index.json + plugins.sha256.json"]]
CAT ==> HOST["5 · Host half<br/>races every origin<br/>verifies sha256 · caches"]
HOST ==> DEP{"6 · Dependency check<br/>resolve each recorded peer<br/>against YOUR profile"}
DEP -->|"one or more absent"| BAD["Incompatible<br/>the card names<br/>what is missing"]
DEP -->|"all resolve"| GOOD["installable"]
BAD --> CLIENT["Client half — the Settings tab<br/>nine shop/* methods<br/>no network · no filesystem"]
GOOD --> CLIENT
CLIENT ==>|"dsh plugin add"| PROF[("your dsh profile")]
Two parts are worth naming, because they are the ones people expect to work
differently:
- The gate rejects; it never silently drops. Every candidate that fails becomes a
named rejection with a reason, attached to the build.
- The dependency check is not a catalog fact. The build records only the peer
names — never their version ranges, because nearly every dsh plugin declares
"*" and the harness's own prereleases do not satisfy ordinary ranges, so checking
them would accuse plugins that work. Whether a name resolves is decided by your
installation, against your profile.
✅ What it is
|
|
| Public and community-run |
Publishing to npm with the dsh-plugin or deepseek-harness keyword is all it takes to be discovered. Nothing is submitted to this project. |
| Git-auditable |
Every daily catalog change is a reviewable diff, not a row in someone's database. |
| Tiered trust, honestly reported |
A review is pinned to the exact version it covered, so an author who passes review once cannot publish a malicious version and inherit the trust. Today registry/verified.yml is empty: no listing has been read by a human, every entry is community-tier, and every install asks for the acknowledgement. The filtering above is mechanical, and it is not a substitute for reading the code you are about to run. |
| Zero-privilege UI |
Compromising the browser interface does not compromise the runtime. |
🚫 What it is not
It is not a sandbox. A dsh plugin, once mounted, holds the full ctx — your
filesystem, your shell, and the requests going to the model. Installing one is
complete trust. This project does not change that; it tells you the truth before you
click.
It also carries no download counts, ratings, or reviews, 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.
📚 The catalog
Built daily and published as static JSON, to two places at once: the npm package
dsh-plugin-shop-catalog and GitHub Pages. Your installation races them — the
registry you have configured, npmmirror, npmjs, then Pages — and takes whichever
answers first, because the link to one of them can be far slower than the link to
another from where you sit. All of them carry the same bytes, and the sha256 in the
pointer is checked before any of them is trusted. DSH_SHOP_CATALOG_URL opts out of
the race and reads only what you name.
| Artifact |
Purpose |
/v1/index.json |
The pointer — schemaVersion, builtAt, the entry count and rejected totals (the badges above read them live), and the content hash. Small enough to poll. |
/v1/plugins.<sha256>.json |
The data — content-addressed, safe to cache indefinitely. |
/v1/stars.<sha256>.json |
GitHub star counts by package name, when the daily build could fetch them |
Each build's rejection report, carrying an author-readable reason for every rejected
package, is attached to the workflow run. Nothing disappears without a reason attached
to its name.
The data files are content-addressed, so each build publishes new names and the previous
ones stop existing, while the pointer above them is cached for ten minutes. If you fetch
/v1/ yourself, re-read index.json whenever a data URL answers 404 — or read the same
bytes from the npm package dsh-plugin-shop-catalog, where the pointer and the data it
names always ship in one tarball.
🏷️ Listing a plugin
Add a harvest keyword (dsh-plugin or deepseek-harness) to your package.json and publish to npm; the daily build picks it up. 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 — the catalog pins the default-branch commit as the version.
A dsh.catalog section is optional — declare it to control your own category, summary
and capabilities, or omit it and the catalog derives a listing from your npm
description instead.
{
"name": "dsh-hello-plugin",
"keywords": ["dsh-plugin"],
"dsh": {
"bundle": { "patch": "./cordis.patch.yml" },
"catalog": {
"category": "tool",
"summary": { "en": "...", "zh": "..." },
"capabilities": ["fs", "shell"]
}
}
}
Full field reference: docs/schema.md.
Not listed, and why: a package without dsh.bundle is a library rather than an
installable plugin. A package without a license or a repository cannot be audited. A
package with neither a dsh.catalog section nor an npm description has nothing to
show.
🗂️ Repository layout
| Path |
What lives there |
registry/ |
The catalog pipeline — a pure core (gate, tier, emit, pipeline) behind an impure shell (npm-client, build) |
registry/verified.yml |
The human review record, pinned per version |
registry/denied.yml |
The denylist; every entry states why |
registry/snapshots/ |
manifest.lock, committed daily |
packages/dsh-plugin-shop/ |
The npm package — Host half and Client half |
docs/design/ |
The specification. It is the authority; code follows it. |
🛠️ Development
pnpm install
pnpm test # vitest
pnpm typecheck
pnpm build:catalog runs the real harvest against npm and GitHub — thousands of live
requests and several minutes. The tests cover every policy decision without a
network, so reach for it only when you have changed the fetching or writing layer.
Status and open work: docs/plans/2026-08-18-remaining-work.md.
Specification: docs/design/2026-08-18-dsh-plugin-shop-design.md.
🤝 Contributing
Three ways in, cheapest first.
- Correct a verdict. Categories and competing-market judgements are made by a
classifier, and the build report
names every call it made with no human behind it. Fixing one is a single line of
YAML — no network, no TypeScript, no local build.
- Get a plugin listed. Add a harvest keyword and publish. If the shelf still
does not show it, that same report says why, per package, in terms written for
the author.
- Change the pipeline.
docs/design/ is the specification and
the authority; CLAUDE.md is the working agreement.
All three in full: CONTRIBUTING.md. Be decent to each other:
Code of Conduct. Vulnerabilities and malicious plugins go
privately, never to a public issue.
📄 License
Apache-2.0 © LivXue
It's a browsable, git-auditable plugin marketplace for DeepSeek Harness (dsh) — a catalog you use to discover, install, enable and update dsh plugins.