GitHub 官方 MCP 接入

为什么不用临时脚本拼 GitHub API

很多团队让 AI 代理操作 GitHub 时，习惯用临时脚本直接调用 API。这种方式的问题在于：权限边界模糊——脚本往往带着高权限 token，改主干、误合并的风险高；动作无审计——代理做了什么、改了什么，事后难以回溯；操作不规范——PR、Issue、CI 的操作逻辑分散，无法形成标准能力。

技能如何工作

该技能将 GitHub 官方 MCP 接进编程代理工作流，让“建 PR、管 Issue、读 CI”成为受控的标准操作，核心能力分四组工具：

• 仓库操作（低风险）：读文件、搜代码、列分支，仅读取仓库内容，不修改数据。
• Issue 管理（中风险）：建/改/评论 Issue、加标签，支持日常协作维护。
• PR 处理（高风险）：创建 PR、评论 PR、合并 PR，涉及主干变更需严格确认。
• Actions 操作（中风险）：读 CI 运行、重跑 CI，便于排查构建问题。

接入遵循渐进式安全原则，步骤明确：

1. 最小权限授权：用细粒度 PAT 或 GitHub App，只授予所需仓库与作用域，不随意开放全量权限。
2. 声明模式：在代理配置中声明 MCP server，明确区分只读与读写模式，避免权限滥用。
3. 渐进开放：先以只读模式验证工具可用性，确认无风险后再逐步开放写操作。
4. 高危确认：合并 PR、删除分支等高危动作，必须人工确认，不自动执行。
5. 审计日志：保留代理操作记录，便于事后回溯每一步操作。

适用边界与注意点

• 权限严格控制：token 必须最小权限，若仅需读取单个仓库，不勾选 repo 全量权限；若无需写操作，只授予只读权限。
• 防信息泄露：代理读取的 Issue、PR 内容若含内部密钥，禁止写回公开评论；避免在公开仓库暴露内部上下文。
• 敏感操作保留人工：涉及合并、强制推送等操作，必须保留人工审批环节，遵守 GitHub 使用规范与仓库保护规则。
• 避免权限滥用：不要给 MCP 开放全仓库写权限，避免代理误改主干或误合并；token 禁止提交进仓库或被日志打印。