Awesome DSH Plugins

Discover installable DeepSeek Harness plugins, inspect the evidence behind each listing, and explore the 2Origin plugin lab.

中文 · Official DeepSeek Harness · Browse verified bundles · Search from the terminal · 2Origin plugin lab

Start here

Normal CLI searches use the committed snapshot and need no GitHub token:

npx github:dongsheng123132/awesome-dsh-plugins search memory

This repository deliberately distinguishes a repository that mentions DSH from an installable DSH profile bundle. A plugin receives the Verified Bundle mark only when the scanner finds both:

1. a package.json declaration at dsh.bundle.patch; and
2. the declared patch file in the same Git tree.

This is structural verification, not a security audit or a promise that the plugin works with today's DSH main branch. Categories are heuristic navigation aids; manifest and patch evidence, not the category label, determines verification.

Radar

1098 verified bundles / 1003 topic repositories examined / 11490 reported by GitHub

Other: 329 · UI / TUI: 225 · Token & Cost: 68 · Browser: 67 · MCP Bridge: 63 · Security: 61 · Memory: 55 · Model & Routing: 54 · Coding: 34 · Office: 32 · Developer Tools: 28 · Finance: 28 · Long-running: 22 · Writing / Novel: 19 · Research: 12 · Provenance & Lineage: 1

The homepage shows the top 30 repositories once each; multi-bundle repositories and all records remain in data/plugins.json. Snapshot: 2026-08-25T08:59:38.471Z.

The full machine-readable records live in data/plugins.json. Topic-tagged repositories that do not yet pass bundle verification remain visible in data/candidates.json; they are never silently presented as installable plugins.

Capability Port Score

This second radar finds public SKILL.md candidates from Claude, Codex, shared .agents, OpenClaw, and SkillHub-oriented searches. It does not copy or republish their instructions. Each record pins the repository commit, file path, Git blob, content SHA-256, observed license source, and line-level adaptation signals before assigning one evidence-backed path:

• copy: self-contained instructions with no observed runtime, bundled-resource, executable, or permission dependency;
• wrapper: instructions that need a command, bundled resource, network, secret, write, or shell adapter;
• a skill index that refers to relative skills/<name>/SKILL.md files is a wrapper, because copying only the entry file omits required instructions;
• bridge: a harness hook, plugin protocol, or runtime-specific configuration must be translated;
• unclassified: required identity evidence is missing.

The scheduled scan keeps the last committed snapshot when GitHub search finds no hits or fewer than half of the pinned files can be inspected (for example, during API rate limiting). A failed scan is not interpreted as zero available capabilities.

49 revision-pinned candidates: Copy 15 · Wrapper 30 · Bridge 2 · Unclassified 2

Full records, score components, and line-level signals live in data/capabilities.json. Snapshot: 2026-08-13T22:47:12.754Z. The score measures only observed adaptation effort; it is not compatibility, safety, quality, or license clearance.

Search from the terminal

npx github:dongsheng123132/awesome-dsh-plugins search memory
npx github:dongsheng123132/awesome-dsh-plugins trending
npx github:dongsheng123132/awesome-dsh-plugins verified
npx github:dongsheng123132/awesome-dsh-plugins experimental
npx github:dongsheng123132/awesome-dsh-plugins runtime skillport
npx github:dongsheng123132/awesome-dsh-plugins risk process-execution
npx github:dongsheng123132/awesome-dsh-plugins ports cad

The CLI reads the committed snapshot, so normal searches do not require a GitHub token.

Static review signals

The radar also reads each verified bundle's patch and runtime dependencies, flagging review signals for secret-bearing configuration, process execution, filesystem access, network/browser access, MCP external tooling, and Web client extensions. In the first pass, 163 of 488 bundles matched at least one signal. Each signal retains patch or dependencies as its evidence source and exists only to prioritize human review; it is not a vulnerability finding or security certification. Full records live in data/plugins.json, and risk [signal] exposes them from the CLI.

Runtime compatibility layer

Verified Bundle proves only that a repository has both a dsh.bundle.patch declaration and the referenced patch file. Runtime evidence is deliberately separate in data/runtime-compat.json: each report pins the exact DSH commit and Node runtime, installs into a fresh temporary profile, composes the patch stack, then boots the real Web profile until DSH prints its readiness URL.

The first audit already demonstrates why the split matters. @dsh-skillport/bundle was not available from npm at audit time, so the documented registry install failed. The same source commit, after a local build, installed, composed, and reached a real DSH Web readiness URL on Node 24.19.0 against a previously built DSH 47f943859bef checkout. A clean detached DSH checkout installed and composed the plugin but was blocked by missing DSH Web client bundles; rebuilding that checkout then failed earlier in DSH's own build (tsdown could not import unrun). The evidence therefore supports compatibility with the built checkout, not yet a clean-source reproducibility claim. A Node 22.14 attempt is separately retained as blocked-environment because it does not satisfy DSH's declared engine floor.

The next layer is machine-scheduled: data/runtime-targets.json pins three DSH baselines (the pre-0.1.1 anchor, official dsh-v0.1.1-rc.2, and official dsh-v0.2.1-alpha.1) and immutable plugin commits. The runtime compatibility matrix boots every stock baseline on Ubuntu and Windows, then runs only the targets explicitly scoped to that baseline in a fresh DSH_HOME. Four observed community plugins and the original required 2Origin positive control stay on the two older baselines; a separate required 2Origin support-lifecycle control covers the new alpha. See the alpha evidence and limits. Baseline IDs, revisions, report paths, cache keys and artifact names remain distinct, so upgrade evidence cannot overwrite the anchor. Each pinned DSH commit governs its own lifecycle scripts with strictDepBuilds and reviewed allowBuilds; plugin lifecycle builds are allowed only for the target's one named package. Reports resolve the installed entrypoint, distinguishing package-artifact-missing from boot failure, and upload create-only content-addressed evidence after removing credential-shaped and CI-control environment variables. A valid negative observe report does not make the instrument red; a required target must pass, and missing or malformed evidence always fails. Passing proves only the named tuple, not safety or general compatibility.

Run a reproducible check:

node scripts/runtime-verify.mjs --spec <package-or-built-checkout> \
  --dsh-repo /path/to/deepseek-harness \
  --node /path/to/node-24 \
  --record data/runtime-compat.json

2Origin plugin lab

Lab status is evidence-gated:

• planned: problem and acceptance target exist, but there is no runnable repository.
• experimental: a runnable repository exists; compatibility is not yet demonstrated.
• verified: installation and a declared smoke test were observed against a named DSH revision.
• deprecated: the experiment is no longer maintained.

Plugin runtime code stays in separate repositories. This repository owns discovery, evidence, comparison, and experiment status—not a monolithic plugin implementation.

Automation

Every four hours, the scheduled workflow scans the public dsh-plugin topic, inspects package manifests, patch paths, and static review signals, regenerates the radar, runs checks, and opens or updates a reviewable pull request. Expensive runtime verification is triggered only for high-value candidates or changed revisions rather than blindly rerunning the entire matrix every four hours. It does not auto-merge ecosystem claims into main.

Local update:

GITHUB_TOKEN=github_token npm run update-radar

Anonymous API access also works for small scans:

npm run discover -- --limit 25

Contributing

See CONTRIBUTING.md. Adding the dsh-plugin topic helps discovery, but verification still depends on the bundle manifest and patch file.

Disclaimer

This is an independent community project and is not an official DeepSeek endorsement. Installing a third-party plugin executes code and may change the agent's tools, prompts, permissions, UI, or data access. Review source, dependencies, license, permissions, and maintenance state before installation.

MIT © 2026 hfshfg