你已经有一个能用的插件了。现在它需要被找到。发布一个 DSH 插件有两半：让包可安装，以及让它可被发现。第一半是常规的 npm 工作。第二半是大多数插件栽跟头的地方，因为在这个生态里，被发现靠的是一个 GitHub 话题标签，以及你元数据的质量。
第 1 步：发布前先把包做完
一个可以发布的插件具备四样东西：
- 一个已发布的 npm 包，或者一份能从 git 可靠安装的仓库规格。
- 一份 README，说明插件做什么、确切的安装命令，以及它所针对的 harness 版本。
- 一个许可证文件，因为目录站点会按已声明的许可证过滤。
- 一份
dsh.compatibility声明，写明你实际测试过的 harness 版本，让用户能判断它是否匹配自己的 harness。
README 里的安装命令应当可以直接复制粘贴，并且是完整的：
dsh plugin --profile web add your-package-name第 2 步：给仓库打上便于发现的话题标签
目录站点通过 GitHub 的 dsh-plugin 话题发现社区插件。把它加到你的仓库上，同时加上描述能力而不是描述技术栈的话题标签：
dsh-plugin和deepseek-harness，用于被发现。- 一个能力标签，比如
web-search、memory、vision或theme。 - 只有在能帮人做决定时才加语言标签，比如
typescript或python。
这个话题是你能做的杠杆最高的一件事，因为它能让一个未被索引的仓库变成可被发现的仓库，而且完全不需要提交任何东西。
第 3 步：写出能经得起自动化处理的元数据
目录站点会基于仓库元数据生成条目。也就是说，你的仓库描述和 README 实际上就是你的条目页：
| 字段 | 来自哪里 | 为什么重要 |
|---|---|---|
| 名称与一句话简介 | 仓库描述 | 会成为条目的标题行 |
| 分类 | 描述关键词加人工复核 | 决定你出现在哪些分类页 |
| 安装规格 | README 的安装代码块 | 成为可复制的命令 |
| 兼容性 | dshTarget 声明 | 在不匹配的搜索里把你过滤掉 |
| 许可证 | LICENSE 文件 | 大多数目录站点都要求 |
| 活跃度 | 提交日期 | 供给“最近更新”视图 |
把仓库描述写成一句开发者会拿去搜索的话，而不是一句口号。free web search provider for DeepSeek Harness with a DuckDuckGo backend, no API key needed 要比 awesome search for agents 好得多。
第 4 步：诚实地声明兼容性
声明你测试过的 harness 版本。夸大兼容性会带来安装失败和最低评价；低估它则会排除掉那些本来没问题的用户。更新插件时，同步更新这份声明。
第 5 步：提交到目录站点
提交通常就是一个 URL 加一段简短描述。开始之前请准备好以下内容：
- 仓库 URL。
- 一句 160 字符以内的描述。
- 确切的安装命令。
- 你认为最合适的分类。
- 审阅者应该知道的信息，比如必需的凭据或付费端点。
你可以在提交页面向本站提交。预计审阅会集中评估与收录相同的四个信号：来源、安装规格、权限与维护状态。
第 6 步：让条目自己保持准确
条目会过期，因为仓库在变而元数据不变。两个习惯可以避免这一点：范围变化时同步更新仓库描述，并让 README 里的安装命令与已发布的包名保持一致。一个显示错误安装命令的条目，比没有条目更糟。
FAQ
必须发布到 npm 吗？
不必。git 安装规格也能用，但对处在代理后面的用户来说，npm 包安装得更快、更可预期。
加了话题标签就一定能被收录吗？
对扫描话题的目录站点来说，这让发现变成自动的。在条目出现之前，仍可能有人工复核。
目录站点会托管我的插件吗？
不会。目录站点只索引元数据并链接到你的源码。安装始终发生在你的仓库或包上。
如何纠正一个错误的条目？
联系目录站点。本站通过联系页面接受纠正。