Skip to content
dsh-market Browse plugins GitHub 中文

white-sand-grand/dsh-plugin-doctor

Community search, similarity analysis, and install/dedupe/build-it-yourself decisions for the dsh-plugin ecosystem.

Stars ★ 3 Category Plugin Markets & Managers Listed 2026-08-17

Install

Inside DeepSeek Harness, with dsh-market

dsh plugin --profile web add dshmarket

Or from the command line

dsh plugin --profile web add github:white-sand-grand/dsh-plugin-doctor

Installing runs third-party code with your own permissions — it can read your files, use your credentials and reach the network. Review the source first, and pin a commit (github:owner/repo#sha) when you can.

README

Chinese version: README.md

dsh-plugin-doctor is a diagnostics and decision tool for the DSH plugin ecosystem. It searches community plugins, compares overlap, understands aggregate bundles, guards multi-plugin installs, audits real usage, and renders a plugin landscape graph. Inspired by Claude Code's /doctor command and repeated plugin conflicts and crashes caused by installing incompatible extensions.

Current version: 1.0.0. Requires Node.js >=22.19. The plugin is read-only by default: it does not start Web UI or mutate a profile on its own.

Install

Run this in the same environment that runs DSH:

dsh plugin --profile web add github:white-sand-grand/dsh-plugin-doctor

Start DSH Web yourself when needed:

dsh web

Open http://127.0.0.1:3080 and ask questions in natural language. The plugin does not start Web UI or change other profile plugins.

Update

Use this deterministic refresh sequence:

dsh plugin --profile web remove dsh-plugin-doctor
dsh plugin --profile web add github:white-sand-grand/dsh-plugin-doctor

Start Web yourself after updating if needed:

dsh web

Capabilities

Need Behavior
Find a plugin Searches GitHub dsh-plugin repositories and fallback sources; returns match, capabilities, stars, update time, and install reference
Check functional overlap Compares description text, capability tags, and dependencies, then recommends dedupe or self-development
Ask how installs relate Renders a similarity graph with Chinese function summaries and edge explanations
Check several repositories before installing Inspects package names, tools, Cordis patch rows, and peer dependencies; conflicts or unknown metadata return INSTALL BLOCKED
Understand an aggregate bundle Expands installed DSH-shaped dependencies; child plugins carry providedBy and are not recommended for independent removal
Audit actual usage Scans finalized local session logs and attributes tool calls through dsh.tools
See the overall plugin landscape Renders a Mermaid relation graph and core / active / idle / review tiers
Learn about known official issues before installing Before search, recommendation, or supplied repository links lead to an install, asks whether to inspect open issues and shows relevant official links

Tools

  • plugin_community_search: community search and filters.
  • plugin_similarity_analyze: similarity, redundancy groups, and irreplaceability.
  • plugin_recommend: install, dedupe, or self-development decisions with aggregate-bundle awareness.
  • plugin_install_guard: read-only preflight for multi-repository installs.
  • plugin_usage_audit: local session usage audit.
  • plugin_landscape: installed/community relation graph and usage tiers.

The agent selects the appropriate tool automatically.

Official issue check before installation

When a user searches for an installable plugin, asks for a recommendation, or sends repository links to install, the plugin first asks whether to inspect open issues in the official repositories. It matches issue titles and bodies against the requested capability or symptom and shows official links, such as an unresolved report about recursive file watching causing Web UI stalls.

If the user explicitly chooses “do not check this session,” the prompt is suppressed for the rest of that session and returns in a new session. Dismissed prompts or unavailable interaction are reported as incomplete checks, never as proof that no known issue exists. An unavailable Issue API affects only the warning; it never bypasses the install guard's fail-closed behavior.

Examples

Ask about official issues before installing (real incident pattern)

I want to install a Web UI plugin. Check the official repository for unresolved issues first so we do not repeat history-load failures, unavailable model selection, or stuck file operations.

The plugin first asks whether to check official open issues. In the real incident pattern, an official repository contained an open issue closely matching “right-side file panel stalls and history loading fails”: the root cause was not the remote Web plugin, but a file-panel plugin whose recursive watcher consumed resources. The report uses a blurred plugin name such as @example-org/ui-panel-plugin and links to the official Issue #119 for verification. After an explicit refusal in the current session, later install requests do not repeat the prompt.

Search and check overlap

Find me a memory plugin and check whether it overlaps with plugins in my web profile.

The result lists candidates, match reasons, overlap scores against local plugins, and keep/remove commands. Spec generation and dedupe execution require confirmation.

Guard a multi-plugin install

I want to install these repositories together. Check for conflicts first:
github:owner/plugin-a
github:owner/plugin-b
github:owner/plugin-c

If GitHub returns 403/429, or repository metadata cannot be read, the result is INSTALL BLOCKED with token and rate-limit-reset guidance. Unknown metadata is never waved through.

View plugin relationships

How are the plugins I installed earlier related? Which ones are similar?

plugin_landscape returns a relation graph. Nodes include Chinese function summaries; edges explain whether similarity comes from descriptions, capabilities, or dependencies. With an intent, community candidates join as dashed nodes.

Understand an aggregate bundle

I need a task board. Does my installed UI bundle already provide one?

The recommendation path reads plugin-shaped dependencies of installed aggregate bundles. When a bundle already supplies the capability, the report shows its providedBy owner and avoids recommending an independent child removal or duplicate install.

Audit usage

List plugins in my web profile that declare tools but have never been used.

The result is based on local finalized session logs and never uploads their contents. An active or not-yet-flushed session may not be included and is called out.

Direct DSH questions versus doctor

When you simply ask DSH to “find a plugin,” the model may offer a general suggestion from context, but it does not consistently search the community, read local package metadata, quantify overlap, or inspect Cordis registration conflicts. A multi-repository install can also proceed without a preflight.

With dsh-plugin-doctor, the same requests produce structured, reviewable evidence:

Direct DSH question With dsh-plugin-doctor
Relies on model context or an ad-hoc search Uses GitHub, cache, and registry fallbacks and identifies the source
Says plugins “look similar” Returns text, capability, and dependency similarity plus redundancy groups
May miss children inside an aggregate bundle Reads installed bundle dependencies and marks providedBy
Installs several repositories immediately Checks package names, tools, patch rows, and peer dependencies first; unknown state fails closed
Gives no reliable usage history Counts tool calls, sessions, and recency from local session logs
Describes relationships only in prose Renders a Mermaid graph with pair-by-pair explanations

Safety and degradation

plugin_install_guard fails closed when repository metadata cannot be verified. GitHub 403 and 429 responses include token and rate-limit-reset guidance; unknown metadata is never treated as conflict-free.

Community search falls back in order: live GitHub, process cache, third-party registry pages, then a built-in snapshot. The response identifies the data source used.

The usage audit reads only session files already flushed to disk. An active or not-yet-flushed session may be absent and is called out in the report. Corrupt artifacts are skipped and counted; runtimes without zstd support skip compressed logs without preventing the other tools from loading.

Optional configuration

Field Default Purpose
githubTokenEnv DSH_PLUGIN_DOCTOR_GITHUB_TOKEN Environment variable containing a GitHub token
githubToken none Literal token; prefer the environment variable
similarityThreshold 0.8 Similarity threshold for redundancy
cacheTtlMinutes 30 Community search cache lifetime
enableRegistryFallback true Enable registry and snapshot fallbacks
allowExecuteActions false Permit confirmed interactive add/remove actions; default is report-only

Prefer an environment variable and keep tokens out of repositories:

export DSH_PLUGIN_DOCTOR_GITHUB_TOKEN='your GitHub token'

Development

git clone https://github.com/white-sand-grand/dsh-plugin-doctor.git
cd dsh-plugin-doctor
pnpm install
pnpm test
pnpm run build
node verify-boot.mjs

Current verification baseline: 56 tests pass, TypeScript builds, and all six tools register and pass the smoke invocation. See ARCHITECTURE.md for the algorithm and data flow, and CONTRIBUTING.md for contribution rules. Do not share one node_modules between Windows and WSL.

License

MIT.

Content from the project README on GitHub ↗