企业官网建设流程全解析

awesome-dsh-plugin 投稿指南：一份 YAML 让 DSH 插件登上精选列表

【免费下载链接】awesome-dsh-pluginA curated list of plugins for DeepSeek Harness (dsh) · DeepSeek Harness 插件精选列表项目地址: https://gitcode.com/gh_mirrors/aw/awesome-dsh-plugin

awesome-dsh-plugin 是 DeepSeek Harness（dsh）插件的精选列表，收录所有可用dsh plugin add一键安装的社区插件。读完本文，你能让自己的 DSH 插件过掉硬性门槛、写好条目文件，并在 CI 与人工评审中顺利走完整个收录流程。

先让仓库过硬门槛

收录有几条硬要求，不达标后面全白做。开 PR 之前，先对照你的插件仓库逐项核对：

• dsh.bundle声明：package.json里必须声明dsh.bundle，monorepo 的根包或子包声明都可以。这正是插件能靠dsh plugin add安装的原因。
• 真实可用的代码：占位仓库、纯 README 仓库不收。
• 仓库年龄：创建满 1 天，由 CI 自动检查，没有提交数门槛。
• Topic 标记：给仓库加上dsh-plugintopic。
• 描述与代码一致：描述里写的工具数量、命令、API 会被逐一和代码核对，夸大是本来不错的插件被打回的主要原因。

⚠️ 只声明dsh.client是最常见的被拒原因——那样无法安装。完整的 manifest 配置示例见贡献指南 contributing.md。

把条目写进 data/plugins

列表数据全部存放在data/plugins/目录，一个插件对应一个 YAML 文件。两个 README 和官网页面都是脚本从这些文件生成的，不要手工编辑生成产物——列表增长会让行号漂移，手改容易落到邻居的行上；也正因"一个插件一个文件"，你的 PR 永远不会和别人冲突。

文件以你的仓库命名：data/plugins/<owner>__<repo>.yml。拿真实条目 1010n111__dsh-about.yml 做例子：

url: https://github.com/1010n111/dsh-about name: 1010n111/dsh-about category: ui description: en: Adds an "About" settings page to the DeepSeek Harness web interface, showing the running DSH version and recent release notes. zh: 为 DeepSeek Harness Web 设置面板添加"关于"页，展示运行中的 DSH 版本与最近更新日志。

字段上有几个要点：

• 只有description.en必填；写不了中文就不写zh，维护者会补上。
• category从ui、usage、theme、model、memory、tools、vision、voice、workflow等23 个取值里选（全集见 contributing.md）；选不准没关系，维护者会直接改，不会打回。
• monorepo 子包：url指向子目录，name写成owner/repo#subname，文件名相应为owner__repo--subname.yml。
• 描述里出现:（冒号加空格）时必须给整段加引号，否则 YAML 会把它当成嵌套键，解析直接失败。

⚠️ 一个 PR最多添加 3 条条目，超过会被 CI 直接拒绝。插件不止一个的话，拆分 PR，并且只提交"如果只能留几个，你会留下的"那几个。

想先看看生成后的效果？克隆仓库（https://gitcode.com/gh_mirrors/aw/awesome-dsh-plugin）后执行：

npm ci node scripts/generate-readme.mjs

生成脚本就是 scripts/generate-readme.mjs。

通过 CI 的四道检查

PR 提交后，CI 会按顺序跑四道检查，逻辑在 scripts/check-submission.mjs：

1. 条目数量：每个 PR ≤3 条，最先检查，早于任何网络请求；
2. dsh.bundle校验：拉取你仓库的package.json（根包，或packages/、plugins/、apps/下的子包）来验证；
3. 仓库年龄：是否满 1 天；
4. awesome-lint与站点构建：校验双语一致性、日期、截图等格式问题。

CI 挂了怎么办？报错信息会明确告诉你该改哪里——把修复推到同一分支即可，不用重开 PR。

应对人工评审

CI 通过只是前置条件，不是结论。合并前维护者会实际阅读你的插件源码，核对五件事：

• 代码是否做描述里说的事，包括其中的数字和 API 名称；
• 是否真实可用，而不是占位或空壳包装；
• 是否已被现有条目覆盖——功能重复时，"谁维护得更好"优先于"谁先来"；
• 源码里有没有可疑行为（混淆代码、凭据外传等）；
• PR 是否只动了自己的条目，夹带修改别人描述会被打回。

需要改动时，维护者会给 PR 打上held: author标签。它只是把 PR 暂停在合并队列里，不是拒绝：把修复推到同一分支、留一条评论说明改了什么，重新评审通过后标签自动摘除、PR 回到队列。

补齐截图与预构建包

以下都是可选动作，但会让插件在站点上更像"能上架的东西"：

• 截图（推荐）：在自己仓库的package.json旁边放一个screenshots.json，列出1-8 张图片路径（相对路径即可）。之后换截图只需推自己的仓库，下次构建自动生效，无需再提 PR。
• 发布 npm 包：预构建安装可跳过构建授权步骤，市场还能展示下载量；已发布包的repository字段必须指回你的插件仓库，条目里不需要任何额外字段。发不发 npm 都不影响收录。
• 主题/皮肤类插件：归入theme分类，条目会自动进入插件市场的主题 Tab，支持用户一键安装、切换、卸载。
• 预构建 tarball：仓库无法从源码安装时，在条目里加tarball:字段指向 GitHub Release 上的.tgz；用latest/download/形式时资产名不要带版本号，否则下次发版链接就会失效。

合并后的维护动作

合并后什么都不用做，README 和站点会自动重建。长期留意三件事：

• 信息要更新了？只改你自己那条 data/plugins/ 条目文件，README 是生成产物，别去手改。
• 停更条目会怎样？列表有定期扫描：仓库消失、已归档或长期停更的条目会被标记并移除，所以保持项目活跃维护。
• 不完美、没发 npm 也能上吗？能。列表不评判插件质量，只要可安装、描述属实、分类合理、持续维护，就有机会。

对照上面的门槛清单核对仓库，写好data/plugins/下的条目文件，你的第一个收录 PR 就可以开出来了。

【免费下载链接】awesome-dsh-pluginA curated list of plugins for DeepSeek Harness (dsh) · DeepSeek Harness 插件精选列表项目地址: https://gitcode.com/gh_mirrors/aw/awesome-dsh-plugin