dsh-plugin-shop

📦 Install the shop

Install the shop manually, or have an agent follow the automated steps below.

🧑 Manual installation

Prerequisite: Node.js. You can run DeepSeek Harness without a global installation
using the command in its official documentation: npx -y @deepseek-ai/dsh web.
Plugin management uses dsh plugin, which invokes both dsh and pnpm.
Install these tools with npm install -g @deepseek-ai/dsh pnpm, then check that both
are available with dsh --version and pnpm --version.

# 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.6
# Alternatively, run the installation command through npx:
npx -y @deepseek-ai/dsh plugin --profile web add dsh-plugin-shop@0.8.6

Replace web with your profile name if you use a different one. Restart dsh after
installation to load the new plugin, then open:

Settings → Built-in plugins → Plugin shop (the section is called Plugins on dsh 0.1.5)

🤖 Installation with an agent

An agent can run these steps without interaction. The --profile option is required.
If it is omitted, dsh plugin exits with this error:
error: required option '--profile <name>' not specified.

# 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.6

# 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>

You can also verify step 3 by checking that dsh.profile.bundles in
$DSH_HOME/profiles/<profile>/package.json includes the plugin. For troubleshooting,
see the package README.

🖼️ Screenshots

Confirmation is required before installing an unreviewed plugin	The plugin shop in dark mode

✨ Highlights

• 🌐 Automatic discovery — the catalog collects npm packages with the
  dsh-plugin or deepseek-harness keyword and GitHub repositories with either
  topic. Authors do not need to submit an application or join a queue.
• 🧹 Strict screening — every candidate is checked automatically on each build.
  Rejected plugins are recorded by name with one of seventeen predefined reasons
  and a detailed explanation to help authors troubleshoot. The plugins and
  filtered badges above show the current totals.
• 🔌 Local dependency checks — the shop checks each peer dependency a plugin
  requires against your profile and the modules dsh's web client provides. When the
  author declares which dsh versions or profiles a plugin supports, the shop also
  compares them with what you run. A card shows Incompatible only when a
  dependency is missing from your environment or the author's declared support
  does not cover it.
• 🗓️ Daily updates — the catalog is rebuilt daily, with changes committed to
  Git for review. Eligible new plugins are listed the next morning, and plugins
  whose repositories are no longer available are removed during the same process.
• 🗂️ Seven categories — authors can choose a category through dsh.catalog.
  Otherwise, the build assigns one automatically.

🗺️ How it works

The catalog is built daily in this repository. The build code lives in registry/.

flowchart TB
  subgraph HARVEST["1 · Discover — collect plugins from public sources daily"]
    direction LR
    NPM(["npm packages<br/>keyword dsh-plugin<br/>keyword deepseek-harness"])
    GH(["GitHub repositories<br/>with the same keywords<br/>as topics"])
  end

  subgraph GATE["2 · Screen — check every candidate on each build"]
    direction LR
    G1["Is it a loadable plugin?<br/><br/>Has a valid<br/>dsh.bundle"]
    G2["Can it be reviewed?<br/><br/>Has a license and<br/>an accessible source repository"]
    G3["Can it be installed?<br/><br/>Not deprecated on npm;<br/>repository listings also require<br/>no build scripts or<br/>workspace: dependencies"]
    G4["Is the package information credible?<br/><br/>Check integrity, publication time,<br/>and potentially misleading names"]
    G5["Is there information to display?<br/><br/>Has a valid dsh.catalog<br/>or an npm description"]
  end

  subgraph SHELVE["3 · List — record plugin details"]
    direction LR
    CAT["One of seven categories"]
    PEER["Required peer dependency names,<br/>without version ranges"]
  end

  NPM --> G1
  GH --> G1
  G1 -.-> REJ
  G2 -.-> REJ
  G3 -.-> REJ
  G4 -.-> REJ
  G5 -.-> REJ
  REJ[["Rejected — record the plugin name and explain why"]]
  G5 ==>|"All five checks pass"| CAT
  PEER ==> PUB[["4 · Publish — name JSON files by content hash, commit to Git, and publish to GitHub Pages and npm"]]

The shop runs locally as an npm package. Its code lives in packages/dsh-plugin-shop/.
The catalog build and the local shop share a data schema; their code is independent.

flowchart LR
  CAT[["Plugin catalog<br/>index.json + plugins.sha256.json"]]
  CAT ==> HOST["5 · Host<br/>Request multiple sources concurrently<br/>Verify sha256 and cache the result"]
  HOST ==> DEP{"6 · Check dependencies<br/>Look for each peer dependency<br/>in your profile or web client"}
  DEP -->|"Missing dependencies"| BAD["Incompatible<br/>The card lists<br/>missing dependencies"]
  DEP -->|"All dependencies found"| GOOD["Ready to install"]
  BAD --> CLIENT["Client — the plugin shop in Settings<br/>Calls nine shop/* methods on the host<br/>No network or filesystem access"]
  GOOD --> CLIENT
  CLIENT ==>|"dsh plugin add"| PROF[("your dsh profile")]

Two details are useful to understand:

