前言¶

在 DSH 里做仓库改动时，常见做法是自己在会话里描述需求、改代码、再手动开 PR。需求若来自 GitHub Issue，还要在 Issue、本地 checkout 和 DSH 会话之间来回对齐分支与上下文；审查意见或 CI 失败后，往往要重新整理「上次做到哪了」。若希望 Issue 作任务入口、PR 作交付入口，且验收通过才推送，就需要把 GitHub 与 DSH 串成可重复的一圈循环。

下面介绍社区插件 dsh-github-harness（维护者 yintaocheng，分类：工作流）。它在 DeepSeek Harness 中提供工具 github_harness，把「Issue → DSH 实现 → 独立验收 → Pull Request」跑通；同一 Issue 可凭评论与 CI 反馈续跑，无需每次重开任务。

这是什么¶

dsh-github-harness 是面向 DeepSeek Harness 的可复用插件与 CLI：在目标 Git 仓库（不必包含插件源码）里，按 Issue 管理分支、DSH 会话和 PR，形成单智能体任务环。README 概括为：让 GitHub Issue 成为 DSH 的任务入口，让 PR 成为代码交付入口。

Issue → DSH 实现 → 独立验收 → Pull Request
  ↑                              │
  └────── 修改意见 / CI 反馈 ──────┘

插件当前版本 v0.3.0（见仓库 package.json），许可证 MIT，属于 DeepSeek Harness 社区插件；目录页见 SkillHub，源码见 GitHub。

核心功能¶

以下能力均来自项目 README，安装前可对照仓库文档核对。

• 按任务管理上下文：每个 Issue 使用独立分支、DSH 会话和 PR。
• 持续处理反馈：读取 Issue 评论、PR 审查和 CI 结果，对同一 Issue 续跑。
• 先验证，再发布：验收失败不推送；没有代码变更时不创建空 PR。
• 支持多个项目：插件只需安装一次，调用时通过 workdir 选择目标仓库；同一 checkout 中的任务串行执行。
• 保留人工审查：稳定版不自动批准或合并 PR。

安装与启用¶

环境要求：DeepSeek Harness 0.2.0-rc.2、Node.js 22+ 和 Git（与 package.json 中 engines 及 README 一致）。

在 DSH 的 Plugins → Add plugin 中输入官方安装串：

github:yintaocheng/dsh-github-harness#v0.3.0

安装后启用插件，按宿主提示完成重启。注册到宿主后的工具名称为 github_harness。CLI 安装与桌面端细节见仓库 docs/desktop.md。

典型用法¶

1. 准备目标项目¶

打开一个已有基线提交的 Git 仓库，确保 HTTPS origin 指向你有写权限的 GitHub 仓库。Windows 可通过 Git Credential Manager 登录：

git credential-manager github login --browser

其他凭据方式见仓库 认证配置。同时确认 DSH 的 headless 模型可用。

2. 配置验收¶

在目标仓库根目录新建 harness.local.json：

{
  "owner": "YOUR_ACCOUNT_OR_ORG",
  "repo": "YOUR_PROJECT",
  "base": "main",
  "agent": { "id": "solo", "expectedLogin": "YOUR_GITHUB_LOGIN" },
  "dsh": { "command": ["dsh", "headless"] },
  "verify": [["node", "--test"]]
}

替换 owner、repo、expectedLogin 和 verify 中的验收命令。Windows 若 PATH 中找不到 dsh，将 dsh.command 首项改为桌面自带 dsh.cmd 的绝对路径。完整字段说明见 配置示例。

将本地配置与运行状态排除出版本库：

harness.local.json
.harness/
.reference/

3. 运行一个 Issue¶

在 GitHub 创建 Issue，写清需求、范围和验收条件。在 DSH 中可以用自然语言驱动，例如：

用 github_harness 检查 my-project 的配置，然后处理该仓库的 Issue #42。

也可以直接调用工具（JSON 参数）：

{"action":"doctor","workdir":"my-project"}
{"action":"run","issue":42,"workdir":"my-project"}
{"action":"status","issue":42,"workdir":"my-project"}

workdir 可以是绝对路径，或相对当前 DSH 会话工作区。PR 创建后，在 Issue 或 PR 留下反馈，再对同一目录和 Issue 执行 run 即可续跑。

doctor 会检查身份、仓库读取能力和 DSH 命令；它不会替你创建仓库，也不会验证所有写权限。GitHub 配置必须匹配目标 checkout，不要通过复制任务缓存切换仓库或账户。

适用场景与注意¶

适合：已在用 DSH 做代码修改、希望 Issue/PR 成为唯一任务与交付界面、且能在本地配置验收命令（如 node --test）的团队或个人。

权限与安全：工具需要宿主授权的文件、进程和网络访问，并以当前 DSH 进程权限运行；agent、测试与 Git hooks 都可能执行目标仓库中的本地代码。安装前应阅读源码与 MIT 许可证，仅用于可信仓库。

生态说明：DeepSeek Harness 的理念是「一切皆插件」；SkillHub 等社区目录为独立站点，与 DeepSeek / 幻方无官方从属关系，本文不以「官方应用商店」表述。

更多说明见仓库文档：安装与凭据、命令与续跑、演示项目 dsh-github-harness-demo。

结尾¶

dsh-github-harness 把 GitHub Issue 与 PR 固定为 DSH 单智能体工作流的入口与出口：验收通过才推送，反馈留在 Issue/PR 即可续跑同一任务。若你正在 DSH 里维护多仓库改动，可按上文安装串与 harness.local.json 在目标仓库试跑一个 Issue。

• 目录页：https://www.skillhub.cn/plugins/yintaocheng/dsh-github-harness
• GitHub：https://github.com/yintaocheng/dsh-github-harness