前言¶

DSH 的宿主进程已经能跑工具调用和技能，但如果你维护的是一个 Hugo 站点，通常还缺一段：新建文章、改 Front Matter、跑一次构建检查、确认后推送发布。这些动作要么手工在终端里敲一堆 hugo / git 命令，要么让智能体直接拿到 shell，风险和可控性都不稳定。下面介绍的插件就是把这个链路包成一层工具，让智能体有明确接口可用，同时在侧边栏保留可视化操作入口。

这个插件是 dsh-hugo-blog，维护者 ruoshui6662，作用是给 DSH 宿主补充 Hugo 博客的写作、构建检查、清单与发布回执能力。它不替代 Hugo 本身，也不负责 CI workflow，只负责把「内容 → 构建 → 发布确认」这一段接进插件体系。

定位与维护¶

插件定位一句话：Hugo 博客写作、发布、维护与推送的工具层。维护者是 ruoshui6662，源码托管在 GitHub 的 ruoshui6662/dsh-hugo-blog，包版本 0.1.0，许可证 MIT。运行时要求 Node >= 22，宿主 dsh 版本要求 >=0.2.0-rc.1 <0.3.0-0。

它只使用 Node 内置模块，零第三方依赖，也不声明 peerDependencies。运行时依赖由宿主提供：ctx.tools.register、ctx.skills.registerProvider，具体落到 dsh-tools / dsh-skill 等服务。

核心功能¶

插件提供的能力分两块：侧边栏面板和一组工具。

面板在侧边栏注册 Hugo 博客 入口，按固定顺序操作：

1. 站点目录：选择目录（原生目录选择器或手动输入路径）后点「载入站点」。目录须含 hugo.toml 等配置与 content/，是否 git init 不影响识别。目录会被记住，下次自动载入。
2. 站点状态：分支、草稿数、工作区是否干净、改动文件列表。
3. 文章列表：切换「草稿 / 未来 / 已过期 / 全部 / 已发布」，点一行填入编辑区。
4. 新建文章：按 posts/hello.md 形式创建，或新建 Page Bundle。
5. 编辑 Front Matter：标题、草稿、标签、分类、日期、定时发布、过期下架、Slug；保存后回显 lint 结果。
6. 构建与发布：先跑 hugo build 检查，再两步确认发布。构建失败或工作区脏会被拒绝。

工具侧暴露的接口是：

• hugo_new_content
• hugo_edit_frontmatter
• hugo_new_pagebundle
• hugo_build_check
• hugo_list
• hugo_publish
• git_status_summary

另外附带一个技能 hugo-blog。更细的实现说明在仓库的 docs/DETAIL.md。

一个需要留意的行为：hugo_publish 会产生 git 写操作，宿主策略可以要求审批。也就是说发布不是静默完成的。

面板本身只调 Host 的 /api/hugo-blog/* 路由，所有 hugo / git 执行都在 Host 进程内完成，前端不直接碰文件系统。

安装与启用¶

README 里给出的安装命令是本地路径方式：

dsh plugin --profile web add ./dsh-hugo-blog

如果是从 Git / npm 安装本包，则需要在 cordis 补丁中插入 id=hugo-blog、name=dsh-hugo-blog。仓库内提供了 cordis.patch.yml，package.json 里的 dsh.bundle.patch 字段指向它。

这里能看到一个容易踩的点：使用打包命令时，本插件主要面向 web profile（package.json 的 dsh.client.platform 也写的是 web）。而 README 的已知限制里说明，插件按 profile 隔离安装，桌面 GUI 用 desktop profile，CLI-headless 用它自己的 profile，装在哪个 profile 只有那个实例可见。所以如果你的部署切在另一个 profile，需要按对应实例重新装一次。

典型用法¶

装好后，先看一遍面板流程即可完成日常操作。如果想走工具调用路径，顺序大致是：

1. 在面板选择站点目录并载入，确认站点状态里的分支和工作区状态。
2. 用 hugo_new_content 或 hugo_new_pagebundle 建内容。
3. 用 hugo_edit_frontmatter 改标题、标签、日期、定时发布等字段。
4. 用 hugo_build_check 跑构建检查。
5. 用 hugo_list 确认文章落位。
6. 用 hugo_publish 发布，按宿主审批策略等待确认。

发布这一步如果宿主策略要求审批，hugo_publish 的 git 写操作会先停下来等人工同意，这是设计好的保护，不是卡住。

面板侧则可以直接在「文章列表」里挑一行进编辑区改 Front Matter，保存时会看到 lint 结果；这一步的价值在于发布前能立刻知道字段是否合法，不用等构建报错才发现。

适用场景与注意¶

适合两类人：一类是在 DSH 里维护自己 Hugo 博客、希望写作到发布都在一个流程里完成的开发者；另一类是给团队搭智能体工作流、需要把内容发布动作收敛到插件工具而不是自由 shell 的人。

使用前需要确认几件事：

• 插件以当前 dsh 进程权限运行，能在站点目录里读写文件和执行 git。安装前先检查源码与许可证（MIT）是否符合你的要求。
• Hugo 构建缓存目录必须可写（HUGO_CACHEDIR），沙箱环境下要确认缓存目录权限。
• GitHub Pages 部署默认走「push → Actions」，CI workflow 需要在仓库侧自备，插件不提供。
• profile 隔离意味着同一个插件装在不同实例上互不可见，部署前确认目标 profile。

结尾¶

这个插件解决的不是 Hugo 本身的问题，而是把 Hugo 站点的日常维护动作接进 DSH 工具体系，让智能体有明确的注册接口可用，让发布带着构建检查和审批闸门。功能集中、依赖很少，适合自己跑 Hugo 站点的人直接装来试。

• 目录页：https://www.skillhub.cn/plugins/ruoshui6662/dsh-hugo-blog
• GitHub：https://github.com/ruoshui6662/dsh-hugo-blog