Inclusion criteria
A plugin is listed when it is a public repository that extends DeepSeek Harness, carries the
dsh-plugin topic or has been submitted for review, declares a license, and ships an install
command that resolves. Plugins that are closed source, that only wrap an unrelated project, or that cannot be
installed by a reader are not listed.
Categorisation
Categories describe the surface a plugin changes, and use cases describe the job it does. Both are assigned by review from the repository description and source, not copied from self-descriptions, because self-descriptions tend to claim every category at once.
Verification levels
Verification levels record how far the install path was exercised, from L1 (repository found) to L5 (plugin loaded and run). Levels describe testing, not trustworthiness. The full rules are on the verification page.
Collections and picks
Editorial collections are chosen on capability gain and maintenance signals: recent commits, a declared
license and a dshTarget that tracks a current preview release. Star counts are context, never
the deciding factor, and no placement is paid for. A pick that stops tracking the runtime is replaced rather
than quietly left in place.
Removal and correction
A listing is corrected or removed when its install spec stops matching the published package, its repository disappears or is archived, its license changes in a way that contradicts the listing, or it is reported as malicious. Malicious reports are acted on first and investigated second.
Corrections from maintainers
Maintainers may request corrections to their own listings, including category, description and install command. Requests are not treated as promotion: a correction that makes a listing more accurate is applied regardless of whether it improves the plugin's position.
Independence
AllDSH is not affiliated with DeepSeek AI. Nothing on this site is an endorsement by DeepSeek, and no maintainer pays for placement, a verification level or a collection entry.
Generated listings
Listings are assembled from public repository data by automated processes, then reviewed. Where automation necessarily decides something, it is the technical metadata: stars, license, language and dates. Where judgement is required, which is categorisation, verification and editorial picks, a person decides.
Sourcing and attribution
Every guide and digest post ends with the primary documents its technical claims rest on: the upstream repository, the package registry entry, the specification a plugin implements, or the standard a recommendation follows. We cite first-party documents rather than summaries of them, and links are re-checked when a page is revised so a dead reference is treated as a bug.
Attribution is stated on the page, not only in metadata. Each prose page carries a named byline and a publication and revision date, and each listing records when it was last checked. Where a claim cannot be pointed at a source, it is written as our observation rather than as a fact. How to quote or reuse this work is set out on the citations page.