Preface¶
DeepSeek Harness (hereinafter referred to as dsh) has embedded “everything is a plugin” into its architecture: interfaces, tools, and skills can all be installed externally. The official repository deepseek-ai/deepseek-harness also recommends that plugin authors add the GitHub topic dsh-plugin to their repositories for easier discovery. The problem is that the number of repositories under this topic will grow, and individual accounts and organizations will transfer between each other. Manually browsing search results or only following a specific organization makes it easy to miss available plugins, and it is difficult to distinguish whether they should be installed as a bundle, Cordis plugin, or skill.
What’s more troublesome is the installation itself. Plugins run in the current dsh process, and installing them means handing over the session, tools, and local command permissions to them. The community directory site deepseek-harness-plugin.com is an independent indexing site and has no official affiliation with DeepSeek / HyperMind. The installation commands on the page cannot replace reviewing the source code yourself.
dsh-find-plugins maintained by Nagi-ovo was created for this purpose: describe your needs in natural language in the agent conversation, it will search for candidates across all GitHub repositories tagged with the dsh-plugin topic, explain the differences, wait for you to select one, then conduct a permission review before installing and verifying whether the plugin has been successfully mounted. This article is collated after cross-checking the directory details page, GitHub repository README, skills/find-plugins/SKILL.md, and the official deepseek-harness repository.
What is this¶
dsh-find-plugins is a skill plugin hosted at Nagi-ovo/dsh-find-plugins, maintained by Nagi-ovo, and licensed under BSD-3-Clause. The community directory categorizes it under the “Skills” section. As of 2026-08-17, both GitHub and the directory page have 130 stars. The primary language of the repository is JavaScript, it was created on 2026-08-13, and it was added to the directory on 2026-08-15.
It does not solve the problem of “writing a new plugin”, but addresses these issues:
- Find public candidates from all GitHub repositories tagged with dsh-plugin based on natural language requirements
- Compare README, package.json, and repository files to determine whether they should be installed as a bundle, Cordis plugin, or skill
- Report the permissions required by the plugin to the user before they take any action after selection
- Verify whether the plugin has been successfully mounted after installation
The skill entry file is skills/find-plugins/SKILL.md, and the skill name is find-plugins. SKILL.md clearly states that it only handles searching and installation; to develop a new plugin, you should go to make-dsh-plugin instead.
Core Features¶
Treat the topic as the directory, not a specific organization¶
The skill treats GitHub’s dsh-plugin topic as the plugin identity, rather than a specific owner or organization as the directory. Whether a repository belongs to an individual or an organization does not matter: as long as it is a public repository with this topic, it can still be discovered even after the ownership is transferred. The search results are based on the current fullName and url, and the address will not be guessed based on the old owner.
The retrieval script is the built-in skills/find-plugins/scripts/search-topic.mjs in the repository. It calls the GitHub Search API with the query condition topic:dsh-plugin is:public archived:false, then filters out forked, archived, and disabled repositories. The script handles pagination (100 items per page, up to 10 pages) and deduplicates by fullName. For authentication, it reuses GITHUB_TOKEN / GH_TOKEN first, then the local gh login token to increase the rate limit; if neither is available, it uses the public API. When rate-limited, you need to run gh auth login first and then retry, instead of falling back to a specific organization’s repository list.
The README also mentions: if the current account can read the catalog.json of dsh-external/hub, you can use its classification and installation instructions as supplementary information. The Hub is not the main directory, the GitHub topic is. If the Hub is missing, private, or still pointing to the pre-transfer address, it cannot override the current declaration of the repository.
First filter a small number of candidates, then determine the installation method¶
The skill will not open all repositories under the topic. It first compares the user’s requirements with the repository’s name, description, and topics, prioritizing hits that have been pushed recently, and only reads the README, package.json, and file tree for a small number of repositories with the closest semantic match. Then it judges the installation type based on the current declaration of the repository:
- package.json declares dsh.bundle.patch: install as a bundle
- Contains one or more SKILL.md files, and no bundle declaration: install as a skill
- The README explicitly requires writing cordis.patch.yml, but no bundle declaration: install as a cordis plugin
- Only uses the old .dsh-plugin / repository format: marked as “requires migration”, cannot be installed directly
- Cannot be determined: marked as “requires verification”, do not fabricate installation commands
references/install-methods.md also adds a priority order: when multiple methods coexist, bundle takes precedence over cordis, followed by external managers marisa / mygo. The latest DSH has removed the old repository format; for plugins with only old tags and no bundle, the skill will stop and prompt that migration is needed, rather than writing outdated configuration. marisa / mygo are managed by their respective managers, and this skill will not handle them.
The output will be a maximum of 3 rows of candidate tables: name, one-sentence purpose, last update time, and installation method. A one-sentence explanation of the preferred reason will follow the table. If no matches are found, it will directly state that there are none in the topic directory and ask if you want to write a new plugin instead.
The README gives two comparison examples (and clearly states that “search hits are purely coincidental”): “Want to visualize data and processes” can find dsh-visualize; “Want to add a 2005 Internet retro flavor to the Web UI” may find dsh-ads.
Report permissions before installation, disclose any issues or not¶
After the user agrees and before taking any action, the skill will first check what permissions the plugin will obtain when installed. SKILL.md specifies that this step cannot be skipped: plugins run in the user’s DSH process, can read sessions, call tools, and run commands, so installing them means granting authorization.
You need to check at least these four points:
1. Lifecycle scripts in package.json: preinstall, install, postinstall, prepare will be executed during Git / npm installation
2. External actions: network requests, child processes, writing paths outside $DSH_HOME, modifying shell configuration or system settings
3. Read session data and credentials: session logs, settings, .env or credentials
4. Trustworthiness of the repository itself: last push time, star count, whether the author has other dsh plugins, whether the README matches the code
Report regardless of whether issues are found, explaining in 3 to 5 lines: which parts were checked, what permissions the plugin actually requires, and whether there are actions that do not match its declared purpose. If there are suspicious items, paste the original text instead of paraphrasing it. After the report, ask once more whether to continue; if the user says to stop, the process will end here, and the plugin will not be installed automatically.
If actions not seen during the check appear during the installation process (new download sources, additional write paths, privilege escalation requirements), stop again and present the original text to the user.
Verify mounting after installation¶
After the installation is complete, enter the verification phase. Long-running interfaces such as web will listen for patch file changes and hot reload; one-time runs will take effect after the next startup. The skill will ask the user to confirm that the corresponding UI, tool, or skill entry has appeared. If it does not appear, troubleshoot in order: hmr/config-update-failed in the service log, whether the Git spec still uses the pre-transfer owner, ref / path spelling, and whether pnpm install in the profile directory was successful.
The completed state has only one criterion: the plugin selected by the user is available in their DSH instance.
Installation and Activation¶
The installation command given on the community directory page can be run directly in the DeepSeek Harness terminal:
dsh plugin add github:Nagi-ovo/dsh-find-plugins
For reproducible installations, the directory page recommends pinning the commit hash:
dsh plugin add github:Nagi-ovo/dsh-find-plugins#<commit>
Replace <commit> with the actual commit hash in the repository, do not leave the placeholder.
The repository README also provides the installation method for the skill directory. You can send the following message to DSH:
Please install the dsh-find-plugins skill from https://github.com/Nagi-ovo/dsh-find-plugins
For manual installation, copy the entire skills/find-plugins/ directory to the skill discovery root. Common locations are:
- Global: $DSH_HOME/skills/ (default ~/.dsh/skills/)
- Current project only: <project root>/.dsh/skills/, or <project root>/.agents/skills/
- Shared with other Agents: ${DSH_AGENTS_HOME:-~/.agents}/skills/
The directory has a watcher, so it will take effect immediately without restarting. You should copy the find-plugins directory containing SKILL.md, not the README and images in the repository root.
The directory page reminds: plugins run with the permissions of the current dsh process, and code may be executed during installation. Please check the source code repository and license before installing.
Typical Usage¶
SKILL.md states the trigger conditions very straightforwardly. When the user wants to find plugins for DeepSeek Harness, they can directly say:
Are there any plugins that can visualize data and processes?
Help me install a plugin that adds a retro flavor to the Web UI
What fun things are there in the ecosystem
You can also directly name a plugin:
Help me install dsh-visualize
When the user names a specific plugin, the skill will first verify the current repository and installation method, then proceed to the permission report, instead of searching again.
The complete process can be understood in six steps:
1. Get candidate pool: Run search-topic.mjs to get a list of public, unarchived, non-forked dsh-plugin repositories
2. Filter and confirm installation method: Only open a small number of the most matching repositories and generate a maximum of 3 rows of candidate tables
3. User confirmation: Pause and wait for selection
4. Security check and report: Report once regardless of whether issues are found, then ask whether to continue
5. Install: Follow the corresponding section in references/install-methods.md according to the confirmed installation type
6. Verify mounting: Confirm that the UI, tool, or skill entry has appeared
The official deepseek-harness repository is currently in developer preview, and the documentation states that there will be breaking changes. The installation commands in the skill are also written for the “latest DSH”, for example, installing a bundle from the source checkout root using pnpm dsh plugin --profile <profile> add .... The specific commands shall prevail based on the current declaration of the target plugin repository, do not copy the old .dsh-plugin configuration back.
Applicable Scenarios and Notes¶
It is suitable for these situations:
- Already using DeepSeek Harness and want to find ready-made plugins from the community topic according to requirements, instead of only browsing a specific organization
- Unable to distinguish whether the target repository should be installed as a bundle, Cordis plugin, or skill
- Want to see the permission report before installing, instead of directly executing plugin add
- The repository has just been transferred from an individual account to an organization (or vice versa), and need to install according to the current fullName to avoid using the pre-transfer Git spec
Please note the following points when using it.
First, plugins run with the permissions of the current dsh process. dsh-find-plugins will help you check other people’s plugins, but it is itself a skill loaded into dsh. You should read the repository source code and the BSD-3-Clause license before installing it. The directory page also states the same point: code may be executed during installation.
Second, it only covers public repositories tagged with the dsh-plugin topic. Repositories without this tag, archived, forked, or private repositories will not appear in the candidate pool. A search hit does not equal a recommendation, and the examples in the README also state that “search hits are purely coincidental”.
Third, the GitHub API has rate limits. Without GITHUB_TOKEN / GH_TOKEN or gh login, public search will still work, but it is more likely to be rate-limited. If rate-limited, you should authenticate first and then retry.
Fourth, the community directory and dsh-external/hub are both supplementary information sources and cannot override the current installation declaration of the repository. The directory site has no official affiliation with DeepSeek / HyperMind, do not treat it as an official app store.
Fifth, this skill is not responsible for developing new plugins, nor does it handle external managers such as marisa / mygo. The old repository format has been removed from the latest DSH. For repositories with only old tags, you should consider them as requiring migration, rather than forcing installation.
Summary¶
dsh-find-plugins turns “finding plugins in conversations” into a verifiable process: using GitHub’s dsh-plugin topic as the directory, filtering a small number of candidates, determining the installation method, reporting permissions before installation, and finally verifying mounting. For users who are already using DeepSeek Harness and do not want to manually browse repositories, it integrates discovery and installation into the same conversation, while making “installing a plugin means granting authorization” a default step.
Directory page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-find-plugins/
GitHub: https://github.com/Nagi-ovo/dsh-find-plugins