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.

Run the deterministic retrieval script built into this skill:

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.

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:

If the current account can read , 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.

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.

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.

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.