01Before you submit: make the repo directory-ready

Submitting takes a minute, but the quality of the listing depends on the repository. Before you start, make sure:

• the repository is public — the directory only parses public metadata, so private repos cannot be listed;
• it carries the dsh-plugin topic — this is the primary recognition signal;
• the README is clear — what the plugin does, how to install it, how to use it; bilingual READMEs are even better;
• it has an open-source license — the LICENSE shows up on the detail page and tells users they can use it safely.

Add the topic with the GitHub CLI in one line:

gh repo edit owner/my-dsh-plugin --add-topic dsh-plugin

A well-structured README makes the listing far more effective. Cover at least these sections:

# my-dsh-plugin

One sentence: what this plugin does for DeepSeek Harness.

## Features
- Feature one
- Feature two

## Install
Describe the install method and requirements.

## Usage
Show a minimal working example.

02Pre-submission checklist

Step 1 gets the repository into shape; before you actually submit, spend one minute on this checklist. Tick all six boxes and both recognition and presentation go smoothly:

• the repository is public — private repositories cannot be parsed by the directory;
• the dsh-plugin topic is added — the primary recognition signal;
• package.json has name and description — the name and one-line description are the core of the detail page;
• the README explains what the plugin does — features, install steps, a minimal example;
• cordis.yml or the patch config is committed — users can load the plugin straight from the config in your repo;
• a LICENSE file is present — the license is shown on the detail page.

A minimal package.json looks like this:

{
  "name": "my-dsh-plugin",
  "description": "A TUI dashboard for DeepSeek Harness",
  "license": "MIT"
}

You can also self-check the repository state and key files from the command line:

# check visibility and topics
gh repo view owner/my-dsh-plugin --json visibility,repositoryTopics
# make sure the key files are committed
ls LICENSE package.json README.md cordis.yml

03Paste the repository URL at /submit

When the repository is ready, open the submit page on this site and paste your public GitHub repository link:

https://github.com/owner/my-dsh-plugin

No account, no extra fields — the link is the entire input. Parsing starts as soon as you submit.

04Metadata is parsed automatically

The directory extracts everything the listing needs from the repository’s public information:

• name, description, README, primary language, license, topics;
• repository signals such as maintenance activity;
• category — inferred automatically from topics, description, and README; no manual selection.

# Parsed automatically by the directory (no forms to fill)
name: my-dsh-plugin
description: A TUI dashboard for DeepSeek Harness
language: TypeScript
license: MIT
topics: [dsh-plugin, tui, deepseek-harness]

05The DSH recognition check

After parsing, the system verifies that the repository is genuinely a DeepSeek Harness plugin. Any one of the following is enough:

• the repository carries the dsh-plugin GitHub topic (the primary, recommended way);
• the repository declares a dsh bundle;
• the README or repository description clearly states it is a DeepSeek Harness plugin.

If recognition fails, the page prompts you to add the dsh-plugin topic and try again — the fastest and most reliable fix.

06Instant publish and your detail page

Once recognition passes, the plugin is published instantly — there is no review queue. It immediately gets its own detail page at a route like:

/plugins/[slug]

The detail page shows the full README, repository signals (license, maintenance activity, and more), and installation instructions. The plugin also appears in the plugin directory, searchable and browsable by category.

07After submission: sync and rate limits

Publishing is not the end — the directory keeps syncing with your repository:

• updates sync automatically — when you push a new README, topics, or release, the directory refreshes with the sync task; curated data syncs every 6 hours, and self-submitted plugins publish instantly;
• submitting too often is rate-limited — repeated submissions in a short window trigger a limit, and the page asks you to retry in an hour.

08Updating after submission

Once your plugin is live, updating it does not require resubmitting: keep pushing to the same GitHub repository. The directory re-reads the repository’s public metadata during its sync task, so changes to the README, description, topics, and releases flow through to the detail page.

• editing the README or repository description — edit it directly on GitHub and wait for the next sync;
• shipping a new version — after you push code and publish a release, the directory refreshes with the sync task;
• changing the category — just edit the topics; the category is inferred from topics, description, and README.

If you spot incorrect information in the directory, or need to request removal of a listing, open an issue at the directory’s GitHub repository issues. Authors can also simply make the repository private or remove the dsh-plugin topic — the directory only parses public metadata, and the change takes effect with the sync cycle.