Preview your dsh plugin Hub entry before publishing

A dsh plugin Hub entry is assembled from three files before anyone reviews it, and each file is responsible for a different part of what users see. Previewing the entry means checking that pipeline, not staring at the final card.

Why a DSH plugin Hub entry can look right and still fail

Polished copy and a nice icon can hide a broken identity, an unloadable bundle or a category that puts the plugin in front of the wrong people.

The common failure is not a typo. It is a mismatch between what the entry claims and what the package does. The name in the card differs from the package name; the install command points at a scoped package nobody can resolve; the category promises an integration but the plugin is a theme.

These problems survive local testing because the developer tests the running plugin, not the entry. The plugin works in a profile while the metadata that surrounds it is wrong. The card is generated, so it reflects whatever the metadata says even when the package disagrees.

The entry is a projection of three sources: package.json, the bundle, and the description file. Checking the projection means reading all three and comparing what they claim against what the packed package actually contains. A disagreement between them is the actual bug to fix.

package.json decides the identity of a DSH plugin

The package file supplies the facts that must never disagree: name, version, author and dependencies.

The package name is the durable identity. Users search for it, lockfiles record it, and install commands resolve it. Changing it after release breaks every reference that already exists.

The display name can be friendlier, but it must map back to the same package. A display name that drifts into a separate brand makes the entry look like two plugins. Users remember the display name, but tooling remembers the package.

Version and dependencies are the other half. If the entry shows a version that the registry does not have, the install command is already broken. A stale version is worse than an old version, because it promises something the registry cannot deliver.

Read these fields from the packed tarball, not from your working copy. The working copy can contain changes that never made it into the package, and the Hub will never see them. The tarball is the artifact the Hub and the user will actually receive.

The bundle decides whether a DeepSeek Harness plugin loads

An entry that renders proves nothing about loading; the bundle is the file that decides whether a DeepSeek Harness plugin actually starts.

The bundle declares the entry point, capabilities and load information. A wrong path or a missing manifest produces a plugin that appears in the list and fails to activate. That failure is silent unless someone checks the plugin state after installing.

This failure is easy to miss in preview because the card is generated from metadata. The metadata can be perfect while the bundle points at a file that was not included in the package. That gap is invisible in a metadata-only preview.

Pack the package and install from the tarball. That is the closest local approximation of what a user will get. Anything that fails there will fail for a user too.

If the plugin loads from the tarball, the bundle is probably fine. If it renders but does not activate, the bundle is the first suspect. A working card with a silent plugin is the worst outcome because it looks like success.

The description file decides how a DSH plugin is found

Search and discovery are driven by text and category, so the description file decides who ever sees the entry.

The description supplies the text users read and the category the Hub uses for placement. A vague description and a mismatched category make a working plugin invisible. Both fields are part of discovery, not decoration.

Write for search first: what the plugin does, which host it targets, and the terms a user would type. Then write for the detail page: limits, requirements and a short example. The first version serves the search box; the second serves the decision to install.

Screenshots support the text but do not replace it. Search matches fields, not pixels. A search term that never appears in the field will never return the entry.

Keep the category honest. A wrong category may produce clicks but not installs, and it wastes the attention of the people who were looking for something else. Discovery and installation are different promises, and the category only controls the first.

Reading a DSH plugin Hub entry as one pipeline

The three files feed one pipeline, and a preview is only meaningful when it exercises the whole path.

A pipeline preview has three checkpoints. First, does the packed package install into a clean profile? Second, does the plugin activate and perform one real action? Third, does the entry appear under the expected search terms and category?

Skipping the middle checkpoint is the usual mistake. Developers verify text, or verify the plugin, and never verify that the two describe the same thing. That is where a text-perfect entry with a broken plugin gets caught.

Compare the entry with a mature one in the same category. The comparison is faster than an imagined checklist and reveals missing fields you did not know existed. It is not about copying wording; it is about noticing which questions the entry leaves unanswered.

The pipeline is also the review path. If a reviewer cannot follow it, users will not either. A reviewer who has to guess is a preview that was never finished.

Previewing a DSH plugins release before the Hub sees it

A dry run turns the pipeline into evidence you can submit alongside the package.

Install from the tarball into a clean profile, open the Hub, and check the card against the package. Search by package name, display name and author; all three should reach the same entry. Keep the profile disposable so the test can be repeated.

Then uninstall and reinstall. Residue that survives is part of the user experience, and reviewers will find it if you do not. How the uninstall behaves is part of the entry, even though it is not on the card.

1. Pack the package and inspect the included files.
2. Install the tarball into a clean profile.
3. Confirm the plugin activates and runs one real action.
4. Search by package name, display name and author.
5. Compare the card with a mature entry in the same category.
6. Uninstall and check what remains.
7. Write the four results into the submission note.

The checklist is short because the pipeline is short. Most publishing failures come from one of three files disagreeing with the other two, and a dry run is how you catch the disagreement before a reviewer does. Each result is a fact the reviewer can check instead of trust.

That is also the point of previewing at all. The goal is not a prettier card; it is a card that matches the package behind it, from the DSH Plugin Hub search result down to the uninstall step. That match is the only definition of ready that survives review.