Plugin Market

Plugin Market adds a Market page to DeepSeek Harness: it discovers DSH plugins from the
npm registry and GitHub, shows what each one does, screenshots where the author provides
them, and reviews a plugin with a model before anything is installed.

Open it from either entry:

• the Plugin Market icon in the sidebar (next to the shipped Plugins button)
• Settings → Built-in plugins → Market tab

Once a plugin is installed, the shipped Plugins page owns it — enabling, configuring and
removing all happen there, and the Market links you straight to it.

Install

From DSH itself. Open Plugins → Add plugin, enter the package name, and approve it:

dsh-plugin-market

Or point straight at the repository, which works before any npm release:

github:OWNER/dsh-plugin-market

Manually, by adding two entries to your profile's package.json:

{
"dsh": { "profile": { "bundles": ["…", "dsh-plugin-market"] } },
"dependencies": { "dsh-plugin-market": "link:/path/to/dsh-plugin-market" }
}

then reinstall the profile's dependencies and restart DSH.

The host half is loaded at startup, so a restart is required; the browser half reloads on
its own while DSH is running.

For plugin authors

You do not have to do anything for your plugin to appear in the Market. It is discovered
from the dsh-plugin keyword on npm and from GitHub, and the Market falls back to your
README.md for screenshots and to your package.json for the name and description.

Everything below is optional. It is how you make your listing accurate — the correct
logo, a description that says what the plugin actually does, and screenshots of the real UI.

Create one folder: dsh-market/

Put everything the Market shows into a single folder at the root of your repository:

your-plugin/
├─ package.json          ← point "icon" at the logo inside the folder
├─ README.md
└─ dsh-market/
├─ market.json        ← the description, developer and screenshot list
├─ logo.svg           ← your logo
└─ screenshots/
├─ dashboard.png
└─ settings.png

One folder keeps your repository root clean, and deleting it removes your listing metadata
in one step. A root-level dsh-market.json also still works if you prefer a single file;
if both exist, dsh-market/market.json wins.

Where each thing goes

Three things describe your plugin, and each is declared in a different place. This table is
the whole convention; the sections below give the rules for each one.

A worked example: this plugin's own folder

This repository is listed in the Market by the same convention it documents. Its own
dsh-market/ folder is the reference — copy its shape:

dsh-plugin-market/
├─ package.json                  "icon": "./dsh-market/logo.svg"
└─ dsh-market/
├─ market.json                displayName, developer, logo, summary, description,
│                             screenshots[] with per-language captions, license
├─ logo.svg                   the logo, referenced by package.json `icon`
└─ screenshots/
├─ market-list.png
├─ market-detail.png
└─ risk-review.png

Nothing outside this folder is needed for the listing, and deleting the folder removes the
whole thing without touching the plugin.

Relative paths: two rules, and they differ

This is the one thing that trips people up, so it is worth reading twice. A path in
package.json is resolved as a file inside your package; a path in market.json is
resolved as a file in your repository. The same logo therefore needs two spellings:

A descriptor path may also be a full https:// URL on an allowed host (raw.githubusercontent.com,
user-images.githubusercontent.com, objects.githubusercontent.com, avatars.githubusercontent.com);
any other host is refused, because rendering it would reveal every reader's IP address to that
server. Package-relative paths such as ./dsh-market/logo.svg do not work as repository
paths — the leading ./ is stripped, so the resulting URL 404s and the logo silently falls
back to the letter tile.

1. The logo

The logo is declared through icon, the standard manifest field. The shipped Plugins page
reads it too, so one declaration serves both surfaces:

{
"icon": "./dsh-market/logo.svg"
}

If you would rather keep the manifest untouched, put "logo": "dsh-market/logo.svg" in
market.json instead. It overrides icon for the Market only — the shipped Plugins page
still reads icon, so with that arrangement the two pages can show different logos.

