Treat GitHub's dsh-plugin topic as the plugin identity, not some owner or organization as the directory.
After a repository transfer, use the latest fullName and url returned by search results as authoritative. There is only one completion state: the plugin the user
selected is usable in their DSH.
Step 1: Get the candidate pool
Run the deterministic retrieval script bundled with this skill:
node <本 skill 目录>/scripts/search-topic.mjs > <临时目录>/dsh-plugins.json
The script searches all public, non-archived, non-fork repositories with the dsh-plugin topic, and handles GitHub
pagination. It reuses GITHUB_TOKEN / GH_TOKEN, the local gh login token in order to raise the rate limit; when neither
is available it uses the public API. When rate-limited, run gh auth login and retry; do not fall back to organization repository lists.
Completion point: the repositories in the JSON is non-empty, and each entry has the current fullName、url, description,
topics, and update time. Deduplicate by fullName , and do not guess addresses based on an old owner.
Step 2: Filter and confirm the installation method
First compare the user's needs against name、description、topics, and by pushedAt prioritize looking at newer
matches. Only for the small number of repositories with the closest semantic match, read the README,package.json and the repository file tree:
package.jsondeclaresdsh.bundle.patch：bundle。- containing one or more
SKILL.md, and has no bundle declaration:skill。 - The README explicitly requires writing to
cordis.patch.yml, but there is no bundle declaration:cordis。 - Only the
.dsh-plugin/repositoryold format: mark as "needs migration", cannot be installed directly. - Still cannot determine: mark as "needs verification", do not fabricate installation commands.
If the current account can read dsh-external/hub/catalog.json, you may treat the note、
category、managers in it as supplementary information; only accept entries whose url exactly matches the current URL from the topic search results.
A missing, private, or still pre-transfer-address Hub does not affect the discovery results, and cannot override the repository's own
current declarations.
Produce a candidate table of at most 3 rows: name, one-sentence purpose, most recent update, installation method. After the table, explain the preferred choice in one sentence. For example, "meme / retro / fun" can match dsh-ads; "draw out data, processes, and comparisons" can match dsh-visualize。
When nothing matches at all, say directly that there is nothing in the topic directory, and ask whether to switch to make-dsh-plugin to write one now.
Step 3: User decides
Stop and wait for a choice. When the user has already named a specific plugin, after verifying the current repository and installation method from Step 2, go directly to Step 4.
Step 4: Security check and report
After the user agrees and before taking action, first look at what this plugin will get once installed. Plugins run in the user's DSH process, can read sessions, call tools, and run commands; installing one is equivalent to authorization, so this step cannot be skipped, and you cannot speak up only when a problem is found.
Look at at least these four places:
package.json's lifecycle scripts:preinstall、install、postinstall、prepareexecutes during Git / npm installation.- Outward-facing actions in the plugin declarations and source code: network requests, child processes, writing to paths
other than
$DSH_HOME, modifying shell configuration or system settings. - Session data and credentials read by the plugin: places that read session logs, settings,
.envor credentials. - The repository's own trustworthiness:
pushedAt, star count, whether the author has other dsh plugins, whether the README and the code match up.
Whether or not problems are found, report back, in three to five lines make it clear: which places you checked, what permissions this plugin actually requires, and whether there are any actions that don't match its claimed purpose. If there are suspicious items, paste the original text; don't paraphrase.
After reporting, ask once more whether to continue. If the user says stop, stop right there; don't go ahead and finish the install.
Completion point: the user has seen this report and explicitly says to continue.
Step 5: Install
Open references/install-methods.md according to the confirmed installation type and follow the corresponding section. When multiple methods coexist, choose one according to the priority at the beginning of that file.
If actions not seen in Step 4 emerge during installation (a new download source, extra write paths, a request for privilege escalation), stop and hand the original text to the user; don't judge while installing.
Completion point: configuration written, dependencies installed, commands with zero errors.
Step 6: Verify mounting
Long-running surfaces such as web hot-load after listening for patch file changes; one-off runs take effect only on the next startup. Ask the user to confirm that the corresponding UI, tool, or skill entry appears.
If it doesn't appear, troubleshoot in order: the hmr/config-update-failedin the service logs, whether the Git spec still uses
the pre-transfer owner, ref / path spelling, whether the profile directory's pnpm install succeeded.
Completion point: the user confirms it works; or bring back the specific error and the causes already ruled out.