Find and Install Plugins
Treat the
topic on GitHub as the plugin identifier, not a specific owner or organization as the directory. After a repository is transferred, the latest
and
returned by the search results shall prevail. The only completion state is: the plugin selected by the user is available in their DSH.
Step 1: Get Candidate Pool
Run the deterministic retrieval script built into this skill:
sh
node <this skill directory>/scripts/search-topic.mjs > <temp directory>/dsh-plugins.json
The script searches all public, unarchived, non-fork repositories with the
topic, and handles GitHub pagination. It reuses
/
and the local
login token in sequence to increase rate limits; if none are available, it uses the public API. When rate-limited, run
and retry, do not fall back to the organization repository list.
Completion criteria: The
in the JSON is not empty, and each entry has the current
,
, description, topics and update time. Deduplicate by
, do not guess the address based on the old owner.
Step 2: Filter and Confirm Installation Method
First, match user requirements against
,
,
, and prioritize viewing newer hits by
. Only read the README,
and repository file tree for a small number of repositories with the most semantic matches:
- declares : .
- Contains one or more files and no bundle declaration: .
- README explicitly requires writing to but no bundle declaration: .
- Only has the old / format: mark as "Need Migration", cannot be installed directly.
- Still cannot be determined: mark as "Need Verification", do not fabricate installation commands.
If the current account can read
dsh-external/hub/catalog.json
, the
,
,
in it can be used as supplementary information; only accept entries where the
exactly matches the current URL from the topic search results. Missing hub, private hub, or hub still pointing to the pre-transfer address will not affect discovery results, nor can it override the current declaration of the repository itself.
Generate a candidate table with up to 3 rows: name, one-sentence usage, latest update, installation method. Add a sentence explaining the reason for the preferred choice after the table. For example, "Fun/Retro/Interesting" can hit
dsh-ads; "Visualize data, processes, and comparisons" can hit
dsh-visualize.
If no matches are found, directly state that there are none in the topic directory, and ask whether to redirect to
to create one.
Step 3: User Confirmation
Pause and wait for user selection. If the user has specified a certain plugin, directly proceed to Step 4 after verifying the current repository and installation method from Step 2.
Step 4: Installation
Open references/install-methods.md according to the confirmed installation type and follow the corresponding section. If multiple methods exist, choose one according to the priority at the beginning of the file.
Read the installation section of the repository README and
lifecycle scripts before proceeding. Git / npm dependencies may execute
,
,
or
. If additional downloads unrelated to the plugin function, writing to paths outside
or modifying shell configurations are found, first present the original content to the user for confirmation.
Completion criteria: Configuration written, dependencies installed, no command errors.
Step 5: Verify Mounting
Long-running surfaces such as web monitor patch file changes and hot-reload; one-time runs take effect only after the next startup. Ask the user to confirm that the corresponding UI, tool or skill entry appears.
If it does not appear, troubleshoot in the following order:
in service logs, whether the Git spec still uses the pre-transfer owner, ref / path spelling, and whether
in the profile directory was successful.
Completion criteria: User confirms availability; or bring back the specific error and the reasons that have been ruled out.