dsh plugin market visibility: index, category, keywords

A plugin can publish cleanly and still be invisible in the dsh plugin market, because exposure is a chain rather than a switch. The chain passes through five gates:

1. Publishing puts the package on the shelf.
2. Indexing creates a searchable entry.
3. Category placement decides which browsers meet it.
4. Search fields decide which queries return a hit.
5. Detail-page completeness decides whether a click becomes an install.

Treating a failed search as one bug usually sends the author to the wrong end of that chain.

Publishing puts a dsh plugin package on the shelf

Publishing proves that the package resolves; it says nothing about whether a dsh plugin entry has been created.

The first thing to verify is identity, not wording. A market entry should point at the full package name rather than a display name, and the version shown on the page should match the version that npm resolves. The publisher field should also agree with the repository owner, otherwise a reader who follows the trail lands somewhere unexpected. When these three disagree, the entry may exist and still install the wrong thing.

A second failure mode is an entry that points at a package that has been renamed or unpublished. The page looks healthy until the install command fails, and the author usually hears about it from a user rather than from the market. Comparing the entry's install command with a fresh package query takes less than a minute and catches most of these cases. If the package itself is sound, the next question is whether the entry was indexed at all.

Indexing is a separate queue for a dsh plugin entry

Indexing is market-side work that turns a published package into a searchable dsh plugin record, and it can lag or skip an entry without any error.

Indexing usually runs as a market-side job, and the author can only influence the metadata it reads. An empty description, a missing entry field or a malformed version can make the job skip an entry without producing a message anyone sees. What the author sees instead is an empty search box, which is easy to misread as a failed publish. Adding metadata afterward is useful, but it does not retroactively explain why the first pass failed.

The detail page is a better intermediate checkpoint than the search box. If the page opens, the package and the entry exist, and the remaining problem is likely fields or category. If the page is missing, stop working on keywords and return to publishing and indexing. Repeated resubmission while waiting is rarely useful and can create duplicate entries.

Category placement decides which dsh plugin browsers meet you

Category browsing is the second entrance to a dsh plugin, and a wrong category hides an entry from people who do not know its name.

Category browsing serves the user who knows the problem but not the package. Someone opens memory, workflow or interface categories and scans rather than typing a precise name, which makes placement a discovery decision rather than decoration. Authors tend to classify by implementation, while users classify by need; a session archive filed under storage may be invisible to someone browsing memory. Following the peers on a category page is usually more reliable than inventing a new home.

Category also interacts with search, because some markets treat the category name as an implicit keyword. A correct category can therefore improve broad queries without any change to the description. Moving an entry between categories is cheap and does not affect installed users, which makes it a sensible first experiment when visibility is weak. If similar plugins cluster on one page, joining them is usually better than defending a cleverer taxonomy.

Search fields decide which dsh plugin queries return a hit

Search matches text rather than intent, so the dsh plugin fields must contain the words users actually type.

The package name is the identity and the most likely English query, so it should carry a function word rather than only a brand prefix. The display name can read naturally, but it still needs a functional term, or Chinese users searching for memory will never meet the entry. The first two sentences of the description carry weight in both search and result summaries, so they should state the problem and the scenario instead of stacking adjectives. The author field is underrated, because people who know your other work search by name.

The split between Chinese and English queries deserves separate treatment. Most DSH plugins are discovered through a mixture of translated terms, package names and author names, and neither audience should come up empty. Writing both phrasings into the description reads better than forcing keywords into the title. After editing, search the package, display and author names once each; two hits out of three is a reasonable bar for field quality.

Detail-page completeness keeps a dsh plugin worth opening

A search result earns a click, but only a complete dsh plugin detail page earns an install.

The page has a few seconds to answer what the plugin does, how it installs and which version is current. A one-line description, an install command that points at a renamed package and an update time from six months ago will lose the click even when the ranking is good. Worse, the user blames the market for an install failure that belongs to the entry. Completeness does not require an essay: capability boundaries, dependency conditions, minimum steps and the current version cover most of it.

Text is also the raw material for search and summaries, so screenshots cannot replace it. A DeepSeek Harness plugin with a precise description and a working command is easier to index, easier to trust and easier to support. The DSH Plugin Hub entry is the place to confirm what the current listing shows before rewriting anything. Exposure is maintained rather than achieved, and the detail page is where that maintenance becomes visible.

Sources: DSH Plugin Hub plugin entry, dsh-plugin-hub repository, your first plugin.