Publish a DSH plugin to the Hub: review checklist

Review for publishing a DeepSeek Harness plugin to the DSH Plugin Hub checks one thing: whether a user clicking install actually gets a working plugin. Rejections therefore cluster around uninstallable packages and incomplete metadata, which makes the pre-submission checklist more decisive than the code. This guide covers prerequisites, three distribution routes, five rejection reasons and follow-up.

Four prerequisites for publishing a DeepSeek Harness plugin

Bottom line: installable package, complete metadata, verifiable provenance, clear license. Missing any one invites rejection.

1. An installable package: published to a registry the marketplace can reach, with a resolvable name and version. This is the hard gate.
2. Complete listing metadata: name, one-line description, category, dependency notes, install method. Document dependencies explicitly — their absence is the top cause of user install failures.
3. Verifiable provenance: repository and maintainer information users can check when deciding whether to rely on it.
4. README and license: usage and permissions in the README, terms in the license.

Option A: publish to npm (primary route)

Bottom line: publish the package to a public registry and point the listing at it. This is the shortest install path and matches marketplace expectations.

1. Prepare package.json with name, version, entry point, dependencies, repository and license.

npm view <your-package> version      # expected: returns the published version

2. Publish (same for first release and updates):

npm publish --access public
# expected: success, after which npm view returns the new version

3. Verify installability in a clean environment — this prevents most rejections:

dsh plugin add <your-package>@<version>
dsh plugin        # expected: your plugin appears in the list

4. Submit the listing following the official publishing conventions, pointing at that package.
5. Trade-off: a public package exposes the implementation; use Option B for sensitive logic.

Option B: private registry plus listing (internal distribution)

Bottom line: for team-only use, skip the public marketplace. Publish to a private registry and document the source.

1. Publish to your private registry and document the source and install command for the team.
2. Still write complete metadata — name, purpose, dependencies, version — even without a public listing. You will need it in six months.
3. Decide whether to submit a public listing: if nothing sensitive is involved, a listing helps others; otherwise keep it private.
4. Keep versions in sync with documentation, or colleagues following the docs will fail (the same requirement as private registries for offline installs).

Option C: validate internally, publish when mature

Bottom line: do not rush the submission. Let a small group run it first, then list it — this avoids "rejected on day one" and "broken on day two."

1. Run an internal trial: have two or three colleagues install exactly as documented and record every snag.
2. Fix the docs and dependency notes from those snags — most "cannot install" reports come from unclear instructions, not broken packages.
3. State the compatible DeepSeek Harness version range.
4. Then submit: metadata is usually complete by this point.
5. Trade-off: one extra round buys fewer rejections and lower support cost.

Five rejection reasons for DeepSeek Harness plugin listings

Bottom line: almost every rejection is self-checkable before submitting. Compare item by item instead of redoing the work after rejection.

1. One more self-check: run install, use and uninstall on a clean profile or machine. Any blocked step means do not submit yet.
2. Record the results: which machine and version you validated on, so you can answer questions later.

Follow-up after submitting a DeepSeek Harness plugin

Bottom line: submission is not the finish line. Track three lines: listing display, user feedback, and version updates.

1. Check that the listing displays as intended — truncated descriptions, wrong categories and hidden dependencies all need correction.
2. Watch user feedback: fix documentation and dependency notes for install failures before doubting user actions.
3. Update the listing range when releasing new versions — changed dependencies or compatibility must be reflected, or the plugin installs but does not work.

DSH plugin troubleshooting during publishing

Bottom line: the object of investigation is the relationship between listing and package, not the plugin code itself.

1. User cannot install — ask for the package name and version, then verify with npm view yourself.
2. User installs but cannot use — check dependencies and whether their CLI version is in the supported range.
3. Rejected — work through the five-item table; resist editing code first.
4. Problems after a release — verify the dependency and compatibility range in the listing still holds.
5. Want more discovery — write a clearer description first; users find plugins by description.
6. Repair status, stated honestly: this checklist synthesizes the official publishing documentation with general package publishing practice. Specific submission fields, review criteria and display rules are defined by the platform and official docs — check docs/user/develop/basic/publish.md and the current submission page before submitting.

Sources: docs/user/develop/basic/publish.md, DSH Plugin Hub listing, npm Docs · package.json.