Submitting Your Plugin to dsh.plus

Review criteria

Human review on dsh.plus is guided by four criteria; the site reserves the final decision:

  1. Original & valuable: the plugin solves a real problem and provides standalone value, rather than simply wrapping existing functionality;
  2. Actually usable: it installs and runs without surprises, with a verifiable install path and basic stability;
  3. Well documented: clear README, install steps and usage examples — plugins with a vague README are not accepted for now;
  4. DSH ecosystem relevant: built for DeepSeek Harness use cases, or it significantly improves DSH workflows and experience.

There is also an implicit requirement: a permissive license. The repo must declare an open-source license (e.g. MIT, Apache-2.0) that permits listing, display and redistribution — repos with no license or unclear terms cannot be listed.

Submission flow

Submissions go through the Submit page (/submit), in roughly three steps:

  1. Fill in the form: plugin name, GitHub repo URL, category (Agent / Tools / UI & Theme / Automation / DevTools / Misc), your email, a one-line summary and optional notes; a Turnstile challenge protects the form;
  2. Enter the review queue: the submission lands in the pending queue, and the editors verify the repo metadata (description, stars, license, topics) against the criteria;
  3. Result: on approval, the system fetches repo metadata, generates a bilingual (zh/en) entry, commits it to the site repository and triggers a rebuild — your plugin appears in the library within minutes; rejections come with a reason.

Duplicate submissions of the same repo are blocked by dedup, so please don’t resubmit the same project.

How to write an application that passes

  • Make the README say three things: what problem it solves, how to install, how to use — with runnable examples and screenshots where possible;
  • Provide a verifiable install command, e.g. dsh plugin --profile web add <your-package>, so reviewers can copy and test it directly;
  • State the license clearly and include a LICENSE file in the repo root;
  • Be deeply DSH-related: build for the Harness, e.g. register tools, extend agent capabilities, integrate third-party services; tag the repo with the official dsh-plugin topic;
  • Keep the repo alive: make sure it installs and runs before submitting — archived or 404 repos are rejected outright.

Common rejection reasons

  • The README is vague — purpose, install or usage is unclear;
  • It cannot be installed or run; the install command is not verifiable;
  • Unrelated to DSH, or a thin wrapper around existing functionality;
  • Already listed, or highly redundant with an existing plugin;
  • No license, or a license that forbids redistribution;
  • The repo is archived, 404, or abandoned.

If your plugin is rejected, the email or form note explains why; fix the issue and resubmit. To get started writing plugins, read Your First Cordis Plugin and Cordis, Level Up.