The shipped icons are solid filled paths with a userSpaceOnUse linear gradient, and the
glyph fills roughly 50–58% of the canvas. An outline drawing with a thin stroke looks
visibly lighter than everything around it. If you want yours to sit naturally in the list,
copy one of the icons out of the DSH installation and match its construction.

2. dsh-market/market.json

Every field is optional, and every text field accepts either a plain string or a
per-language object ({"zh": "…", "en": "…"}). Omitted fields fall back to your
package.json and README.md.

{
"schemaVersion": 1,
"displayName": { "zh": "上下文面板", "en": "Context Panel" },
"developer": { "name": "Your Name", "url": "https://github.com/you" },
"summary": {
"zh": "在会话里查看上下文占用与工具调用细节。",
"en": "Inspect context usage and tool-call detail inside a session."
},
"description": {
"zh": "较长的一段介绍，显示在详情页的正文位置。",
"en": "The longer introduction, shown as the detail page body."
},
"homepage": "https://example.com",
"license": "MIT",
"screenshots": [
{ "url": "dsh-market/screenshots/dashboard.png", "caption": { "zh": "主面板", "en": "Dashboard" } },
{ "url": "dsh-market/screenshots/settings.png", "caption": { "zh": "设置页", "en": "Settings" } }
]
}

3. Screenshots

Point url at a file in your repository. A path relative to the repository root is easiest,
and note the spelling: no leading ./, because the path is appended to the repository's raw
URL rather than resolved against your package:

"screenshots": [
{ "url": "dsh-market/screenshots/dashboard.png", "caption": { "zh": "主面板", "en": "Dashboard" } },
{ "url": "dsh-market/screenshots/settings.png",  "caption": { "zh": "设置页", "en": "Settings" } }
]

Listed screenshots win over anything found in your README, and they keep the order you give
them. A caption is optional but worth adding: it is shown under the image and in the
full-screen viewer, and it is the only text a reader sees next to the picture.

If you ship no descriptor at all, the Market reads the images you already embedded in
your README.md, in markdown or HTML form, and uses those. Keeping the best screenshots
near the top of the README helps, because earlier images rank higher.

What the Market checks before showing an image:

In the README path an .svg is only considered when its file name or alt text names a UI
surface (preview-en.svg yes, logo-en.svg and architecture.svg no), because a vector
next to a README is usually a logo or a diagram.

Screenshots open in a full-screen viewer: click one to enlarge, and again to switch between
fit-to-window and actual size.

4. Language

Write your summary and description in the language you are comfortable with. When the
reader's language differs, the Market translates it once with a model and caches the result,
keyed by the text — so editing your description is what triggers a new translation, and
nothing else does. The translated line is always labelled as machine-translated, and your
original stays available in the tooltip.

You can supply the translation yourself instead, per field, which always wins:

"summary": { "zh": "……", "en": "……" }

Your README.md is shown as written and is never machine-translated.

Configuration

Privacy and safety

• Every request is authenticated. The page reaches the plugin through an exact route on
  the /api channel, which the connection layer wraps in its Host/Origin fence and
  browser-cookie authentication. An unauthenticated request is answered 401.
• Images are loaded from the code host only, so viewing a listing does not announce the
  reader to a third party. Images are rendered with referrerPolicy="no-referrer".
• Nothing installs without a review. Clicking install runs a deterministic rule scan
  plus a model review over the plugin's manifest and entry code, shows the findings, and
  requires an explicit confirmation. The confirmation is a single-use ticket issued by the
  review, so the check cannot be skipped by calling the route directly.
• Third-party code is treated as untrusted data. A review never follows instructions
  found inside a plugin's source, and a plugin claiming to be safe does not lower its own
  result.
• Build scripts are never auto-approved. When pnpm blocks postinstall and friends, the
  names are shown and you approve them explicitly or not at all.
• Translations are cached locally and never sent anywhere except the configured model.

Licence

MIT.