8. Publishing Your Plugin to the Catalog

Once your plugin is working, publish it to npm and submit it to the dsh-suite catalog so others can discover, install, and trust it. This chapter covers the full publish-to-catalog pipeline: npm publish, the catalog submission, the compat CI, and badges.

8.1 npm publish

npm publish --access public

A few things to watch for:

• Granular token. Generate a CI-scoped npm token with publish permission (not a full account token). Store it in NPM_TOKEN or ~/.npmrc.
• Packument half-bump. If npm's registry hasn't propagated your latest version yet and npm publish fails with "cannot publish over existing version", wait a few minutes and retry. The packument cache self-heals; a second npm publish after the bump lands correctly.
• Version line. Pin @deepseek-ai/dsh-tools to the next-tag version (see FAQ #1) and keep all @deepseek-ai/dsh-* on the same 0.1.0-rc.x line.
• files field. Declare "files": ["dist", "cordis.patch.yml"] so only the built output and the bundle patch ship — not your src/, node_modules/, or test fixtures.

8.2 Submitting to the catalog

Open an issue on the dsh-suite repo using the plugin-submission template:

• npm package name — the exact name on the registry.
• GitHub repo — owner/name.
• One-line description — what the plugin does, in English and/or Chinese.
• Category — tools / skills / ui / session / llm / sandbox / orchestration / storage / acp / preset / utility.
• Why it belongs — what problem it solves, and how it differs from similar plugins.
• Compatibility — minimum DSH version, and whether it's been verified on a real DSH install.

The catalog maintainers will review your submission, run the compat CI, and add your plugin to the live directory.

8.3 The compat CI (three layers)

Every plugin in the catalog goes through a daily compatibility check with three layers:

1. Layer 1 — Static peer comparison. The CI runs npm view <pkg> peerDependencies engines and compares the declared @deepseek-ai/cordis peer range against the latest version, plus checks the Node engine requirement against the CI runner's Node version.
2. Layer 2 — Real install. The CI runs dsh plugin --profile <tmp> add <pkg> into a throwaway DSH_HOME profile. If the package installs cleanly (including its transitive dependencies), this layer passes.
3. Layer 3 — Config assembly. The CI runs dsh --profile <tmp> --dump-config and checks that the plugin's row appears in the assembled tree. If the loader can parse and mount the plugin's cordis.patch.yml without error, this layer passes.

A plugin that passes all three layers gets a 🟢 ok badge. A plugin that fails any layer gets a 🔴 broken badge. Plugins that haven't been checked yet show ⚪ unknown.

8.4 Badges

The catalog table and the website render each plugin's compat status as a color badge:

Badge	Meaning
🟢 ok	All three layers passed on the latest daily check.
🔴 broken	At least one layer failed. Check the CI log.
⚪ unknown	Not yet checked (usually a newly submitted plugin).
⚫ unmaintained	The plugin's repo is archived or the author has flagged it as unmaintained.

The catalog also shows each plugin's ⭐ star count and license.

8.5 Cross-linking with other directories

The dsh-suite catalog is one of several directories in the ecosystem. For maximum discoverability:

• dsh-suite — the main catalog (this one). Links to the plugin store and the website.
• dshbase — another curated DSH plugin directory.
• awesome-dsh-plugin — an awesome-list of DSH plugins and resources.
• DSH official dsh-plugin topic — tag your repo with dsh-plugin on GitHub.

Submitting to multiple directories increases your plugin's visibility across the community.

---

← Prev: Skins and Personalization · Contents · Next: Presets and Scenario Packs →