用于GitHub 集成的 DSH 插件

大多数 DSH 插件源码和大多数团队工作本来就放在 GitHub 上，所以这个使用场景涵盖代码仓库浏览、议题与拉取请求工作流、审查评论，以及在会话中驱动的发布自动化。本目录已收录的条目更偏本地 git，而不是完整的 GitHub API 客户端：有用的那些会在聊天旁展示 diff、历史与提交状态，让改动在离开本机之前先被看见。

有用的区分是读和写。浏览仓库或读取 diff 几乎不需要额外信任。会发表评论、创建拉取请求或推送分支的插件，应当被限定在单个仓库上，并使用你可以随时吊销的 token。任何索要宽泛 repo 权限的工具，都值得暂停，而不是当成方便。

怎么评估

安装前看三件事。第一，写入面：插件实际暴露了哪些 git 或 GitHub 动词，其中有没有推送。第二，凭证处理：密钥应落在模型无法整段读进对话记录的配置或环境里。第三，可审查性：提交、暂存补丁或可见 diff 可以复核；静默的 git push 不行。

只读仓库状态的插件是安全底线。会改写远程的插件，应当在执行前展示确切命令或 API 调用，并默认 dry-run 或审批门槛。

什么样算好

强的 GitHub 向插件把远程操作做成显式步骤：智能体先提出改动，你看到 diff，然后才提交并可选推送。状态会诚实区分已暂存、已提交与已推送。议题/PR 助手要么使用范围收窄、可吊销的 token，要么干脆拒绝写入，只准备补丁由你自己开 PR。

本目录在这一场景覆盖偏稀疏不是类目缺陷，而是信号：带议题自动化的完整 GitHub API 客户端在 DSH 生态里仍少；今天多数「集成」是本地 git 加一个浏览器标签页。

常见失败

常见失败是插件自称「GitHub 集成」，实际只做 clone 加 shell 命令。第二种是写入路径把 PAT 嵌进模型能读到的配置。第三种是把 star 数或提交频率当成集成安全的证明：社区规模不会替你收窄 token 权限。

安装顺序与边界

GitHub 类先只读与最小 issue 范围。写操作（评论、PR、合并）应在隔离 profile 里验证过，再放进日常工作流。