Stop Hunting for Plugins on GitHub—I Built Plugin Discovery Directly into DeepSeek Harness

zhaojun chu — Sat, 29 Aug 2026 05:35:27 +0000

Here is the entire pitch: install one npm package, and DeepSeek Harness gets a native plugin marketplace, transparent rankings, and two Agent tools that can search the catalog from a conversation.

No tab hopping. No guessing package names. No stitching together a recommendation from five half-read READMEs.

dsh plugin --profile web add @czj-git/dsh-plugin-hub

This is not an iframe, and it is not the DSH Plugin Hub website squeezed into a WebView. The plugin reads the same public, read-only catalog API and reshapes it for two places where plugin discovery is actually useful: DeepSeek Harness Settings and the Agent itself.

The website answers “What plugins exist?” The plugin answers “Why should I leave Harness to find them?”

The native Plugin Hub in dark mode. Counts, rankings, and public metrics reflect the moment each screenshot was captured; the live catalog keeps changing.

Search was never the slow part. Switching was.

Adding a capability to an Agent usually starts with a simple need:

I need long-term memory.

I want a text-only model to understand screenshots.

I need a panel that shows context usage.

Then the detour begins.

Leave Harness. Open a browser. Search GitHub. Read several READMEs. Compare repositories. Confirm the package source. Copy an install command. Return to Harness.

Every step is defensible. The sequence is ridiculous.

A tool that can only be discovered outside the workspace has not truly joined the workflow. That is why the DSH Plugin Hub plugin has two entrances: one designed for people, and one designed for Agents.

The first entrance: a marketplace inside Settings

Install the package, restart the Web profile, and open Settings → Plugin Hub. The page contains two focused tabs: Plugin marketplace and Rankings.

The marketplace is not an endless wall of repository names. Each card puts the information needed for a first decision in one place:

plugin name, author, and localized description;
category, primary language, and installation source;
GitHub Stars, catalog views, and verification status;
a copyable install command and a link to the source.

Search works across plugin names, authors, and feature descriptions. Category filters narrow the result without hiding the rest of the catalog. The page follows the current Harness language, so descriptions, detail links, and dates switch together between English and Chinese.

One boundary is intentionally visible: “Copy command” never quietly becomes “Install.” The marketplace gives you the public command. Execution still belongs to Harness permissions, approvals, and your own judgment.

The second entrance: skip the marketplace and ask the Agent

Sometimes browsing is already too much interface.

You can ask in plain language:

Use DSH Plugin Hub to find plugins related to memory.
Return at most five, explain what each one is for,
and include the install command and detail link. Do not install anything.

The plugin exposes two tools:

dsh_plugin_search searches by need, feature, plugin name, author, or repository;
dsh_plugin_rankings returns daily growth, top Stars, newly listed, or recently active results.

The Agent does not receive a scraped blob of webpage text. It receives validated fields for runtime type, category, installation source, compatibility, public metrics, timestamps, and links. It can filter those results, compare them, and explain them in the language of the current task.

The Agent can query the catalog, explain the results, and include source and installation links without executing an install.

That is the meaningful shift. Before, you had to know what a plugin was called. Now you can start with the problem you want to solve.

Rankings without a mystery score

I do not want Stars, growth, activity, and listing date blended into one impressive-looking number that nobody can explain.

The plugin and website keep four signals separate:

Daily growth — the GitHub Star change between the latest two successful metric snapshots;
Top Stars — long-term public interest, shown without pretending it measures quality;
Newly listed — projects that have just entered the catalog get a visible path in;
Recently active — ordered by the latest GitHub push time.

Every ranking states its signal. When no historical baseline exists, the UI reports that the value is pending instead of disguising “unknown” as zero.

A mature, stable plugin and a new plugin gaining attention are interesting for different reasons. Flattening them into one score removes information; it does not create insight.

Under the plugin is a living public catalog

The native experience is not backed by a private second dataset. Its source is dshpluginhub.dev:

the plugin marketplace is built for browsing, filtering, and comparison;
detail pages collect installation sources, compatibility information, README content, public metrics, and repository links;
rankings expose the same four explainable signals;
the public search API lets clients, Agents, and third-party tools reuse the catalog.

The division of labor is deliberately simple:

The website aggregates and explains. The plugin brings the result back into the workflow.

The Settings client does not call the cross-origin public API directly. The plugin Host registers a read-only same-origin route and reuses the same API client and response validation as the Agent tools. Settings and chat therefore read the same public catalog instead of drifting into two implementations.

What it deliberately refuses to do

Plugin marketplaces are easy to oversell, so the exclusions matter:

no additional DSH Plugin Hub API key is required;
it does not read Harness identity, saved plugins, or private user data;
it exposes no install, uninstall, or profile-writing endpoint;
a GitHub topic is not treated as official certification;
catalog verification is not a security endorsement;
rankings never replace reviewing third-party source code, permissions, and configuration.

The plugin shortens the distance to discovery and understanding. It does not shorten the distance to responsible judgment.

Why make the catalog itself a plugin?

DeepSeek Harness is built around a simple premise: everything is a plugin.

The interesting consequence is not merely that people can add more capabilities. The ecosystem can begin to describe and navigate itself.

A plugin can help you discover the next plugin.

It sounds recursive. In practice, it is what an extensible system eventually needs. Once capabilities can be added, the next problem is unavoidable: how are those capabilities found, understood, compared, and brought into real work?

The website handles discovery. The API handles reuse. The native plugin removes the context switch. Drop any one of the three and the experience breaks at a different point.

Try it

Install the package:

dsh plugin --profile web add @czj-git/dsh-plugin-hub

Restart the Web profile and open Settings → Plugin Hub, or start a conversation and ask the Agent to use dsh_plugin_search.

npm: @czj-git/dsh-plugin-hub
GitHub: czj-git/dsh-plugin-hub
Website: dshpluginhub.dev
Marketplace: dshpluginhub.dev/en/plugins
Rankings: dshpluginhub.dev/en/rankings
Public API: dshpluginhub.dev/en/api

If there is one idea worth keeping, it is this:

The goal of a tool is not to give you another destination to remember. It is to make the destination disappear into the workflow.

DSH Plugin Hub is an independent community project for DeepSeek Harness. It is not affiliated with or endorsed by DeepSeek. The website and plugin organize public information and catalog checks; they do not endorse third-party code, permissions, or behavior. Review source code and configuration before installation.

DEV Community: zhaojun chu