awesome-dsh-plugins

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/the community catalogs 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 . Snapshot: 2026-08-25T08:59:38.471Z.

The full machine-readable records live in . Topic-tagged repositories that do not yet pass bundle verification remain visible in ; 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 . 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/the community catalogs search memory
npx github:dongsheng123132/the community catalogs trending
npx github:dongsheng123132/the community catalogs verified
npx github:dongsheng123132/the community catalogs experimental
npx github:dongsheng123132/the community catalogs runtime skillport
npx github:dongsheng123132/the community catalogs risk process-execution
npx github:dongsheng123132/the community catalogs 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 , 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 : 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: 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. 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 . 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

…