How to find a DSH plugin: Hub vs CLI vs GitHub

Finding DeepSeek Harness plugins uses three sources that are not alternatives but three stages: the marketplace discovers, the CLI confirms, GitHub verifies. Using only one leaves a specific blind spot: the marketplace alone yields entries with incomplete metadata, GitHub alone gives you code without an installable package name, and the CLI alone cannot tell you what to look for. So fix the order — shortlist in the marketplace, confirm names and versions with the CLI, verify maintenance and dependencies on GitHub. The whole pass usually takes minutes.

What each DeepSeek Harness plugin source can and cannot show

Bottom line: the marketplace shows categories and popularity, the CLI shows package names and versions, GitHub shows source and activity. Their information barely overlaps, so skipping one blinds you.

Option A: marketplace first (when you do not know what you need)

Bottom line: when the requirement is vague, start from categories. It is the fastest way to turn a fuzzy need into concrete candidates.

1. State the scenario before browsing, then navigate by category rather than starting from the overall ranking.
2. Check the listing against your need: what it solves, what it depends on, how it installs. All three must pass.
3. Write a short shortlist: name, one-line purpose, dependency.
4. Move to the three-stage workflow for confirmation.
5. Judge by fit over popularity — see reading DSH Plugin Hub rankings.

Option B: command line first (when you already have a package name)

Bottom line: the CLI is for confirmation, not discovery. Package name, versions and dependencies in one pass prevents installing the wrong thing.

1. Confirm the package and versions using npm's metadata query:

npm view <plugin-package> versions --json
# expected: a version list confirming the version you want exists

2. Check dependencies with npm view <plugin-package> dependencies, looking for native modules that need compiling (important on ARM and in containers).
3. Install and verify immediately:

dsh plugin add <plugin-package>@<version>
dsh plugin        # expected: the plugin appears at the specified version

4. Record the version for rollback and multi-machine alignment (see pinning DSH plugin versions).

Option C: GitHub first (when you need source and activity)

Bottom line: when deciding whether to rely on a plugin long-term, check GitHub. Commits, issues and release cadence answer whether it is alive and whether it might break suddenly.

1. Check commit and release cadence and whether it tracks recent DeepSeek Harness changes.
2. Read issues: long-unaddressed critical problems, or discussions matching your scenario.
3. Read the README for dependencies and permissions — the main basis for what you must prepare before installing.
4. Return to the CLI to confirm an installable form — repository code is not necessarily a published package.
5. Judge by maintenance over stars — stars record past attention, commits record present state.

Three-stage workflow for finding DeepSeek Harness plugins

Bottom line: marketplace shortlist, CLI confirm, GitHub verify. Fixed order, and it covers all three blind spots.

1. Stage one (discover): find two or three candidates by category and record names and purposes.
2. Stage two (confirm): verify package names, versions and dependencies with the CLI, eliminating nonexistent versions and unmet dependencies.
3. Stage three (verify): check maintenance state and known issues on GitHub, then decide which to try.
4. Install one at a time when trying alternatives, so conflicts do not blur responsibility (see DSH plugin conflicts).
5. Record the outcome: package name, version and source in your plugin manifest.

Blind spots and traps for each DeepSeek Harness plugin source

Bottom line: the marketplace trap is publisher-supplied metadata, the CLI trap is not knowing what to search for, and the GitHub trap is code without a package.

1. Marketplace blind spot: metadata comes from publishers, so missing dependency notes surface only at install time. Always read dependencies first.
2. CLI blind spot: no discovery; if you lack a package name, the CLI cannot help.
3. GitHub blind spot: a repository may hold several packages or none published to a public registry, producing "I can see it but cannot install it."
4. Shared blind spot: none of the three knows whether your environment satisfies the plugin (native modules, permissions, CLI version). Only post-install verification answers that.
5. Supplementary channels: community discussions surface leads, but quality varies; use them to discover, then confirm and verify as above.

DSH plugin troubleshooting when searching

Bottom line: search failures are usually "wrong channel," not "nonexistent plugin." Change the channel before changing keywords.

1. Not in the marketplace — try other keywords, search GitHub topics, or check whether the CLI already provides the capability.
2. Found on GitHub but cannot install — confirm the package name and version published to a registry.
3. Installed but disappointing — move to post-install verification and conflict diagnosis instead of hunting for a better plugin.
4. Constantly swapping plugins — write the scenario sentence and search from it rather than trial and error.
5. Team workflow — record the result in the manifest: who provides it, which version, why chosen. More valuable than a bare package name.
6. Repair status, stated honestly: channel capabilities here follow DSH Plugin Hub's public pages and the official repository's publishing conventions. Actual sorts and filters change with the page, and dsh plugin subcommand syntax should be confirmed with --help.

If you only need to know where to download from, see plugin download channels: market, GitHub and npm.

Sources: DSH Plugin Hub listing, apps/cli/README.md, docs/user/develop/basic/publish.md.