Contributing to DSHPlugin

August 14, 2026 ยท View on GitHub

Thanks for helping make the DeepSeek Harness plugin ecosystem easier to discover and explore. Contributions in English or Chinese are welcome.

Before you start

  • Search existing issues and pull requests before opening a duplicate.
  • Use an issue for changes that alter discovery sources, ranking, the catalog schema, or the moderation workflow.
  • Use GitHub private vulnerability reporting for security issues; do not open a public security issue.
  • Never include credentials, personal contact details, Cloudflare identifiers, production database IDs, or copied production data.

Development setup

npm ci
npm run dev

Run the complete check suite before opening a pull request:

npm run verify

When your change affects catalog sources or links, also run:

npm run check:catalog-links

This command performs live GitHub checks and therefore requires network access.

Working with the catalog

  • src/data/awesome-catalog.generated.json is generated. Do not hand-edit it.
  • public/catalog/github-topic.generated.json is generated from public repositories carrying the dsh-plugin topic. Do not hand-edit it.
  • Update the snapshot with npm run sync:catalog.
  • Repository imports must resolve to a canonical, publicly reachable GitHub repository.
  • Automatic GitHub discovery requires a root package.json with dsh.bundle.patch pointing to a real repository file.
  • GitHub stars are refreshed by the generated catalog workflow; do not hand-edit popularity values.
  • Treat stars as a discovery signal, never as a security, quality, or endorsement claim.
  • Installation commands must only be shown for entries that DSH can actually install.

If you only want to propose a plugin, the plugin submission issue form is the easiest route.

Commit convention

DSHPlugin uses Conventional Commits:

<type>(optional-scope): <short imperative description>

Common types:

  • feat: a user-visible capability
  • fix: a bug or incorrect behavior
  • docs: documentation only
  • refactor: an internal change without behavior changes
  • test: tests only
  • perf: a performance improvement
  • build: build or dependency changes
  • ci: continuous integration changes
  • chore: repository maintenance

Examples:

feat(catalog): add repository language filters
fix(links): follow canonical GitHub redirects
docs: explain GitHub discovery sources

Use ! or a BREAKING CHANGE: footer for breaking changes.

Pull requests

Keep pull requests focused. A good pull request:

  • explains the user or maintainer impact
  • includes tests for changed behavior
  • updates translations when visible copy changes
  • does not weaken Cloudflare Access or Worker-side admin checks
  • contains no generated build output, local configuration, or secrets
  • uses a Conventional Commit-compatible title

By contributing, you agree that your contribution is licensed under the MIT License.