• Every rejected plugin is documented. The build report records its name and
  explains which check it failed, so authors can investigate.
• Compatibility depends on your local environment. The catalog records the
  names of the peer dependencies a plugin requires, without version ranges.
  Nearly all dsh plugins declare "*", but the harness's prereleases do not
  satisfy ordinary version ranges. Checking those ranges would incorrectly mark
  working plugins as incompatible. Instead, the shop checks whether each
  dependency is available in your profile or provided by dsh's web client.

✅ Project principles

🚫 Permissions and limitations

The shop does not provide sandbox isolation. Once loaded, a dsh plugin has
access to the full ctx, including your filesystem, shell, and requests sent to
the model. Installing a plugin means trusting it with these permissions. The shop
explains them before installation, but does not restrict what a running plugin can do.

The shop does not display download counts, ratings, or reviews, and it will not offer
installation from arbitrary URLs. For that, use dsh plugin add and decide whether to
allow build scripts or pin a specific commit.

📚 Plugin catalog

The catalog is built daily and published as static JSON through the
dsh-plugin-shop-catalog npm package and GitHub Pages. The shop requests it from
multiple sources: your configured npm registry, npmmirror, npmjs, and GitHub Pages.
It uses the first valid response to avoid delays from a slow connection to any one
source. Each source serves identical data, which is checked against the sha256 hash
in the index before use. Set DSH_SHOP_CATALOG_URL to use only a specific source.

Each workflow run includes a rejection report listing every rejected plugin and the
reason it was excluded, with details to help authors troubleshoot.

When catalog content changes, the data filenames change with their content hashes,
and the old files are removed. However, index.json is cached for ten minutes, so it
may temporarily reference files that no longer exist. If you fetch data directly
from /v1/ and a data URL returns 404, fetch index.json again. Alternatively, read
the same data from the dsh-plugin-shop-catalog npm package, which always bundles
the index with its matching data files.

🏷️ Listing a plugin

Add dsh-plugin or deepseek-harness to the keywords in your package.json and
publish to npm. The daily build will discover your plugin and list it once it passes
the checks. If you do not publish to npm, your plugin can be listed from its GitHub
repository: add either keyword as a repository topic and include name and
dsh.bundle in the root package.json. The catalog pins a specific commit from the
default branch as the plugin's version.

The optional dsh.catalog section lets you specify the category, summary, and
capabilities. Without it, the catalog generates a listing from your npm description.

{
  "name": "dsh-hello-plugin",
  "keywords": ["dsh-plugin"],
  "dsh": {
    "bundle":  { "patch": "./cordis.patch.yml" },
    "catalog": {
      "category": "tool",
      "summary": { "en": "...", "zh": "..." },
      "capabilities": ["fs", "shell"]
    }
  }
}

See docs/schema.md for the full field reference.

Common reasons for exclusion:

• No dsh.bundle, so the package cannot be installed as a plugin.
• No license or source repository, so the package cannot be reviewed.
• Neither dsh.catalog nor an npm description, leaving no plugin information to display.

🌾 Which packages are discovered?

Discovery matches dsh-plugin and deepseek-harness in npm keywords or GitHub
repository topics, regardless of the package name. The cordis-plugin keyword
identifies the underlying framework, but does not establish that a package can be
installed as a DSH plugin. Built-in plugins distributed with dsh declare no npm
keywords, so this discovery process does not find them.

If your community plugin uses Cordis and integrates with DSH, add either keyword
and declare dsh.bundle in the appropriate manifest:

• For npm packages: use the package.json of the package you publish.
• For GitHub repositories: use the root package.json, which must also declare
  a name. In a monorepo, you can instead declare the bundle in the subpackage that
  provides the plugin.

A general-purpose Cordis library without dsh.bundle cannot be installed as a DSH plugin.

🗂️ Repository layout

🛠️ Development

pnpm install
pnpm test        # vitest
pnpm typecheck

pnpm build:catalog collects live data from npm and GitHub, making thousands of
network requests and taking several minutes. All policy decisions are covered by
offline tests. Run the full build when you change data fetching or file output and
need to verify the complete workflow.

Project status and remaining work: docs/plans/2026-08-18-remaining-work.md.
Design specification: docs/design/2026-08-18-dsh-plugin-shop-design.md.

🤝 Contributing

Contributions are welcome. Here are three ways to help, starting with a small correction:

• Correct a classification. A classifier assigns categories and determines
  whether a plugin is another plugin marketplace. The
  build report lists every
  decision that has not been reviewed by a human. Correcting one takes a single
  line of YAML, with no network access, TypeScript changes, or local build required.
• Publish your plugin. Add a discovery keyword and publish. If the plugin does
  not appear in the shop, check the same build report for an explanation.
• Improve the pipeline. Follow the specifications in docs/design/
  and the development conventions in CLAUDE.md.

See the contribution guide for detailed instructions, and follow
the Code of Conduct when taking part in discussions. Report
vulnerabilities or malicious plugins privately through the
security reporting process, not in a public issue.

📄 License

Apache-2.0 © LivXue