dsh plugins vs dsh plugin: 4 search intents and entry points

The difference between dsh plugins and dsh plugin is not grammar; it is what you want to do when you type it: find, install, check commands, or read source. Four intents, four entry points. Choosing the wrong entry point produces "I found it but cannot install it" or "I installed it but cannot find it."

Start with the results: what each term points to

Put the four common spellings side by side and the difference is obvious. This is not random search behavior; it comes from page titles, repository naming, and command docs.

The plural feels like browsing; the singular feels like doing. When you search dsh plugins, you usually have not decided which plugin to install. When you search dsh plugin, you usually have a specific action in mind.

The hyphenated form is an identifier, not natural language. dsh-plugin appears in package names, repository names, and topics. Its job is to identify, not to describe. Searching articles with it tends to produce noisier results.

Intent one: finding plugins, start in the market

The first entry point for discovery is DSH Plugin Hub, not a search engine. It lives under Settings, Plugin Market, and puts category, search, source, and compatible version on the same card (source).

1. Open Settings, Plugin Market, and narrow by category first: memory, browser, interface, model, tools.
2. Search within the category by Chinese name, English name, or package name; each has a different hit rate.
3. Read the card's source, version, update time, and verification status to rule out a same-name plugin from another author.
4. Open the detail page, then copy the install command or install directly.

Off-site search is for discovery, not confirmation. Searching dsh plugins returns blog posts, roundups, and GitHub topics, but these pages rarely include compatible versions or verification status. Discovery ends with a check in the Hub or repository.

Chinese terms help with introductions; English terms help with precision. dsh 插件 tends to return explanatory articles, while dsh-plugin returns repositories and package pages. Knowing your stage prevents using an introduction as an installation source.

Intent two: installing, trust the command

The reliable entry point for installation is the dsh plugin command family. Buttons, copied commands, and one-click installs all end at that command (source).

1. Confirm the target profile: dsh plugin --profile web list should list state for that profile.
2. Install with dsh plugin --profile web add <package-or-reference>; a package name comes from npm, and a reference can be github:owner/repo.
3. Restart after installation so the plugin registers during startup.
4. Verify with list and dsh --dump-config: the package is listed and the config tree contains its section.

Omitting --profile is the most common mistake. The command falls back to the default profile while you look for the entry in another environment, then conclude it did not work. Confirm the profile first.

The command and the plugin name look alike but behave differently. dsh plugin add is an action; dsh-plugin-xxx is an identifier. When an article mixes them, trust the command line: the line you can paste and run is the installation entry.

Intent three: checking commands, ask the CLI

Do not search articles for command syntax; ask the CLI. Versions change and old articles go stale, while --help always matches the installed version.

1. Run dsh plugin --help to see the subcommands supported by your version.
2. Run dsh plugin add --help to see installation and profile options.
3. Copy an example into a non-critical profile and try it.
4. Record the version number so you can compare with article syntax later.

Help text is shorter than articles but more accurate. Articles omit version prerequisites; help does not. When an article says an option exists but the CLI rejects it, check help before deciding whether the article is outdated.

Write your own cheat sheet. Install, list, remove, and update cover daily use. Writing them down beats searching every time and protects you from inconsistent article syntax.

Intent four: reading source, go to GitHub and npm

The entry point for source is the repository, not the market. The market shows metadata; the repository has implementation, commits, and issues (source).

1. Use the source label on the Hub detail page to confirm owner and repository name.
2. Open the repository and read the README install section and compatible version, then check engines and dependencies in package.json.
3. For troubleshooting, read issues and commits to see whether a problem is fixed and in which version.
4. To install an unreleased build, use a github: reference instead of an npm package name.

Same-name repositories are common; owner is the unique key. Names like dsh-memory or dsh-browser may have several implementations. Checking only the name leads to installing the wrong one.

npm pages confirm versions; GitHub pages confirm implementation. When they disagree, trust the repository's package.json and release notes; the npm latest tag can lag behind.

Three places where the wrong entry point hurts

Most "found it but useless" cases fall into three buckets. Each has a clear diagnostic action.

1. Installed into the wrong profile. The article told you to install into web, but you look in the desktop app. Run list in both profiles to see where the package landed.
2. Mistook the display name for the package name. Display names can repeat; package names and owners cannot. Compare the source label and install command on the detail page.
3. Treated an index as real time. There is a delay between a repository appearing and the Hub indexing it. Search GitHub topics or npm first, then check the Hub again.

All three share one pattern: the entry point does not match the goal. Finding used a command entry, installing used an article entry, and source reading used a market entry. The actions were fine; the entries were wrong.

One table for intents and entries

Keep this table nearby when you are unsure.

Pick the right entry and the following actions make sense. The same word pointing to different entries at different stages is normal search-intent layering, not contradiction.

Next steps

Decide the intent, then open the matching entry. To find plugins, go to DSH Plugin Hub. To install, read How to install a DSH plugin. To understand plugin versus plugin package, read What dsh plugins really means.

Sources: dsh CLI README, DeepSeek Harness docs - Your first plugin, GitHub topic: dsh-plugin, DSH Plugin Hub plugin page