Development & Operations DSH plugins

Development plugins cover the operational side: debugging and tracing, plugin and skill managers, workspace organization, sandboxing and permission policy, penetration testing modes, packaging and desktop launchers.

This is the category to install first if you maintain your own plugins, because diagnostics pay for themselves the first time a plugin fails to load. Look for plugins that explain what went wrong, not just that something did.

How to choose in this category

Ask what surface the plugin debugs. Harness load failures, plugin lifecycle, network calls, and model routing are different layers; a tool that only prints “error” is not diagnostics. Prefer plugins that name the failing package, the permission that was denied, or the request that timed out.

Sandbox and pentest tools deserve a higher bar: they exist to widen capability under constraint. Require an explicit authorization story, a scope you can bound, and logs you can read after the run. Desktop launchers and installers should be judged on update path and recovery mode, not on screenshots.

What is mature versus thin here

Mature entries document failure isolation, rollback, or a doctor-style check. Thin entries are shell wrappers around npx with no failure story. If the listing cannot tell you what happens when a plugin throws at activation, treat the operational risk as yours.

Common mistakes

Installing a pentest pack because the tagline is exciting, without an engagement boundary. Trusting a desktop companion’s update channel without reading where binaries come from. Collecting five debug plugins that all hook the same lifecycle and fight each other.

Install order and boundaries

Among developer plugins, the ones that stay on a daily path are patch review, test runs, and diff presentation. Do not keep one-shot scaffolders installed. Before stacking several “dev everything” plugins, check whether they compete for the same tool names.