How to choose DSH plugins: from need to install list

After this tutorial you will

• Turn “I want some useful plugins” into a concrete need instead of a shopping list
• Judge whether a plugin is worth trying through source, maintenance, permissions, and install evidence
• Start with a minimal setup that you can roll back

Compatible version

Compatible with: dsh 0.1.x. This is a selection and verification method; use the plugin detail page and upstream README for the exact command.

Step 1: write the problem in one sentence

“Install plugins for DSH” is not a goal. A goal is a work problem with an observable result, such as “help the agent inspect a screenshot and point out UI issues” or “turn a recurring report into a reusable workflow.”

Write it as scenario + input + expected output. That keeps your search anchored to capability instead of names and star counts.

Use this site's collections to create a first candidate list. They are a starting point, not a universal ranking.

Step 2: inspect four kinds of evidence before stars

Stars measure attention, not compatibility or safety. For every candidate, check:

1. Source — is there a real repository and a README that explains the purpose?
2. Installation — is there a complete dsh plugin ... add command, and does it identify npm, GitHub, or a local source?
3. Maintenance — can you find recent work, release notes, issue responses, or a license?
4. Permissions — do the requested capabilities make sense for the job? A theme should not need shell access; a file tool should state its scope.

Machine-audited evidence on a detail page is a cue that information exists, not a certification. Missing information is not proof of harm, but it is a reason to read further or test in an isolated profile.

Step 3: use the compatibility checker for triage

Open the compatibility checker, enter the full owner/repo plugin ID, and choose your platform and profile. It reports whether the directory has an install command, README, synced repository data, platform/DSH declarations, a fixed profile, and risky patterns that deserve review.

“Not declared” does not mean “unsupported.” Read the upstream README or test in a separate profile instead of treating missing data as a pass.

Step 4: install the smallest useful combination

Do not install ten plugins just to fill a toolbox. A controlled first setup usually has one plugin that solves the current job, at most one helper, and a short record of the command, date, upstream URL, and removal path.

For a visual-design task, install one design or vision capability, complete one real task, and only then add a theme, pet, or marketplace helper.

Step 5: turn a trial into a repeatable check

An install without an error is not enough. Give the plugin a small real acceptance task:

• Can you see or call it in the intended profile?
• Does it complete the minimum capability promised in the README?
• Does output land where you expected?
• Does a failure contain enough detail to investigate?

Keep it only after that check. If it fails, remove it and record one sentence about why. Your next selection will be much faster.

Common questions

Is the most-starred plugin always best?

No. A monorepo's stars may describe the whole project, not the sub-package you need. Start with task fit, installation clarity, and permission boundaries.

Should I try an unfamiliar plugin in my everyday profile?

You can, but a separate profile is safer for plugins that touch local files, network services, shell commands, or tokens.

What if no plugin is perfect?

Choose the best-documented option that solves 80% of the problem, keep the rest manual, and add another dependency only after the real gap is clear.

Next up

Chosen a plugin but hit an error? Read Plugin install troubleshooting.