Submit a DSH plugin
Listings here are generated from public repository data and reviewed by hand. If you maintain a DeepSeek Harness plugin, the fastest path is to add the dsh-plugin topic and submit the URL.
- 01
Publish the repository
Make the plugin public and add the dsh-plugin topic so directories that scan GitHub discover it automatically. Include a LICENSE file and a README with the exact install command.
- 02
Declare compatibility
State the harness release you tested against in your dshTarget field and repeat it in plain language in the README, including what fails on older releases.
- 03
File the listing request
Submit the repository URL with a one sentence description under 160 characters and the install command you want shown. An agent can file this for you through the submission API below; by hand, it is one issue form.
- 04
Review and listing
Submissions are checked for source, install spec accuracy, permission surface and maintenance signals. A listing appears once those four checks pass, usually the same week.
How to submit
Two channels, one queue. Both end as a public issue in the submissions repository, where the review — and its verdict — stays visible. Submissions are not taken by email.
With your agent — the intended path
If an AI agent helps you build the plugin, it files the submission for you. The submit-dsh-plugin skill checks the repository against the review checklist below and POSTs the fields to the intake API; any other agent can do the same directly:
curl -X POST https://www.alldsh.com/api/submit \
-H 'Content-Type: application/json' \
-d '{"repo": "owner/repo",
"tagline": "One sentence, under 160 characters.",
"install": "dsh plugin --profile web add your-package",
"categories": ["skills-agents"],
"notes": "Needs an API key; writes only to ./cache."}'The intake re-checks the mechanical items itself — public repository, dsh-plugin topic set, not archived, no open duplicate — and answers in JSON with the URL of the public review issue. A GET on the same URL returns the machine-readable contract, so an agent can discover the payload shape without reading this page.
By hand
The same five fields, as a GitHub issue form. There is no fee, and maintainers get the same review as anyone else.
The five things a submission carries
- Repository URL
- One sentence description, under 160 characters
- Exact install command
- Category you think fits best
- Notes for reviewers: credentials required, paid endpoints, or unusual permissions
Corrections or removals of an existing listing: contact page.
Review checklist
These are the six things checked before a listing appears. A submission missing any of them is usually returned with a note rather than rejected.
- Public repository with visible commit history
- dsh-plugin topic added to the repository
- LICENSE file present at the root
- README contains a copy-ready install command
- dshTarget declared, matching the release you tested
- Optional: exact version pin documented for reproducibility
What a listing does not mean
A listing is not an endorsement, and it is not a security guarantee. It records what was checked: the source, the install spec, the verification level and the maintenance signals. Users are still expected to read the permission surface before installing, which is exactly what the listings are built to make easy.
Common reasons a submission is returned rather than published: the install command does not resolve against the published package name; the repository has no public source; the description is marketing copy with no capability statement; or the plugin needs credentials with no documented storage story. Fix those and resubmit — a returned submission is a note, not a ban.
Read the editorial policy and the verification rules for the full criteria, or see the publishing guide for how to prepare a repository that passes review.