Plugin audit
How we audit every plugin
A directory is only as trustworthy as its weakest entry. Every plugin listed on dshbase passes three independent audits before it is published, and every listing carries an explicit verification status — so you always know what has been tested and what is still pending.
Data current as of 2026-08-16 · recalculated on every build from the live plugin dataset.
Three audits before listing
We do not scrape a list and publish it. Each entry is checked against three criteria before it appears in the directory.
1 · Source audit
Every entry must map to a real, reachable GitHub repository. Renamed, deleted, or unreachable repositories are removed — we do not keep dead links in the directory.
2 · Ecosystem audit
A plugin must actually belong to the DeepSeek Harness ecosystem. We check for DSH-specific manifests (cordis.patch.yml, dsh.bundle, and related root-level markers) and explicit DSH dependencies — not just a repo name or a topic tag. Repositories that borrow the label without the substance are excluded.
3 · Metadata audit
License, stars, forks, issues, last-updated date, language, and archived status are recorded for every entry and shown directly on the plugin card.
How we verify
The audits answer "does this belong here?" Verification answers "does it actually work?"
- Install verification (
verified/pending) — the evidence that matters most. Verified means we installed the plugin in a clean profile and it booted successfully; pending means it is listed from its repository but we have not yet run it. The two are never mixed, and every card shows which one it is. - Trust tier (
Silver/Bronze/Unrated) — a coarse confidence signal, supplementary to install verification. A tier is a starting point, not a verdict. - Popularity is not endorsement — star, fork, and issue counts are pulled from GitHub and shown as a popularity signal only.
Full verification run — August 2026
In August 2026 we put every pending plugin through a complete three-stage runtime pass in clean, isolated profiles. Here is what we found.
Method
- L1 · Install — the plugin is installed into a clean profile alongside a pinned DSH runtime.
- L2 · Load — the profile boots and dumps its configuration successfully.
- L3 · Runtime — a headless question is answered with the plugin loaded; the run must exit cleanly and return the expected answer.
Scope
923 pending entries — 878 GitHub repositories and 45 npm packages.
Results
Why the rest did not pass
Every failure is classified from its install log. Numbers below count unique plugins.
Install failures (159)
- 68 — declared dependency version does not exist on the registry
- 63 — build / prepare script failed (often a dependency on an unpublished @deepseek-ai/* package)
- 15 — dependency package or repository returns 404
- 13 — unsupported dependency structure (workspace / linked / exotic)
Runtime failures (182)
- 107 — plugin entry failed to activate at boot
- 70 — loader entry failed to apply (unsupported schema DSL, missing config, version mismatch)
- 5 — other
Load failures (10)
- 10 — overlay file missing (ENOENT)
Our stance on reliability
- Listing is not endorsement. Being in the directory means a plugin passed the audits above and genuinely exists in the DSH ecosystem — nothing more.
- We audit continuously. New plugins go through the full pass on intake, and existing entries are re-checked on a regular cadence. Plugins that go stale or drift out of the ecosystem are removed.
- Honest and reproducible. Every judgment rests on checkable evidence — manifest files, repository state, and actual test results — not on guesswork or bulk scraping.
Found a wrong entry or a plugin that no longer works? Tell us, or open an issue. Browse the plugin guide to see the directory in action.