企业官网建设流程全解析

DSH 插件收录一次通过：awesome-dsh-plugin 投稿审查实战指南

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

盯这个列表的评审队列盯久了，见得最多的两个问题是：CI 红了不知道为什么红；CI 全绿了却没合并。原因并不复杂——DSH 插件收录要过两层漏斗：一层是机器，四道固定检查；一层是人，维护者会读你的源码、对照条目描述。仓库达标、YAML 写对，一次就能过。本文回答的就是"DSH 插件如何上架"这一件事，按两层漏斗逐个过一遍实际评审规则，并标出被拒 PR 最常栽的位置。所有条目最终都要能用dsh plugin add装起来，所以审查非常直白：描述里说的话，代码里必须有。

插件 PR 被拒的 4 个最常见原因

本节帮你避开最高频的打回点。四件事都有明确的"不碰"边界，碰上的代价是一整轮重新评审。

缺dsh.bundle或写错（头号拒因）。这是最常见的一条：package.json里只声明了dsh.client而没声明dsh.bundle，那样用户根本装不起来。完整形态长这样，旁边再放一个对应的 patch 文件即可：

{ "dsh": { "bundle": { "patch": "./your.patch.yml" } } }

monorepo 在子包里声明也可以，但条目url必须指到那个子目录，指向仓库根等于装个空气。

空壳仓库。占位仓库、纯 README 仓库不收；只把一组别的插件打包、自己不带任何行为的纯聚合包也不收。注意区分：聚合包如果自己做事——合成配置、提供设置面、运行时协调各部分——它就是普通插件，按普通标准审。

仓库年龄与维护状态。仓库创建要满 1 天，没有提交数门槛。另外列表有定期扫描，仓库消失、归档或长期停更的条目会被标记并移除。

描述夸大。唯一的"非技术性"拒因，但出现频率最高。写"46 个工具、六大领域"，代码里就得恰好 46 个、6 个；提到的命令和 API 名必须真实存在。我见过不少各方面都合格的 PR，就栽在一个数字不成立上——改掉那一行就收录了。

投稿 YAML 条目怎么写才一次写对

本节解决"唯一要写的文件"怎么写的问题。投稿的全部形态就是data/plugins/下一个新文件，命名owner__repo.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. zh: 为 DeepSeek Harness Web 设置面板添加“关于”页。

值得记下的规则：

• description.en是唯一必填项，zh写不出来就留空，维护者会补，这是评审方的活
• 描述含:（冒号加空格）时整段加引号，否则 YAML 会把它当嵌套键，直接解析失败
• 分类从ui、usage、theme、memory、tools、voice、git、security等 22 个里挑最贴近插件实际行为的；挑得不够准，维护者会直接改，不会打回
• monorepo 子包写name: owner/repo#subname，文件名相应改为owner__repo--subname.yml
• 一个 PR 最多加 3 条，超了 CI 直接拒。插件不止一个的话，拆成多个 PR，只投质量最好的几个

提交前想预览效果，克隆https://gitcode.com/gh_mirrors/aw/awesome-dsh-plugin后依次运行npm ci和node scripts/generate-readme.mjs即可。

CI 检查流程：机械四关按这个顺序跑

本节讲清四道机械检查的顺序与含义，CI 红了能立刻定位卡在哪一关。逻辑在 scripts/check-submission.mjs：

第三关是唯一可以"等一等"的失败：gate 的结论是快照，过期判定会自动重跑。不需要重开 PR，也不需要推空提交去触发。

红了之后的标准动作三步：

1. 报错会精确到文件和字段，读完再动手，它说改哪里就改哪里
2. 把修复推到同一分支，无需重开 PR
3. 若是人工侧打回（held: author标签），改完留一条评论说明改了什么，这是唯一需要的信号

人工评审：维护者真正在看什么

本节回答"CI 绿了为什么不合并"。CI 绿只说明形式过关，合并前维护者会实际读目标仓库，对照五件事。

描述与代码。描述里的每个数字、命令、API 名都被当作声明逐条核对，这是收录审查的核心，也是打回的核心。

真与壳。是可用代码，还是包住空气的包装？只指向别行、自身不产出信息的聚合条目不占位——收插件，不收聚合包。

重复度。已有条目做同一件事时，规则不是先来后到，而是谁维护得更好谁占位；维护更好的分叉同样可以被收录。

源码可信度。混淆代码、凭据外传、异常的安装期行为都会被打回。要说明的是，收录不等于做过安全审查，这是常识性检查而非审计。

PR 边界。更新自己插件的 PR 不该顺手改写别人的描述。这类问题曾两次通过全部机械检查溜过去，现在 gate 会列出 PR 改动的每一个既有条目供追问。

反馈以 PR 评论给出，明确到要改哪一行。因描述不准确被打回，不是否定插件本身。完整评审标准见 contributing.md 的评审一节。

合并之后：让条目和市场页不腐化

本节收四类可选配置和几条保鲜规则，全部可以在收录后随时补。

• 截图（推荐）：在自己仓库的package.json旁放一个screenshots.json，列 1-8 个图片相对路径。之后换截图只推自己的仓库，市场页下次构建自动生效，不必再提 PR
• 发 npm（可选）：预构建安装跳过构建授权步骤，市场能展示下载量；已发布包的repository字段必须指回插件仓库才会关联。发不发都不影响收录
• 预构建 tarball（兜底）：仓库无法从源码安装时，条目加tarball:指向 Release 上的.tgz。资产名别带版本号——latest/download/只对latest做解析、文件名按字面取，带版本下次发版就 404
• 主题/皮肤类：归入theme分类，条目自动进入插件市场主题 Tab，支持一键安装、切换、卸载

保鲜两条：保持项目活跃，停更条目会被扫描机制移除；要更新插件信息，只改自己那条 yml，两个 README 和官网都是合并后自动重建的，手工编辑 README 是踩雷高发区。

提交前把四个拒因和 YAML 字段规则对照过一遍，剩下的交给机器验形式、人验内容——CI 不会冤枉任何人，人工评审只查一件事：描述是否成立。

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