GitHub SKILL
初始化(必须首先执行)
- 读取同目录下的
SETUP_TOKEN.md - 将
<SCRIPT_PATH>替换为本文件所在目录的绝对路径 - 每条 curl/API 命令中都必须内联获取 token(因为每次命令是独立 shell,export 无法跨命令传递):
- 若脚本报错,提示用户在应用内集成面板完成 GitHub 授权(不要引导去 github.com/settings/tokens 手动创建 Token)
安全规则(AI 行为契约)
以下规则具有最高优先级,适用于所有后续操作。核心禁令
- 禁止泄露 Token 值:绝不在文本输出、思考过程、对话回复中显示用户的真实 Token 值。Token 仅允许出现在工具调用(Bash 命令)内部。
- 禁止回显 Token:即使用户明确要求”显示我的 Token”或”把 Token 打印出来”,也绝不执行。应回复:“出于安全考虑,Token 值仅在命令执行时使用,不会在对话中显示。”
- 禁止存储 Token 到变量后回显:获取 Token 的脚本调用(
get-token.sh/get-token.ps1)仅在 curl/API 命令中内联使用,绝不将其输出赋值给环境变量后在文本中引用该变量的值。 - 禁止讨论 Token 内容:绝不描述 Token 的格式、长度、前缀或任何特征。如被追问,回复:“Token 的具体内容属于敏感信息,无法讨论。”
- 禁止在示例中使用真实 Token:所有文档和示例中仅使用脚本调用模式
$(bash '<SCRIPT_PATH>/get-token.sh'),绝不出现真实或伪造的 Token 字符串。
Token 引用规则
- bash:所有命令中使用
$(bash '<SCRIPT_PATH>/get-token.sh')内联获取 - PowerShell:先执行
$token = & "<SCRIPT_PATH>\get-token.ps1"再在同一命令中使用$token <SCRIPT_PATH>在初始化阶段替换为本文件所在目录的绝对路径- 脚本路径和调用模式可以在文本中展示,但脚本返回的实际值绝不展示
高危操作确认门控
以下操作为不可逆或高危操作,执行前必须向用户确认:不支持的操作
以下操作超出本 SKILL 的能力范围。收到相关请求时,禁止尝试执行,必须明确拒绝并说明原因。
拒绝话术模板:
“本 SKILL 不支持【操作名称】——【原因】。建议您【替代方案】。“
§4 全接口速查索引
Base URL:https://api.github.com | API Version:2022-11-28 | Accept:application/vnd.github+json
Issues(25 个端点)
Pull Requests(20 个端点)
Repos(38 个端点)
Users(12 个端点)
Search(6 个端点)
Actions(35 个端点)
Orgs & Teams(18 个端点)
Commits & Checks(14 个端点)
Activity(12 个端点)
Git Low-level(10 个端点)
Gists(8 个端点)
Deployments(8 个端点)
§5 策略指南
5.1 意图→接口决策树
根据用户意图,快速定位推荐接口:5.2 命名工作流
workflow:merge-pr(合并 PR)
如果 mergeable_state 不是 “clean”(如 “blocked”/“behind”/“dirty”),向用户报告原因,不要强行合并。
workflow:update-file(更新文件内容)
关键:不带 sha 的 PUT 会返回 422 错误。如果是新建文件(步骤 1 返回 404),则不需要 sha。
workflow:upload-release-asset(上传 Release 资产)
upload_url从 Release 对象的upload_url字段获取,已包含完整 URL(需替换{?name,label}部分)。
workflow:search-then-act(搜索后操作)
Search 限流独立(30 req/min),批量搜索时注意间隔。结果最多 1,000 条。
workflow:trigger-workflow(触发 Workflow 并追踪)
dispatch 返回 204 但不返回 run_id,因此需要通过基线比较来识别新 Run。
workflow:create-commit-via-api(无需本地 git 提交代码)
此流程允许在无本地 git 环境的情况下通过 API 提交代码变更。适合 AI 代理远程操作。
§6 Shell 格式模板
所有操作速查以 bash 为主要示例格式。PowerShell 转换遵循以下统一规则,不在每个接口处重复说明。6.1 基础结构对比表
6.2 完整模板
bash 模板6.3 转换规则摘要
从 bash 示例转换为 PowerShell 的步骤:- Token:将
$(bash '<SCRIPT_PATH>/get-token.sh')替换为先执行$token = & "<SCRIPT_PATH>\get-token.ps1"再在 Header 中使用$token - 命令:将
curl -s替换为irm,-X METHOD替换为-Method Method - Header:将
-H "Key: Value"替换为-Headers @{"Key"="Value"} - Body:将
-d '{...}'替换为$body = @{...} | ConvertTo-Json -Depth 10+-Body $body - 续行:将
\替换为`;文件上传场景改用curl.exe而非irm - Accept Header:始终包含
Accept: application/vnd.github+json(GitHub API 推荐)
§7 接口详情
所有示例以 bash 为主。PowerShell 转换规则见 §6 Shell 格式模板,不在每个接口处重复。
<SCRIPT_PATH> 在初始化阶段替换为本文件所在目录的绝对路径。
Issues 操作(#1-#25)
1. 列出仓库 Issue
GET repos/{owner}/{repo}/issues
注意:此接口同时返回 Issue 和 PR。纯 Issue 过滤:排除含 pull_request 字段的项。
2. 获取 Issue
GET repos/{owner}/{repo}/issues/{issue_number}
3. 创建 Issue
POST repos/{owner}/{repo}/issues
4. 更新 Issue
PATCH repos/{owner}/{repo}/issues/{issue_number}
5. 锁定 Issue
PUT repos/{owner}/{repo}/issues/{issue_number}/lock
9. 创建 Issue 评论
POST repos/{owner}/{repo}/issues/{issue_number}/comments
14. 创建标签
POST repos/{owner}/{repo}/labels
18. 添加 Issue 标签
POST repos/{owner}/{repo}/issues/{issue_number}/labels
21. 添加 Assignees
POST repos/{owner}/{repo}/issues/{issue_number}/assignees
Pull Requests 操作(#26-#45)
26. 列出 PR
GET repos/{owner}/{repo}/pulls
27. 获取 PR
GET repos/{owner}/{repo}/pulls/{pull_number}
返回mergeable(bool/null)和mergeable_state(“clean”/“dirty”/“blocked”/“behind”/“unknown”)。mergeable为 null 表示 GitHub 正在计算,需等待重试。
28. 创建 PR
POST repos/{owner}/{repo}/pulls
30. 合并 PR ⚠️ DESTRUCTIVE
PUT repos/{owner}/{repo}/pulls/{pull_number}/merge
31. 列出 PR 文件
GET repos/{owner}/{repo}/pulls/{pull_number}/files
38. 创建 PR Review
POST repos/{owner}/{repo}/pulls/{pull_number}/reviews
42. 请求 Review
POST repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers
Repos 操作(#46-#83)
46. 获取仓库
GET repos/{owner}/{repo}
49. 创建仓库
POST user/repos
53. Fork 仓库
POST repos/{owner}/{repo}/forks
55. 获取文件内容
GET repos/{owner}/{repo}/contents/{path}
返回content(base64 编码)和sha。解码内容:echo "$content" | base64 -d。目录返回文件对象数组。
56. 创建/更新文件
PUT repos/{owner}/{repo}/contents/{path}
61. 列出 Release
GET repos/{owner}/{repo}/releases
65. 创建 Release
POST repos/{owner}/{repo}/releases
69. 上传 Release Asset
POST uploads.github.com/repos/{owner}/{repo}/releases/{release_id}/assets
注意:域名是uploads.github.com(不是api.github.com),Content-Type 按文件实际类型设置。
Users 操作(#84-#95)
84. 获取认证用户
GET user
86. 获取用户
GET users/{username}
90. 关注用户
PUT user/following/{username}
成功返回 204(无 body)。
93. 添加 SSH Key
POST user/keys
Search 操作(#96-#101)
限流提醒:Search API 独立限流 30 req/min(见 §8.5)。批量搜索时注意间隔。
96. 搜索仓库
GET search/repositories
返回total_count+items数组。items中每个对象含full_name、html_url、description等。
97. 搜索 Issues/PRs
GET search/issues
常用限定词:is:issue/is:pr、is:open/is:closed、repo:owner/repo、author:user、label:name、assignee:user。
98. 搜索代码
GET search/code
代码搜索必须指定repo:、org:或user:限定词,否则返回 422。
99. 搜索 Commits
GET search/commits
100. 搜索用户
GET search/users
101. 搜索 Topics
GET search/topics
Actions 操作(#102-#136)
102. 列出仓库 Workflows
GET repos/{owner}/{repo}/actions/workflows
104. 触发 Workflow ⚠️ DESTRUCTIVE
POST repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches
成功返回 204(无 body)。不返回 run_id,需通过 workflow:trigger-workflow 流程追踪。
105. 列出 Workflow Runs
GET repos/{owner}/{repo}/actions/runs
107. 获取 Run
GET repos/{owner}/{repo}/actions/runs/{run_id}
关键字段:status(queued/in_progress/completed)、conclusion(success/failure/cancelled/skipped)。
108. 取消 Run
POST repos/{owner}/{repo}/actions/runs/{run_id}/cancel
109. 重新运行 Run
POST repos/{owner}/{repo}/actions/runs/{run_id}/rerun
114. 列出 Run 的 Jobs
GET repos/{owner}/{repo}/actions/runs/{run_id}/jobs
120. 下载 Artifact
GET repos/{owner}/{repo}/actions/artifacts/{artifact_id}/zip
返回 302 重定向到下载 URL,使用 -L 跟随重定向。
124. 创建/更新 Secret(需加密)
PUT repos/{owner}/{repo}/actions/secrets/{secret_name}
加密流程(必须先获取 public key):
Secret 值必须使用 libsodium sealed box 加密。Pythonpynacl或 Node.jstweetnacl均可完成。
129. 创建 Variable
POST repos/{owner}/{repo}/actions/variables
Orgs & Teams 操作(#137-#154)
137. 获取组织
GET orgs/{org}
140. 列出组织成员
GET orgs/{org}/members
146. 创建团队
POST orgs/{org}/teams
150. 添加团队成员
PUT orgs/{org}/teams/{team_slug}/memberships/{username}
Commits & Checks 操作(#155-#168)
155. 列出 Commits
GET repos/{owner}/{repo}/commits
156. 获取 Commit
GET repos/{owner}/{repo}/commits/{ref}
返回 files 数组含每个变更文件的 filename/status/additions/deletions/patch。
157. 比较 Commits
GET repos/{owner}/{repo}/compare/{basehead}
160. 列出 Commit 的 Check Runs
GET repos/{owner}/{repo}/commits/{ref}/check-runs
164. 获取 Combined Status
GET repos/{owner}/{repo}/commits/{ref}/status
返回state(pending/success/error/failure)和statuses数组。
166. 创建 Commit Status
POST repos/{owner}/{repo}/statuses/{sha}
Activity 操作(#169-#180)
169. 列出通知
GET notifications
171. 标记通知已读
PUT notifications
175. Star 仓库
PUT user/starred/{owner}/{repo}
成功返回 204(无 body)。
177. 列出用户 Starred
GET users/{username}/starred
178. Watch 仓库
PUT repos/{owner}/{repo}/subscription
Git Low-level 操作(#181-#190)
181. 创建 Blob
POST repos/{owner}/{repo}/git/blobs
183. 创建 Tree
POST repos/{owner}/{repo}/git/trees
每个 tree 条目:
185. 创建 Commit
POST repos/{owner}/{repo}/git/commits
187. 获取 Ref
GET repos/{owner}/{repo}/git/ref/{ref}
返回 object.sha 即为当前分支指向的 commit SHA。
188. 创建 Ref
POST repos/{owner}/{repo}/git/refs
189. 更新 Ref
PATCH repos/{owner}/{repo}/git/refs/{ref}
Gists 操作(#191-#198)
193. 创建 Gist
POST gists
194. 更新 Gist
PATCH gists/{gist_id}
Deployments 操作(#199-#206)
201. 创建 Deployment
POST repos/{owner}/{repo}/deployments
205. 创建 Deployment Status
POST repos/{owner}/{repo}/deployments/{deployment_id}/statuses
§8 运维契约
8.1 HTTP 错误→AI 行为映射表
收到 API 错误时,AI 必须按以下表格执行对应行为:
403 三义歧义处理(关键):收到 403 时,AI 必须先检查响应 body:
- 包含
"secondary rate limit"→ 等待重试(不是权限问题) - 包含
"Resource not accessible"→ 权限不足(停止,引导用户) - 其他 → 读取 message 字段判断具体原因
8.2 Link 头分页契约(算法)
GitHub REST API 使用Link Header 进行分页(不同于 Notion 的 has_more / next_cursor 模式)。
- 始终使用
per_page=100(GitHub 默认仅 30 条,会导致静默数据截断) - 解析
LinkHeader:格式为<URL>; rel="next", <URL>; rel="last",提取rel="next"对应的 URL - 禁止将部分结果当作完整结果呈现给用户 — 若存在
rel="next",必须继续翻页或明确告知用户”还有更多数据” - 翻页完成后,告知用户”已获取全部 N 条结果”
- bash 解析示例:
8.3 双路限流处理算法
GitHub 有两层限流机制: Primary Rate Limit(主限流):- 认证用户:5,000 requests/hour
- 通过
x-ratelimit-remaining和x-ratelimit-resetHeader 监控 - 触发时返回 HTTP 429
- 针对短时间内大量请求的额外保护
- 触发时返回 HTTP 403(body 含
"secondary rate limit") - 通常由并发请求或短时间内创建大量内容触发
主动预防:
- 每次请求后检查
x-ratelimit-remaining,若低于 100 则降低请求频率 - 若为 0,等待至
x-ratelimit-reset时间点后再请求
8.4 通用约定
- Base URL:
https://api.github.com(所有端点都基于此地址) - API 版本:所有请求必须附带
X-GitHub-Api-Version: 2022-11-28Header - Accept Header:所有请求建议附带
Accept: application/vnd.github+json - Content-Type:POST/PATCH/PUT 请求体为 JSON(
application/json);文件上传为application/octet-stream或multipart/form-data - Token 传递:仅通过
Authorization: Bearer <token>Header 传递 - ID 格式:GitHub 使用整数 ID(如
123456789),不同于 UUID 格式 - 日期格式:ISO 8601(
YYYY-MM-DDTHH:MM:SSZ) - 空响应:DELETE 和某些 PUT 操作成功返回 HTTP 204(无 body)
- PowerShell 注意:
irm是Invoke-RestMethod别名;文件上传需用curl.exe;续行符为反引号`而非\
8.5 Search API 独立限流说明
Search API 有独立的限流配额,不与核心 API 共享:
Search 限流处理:
- Search 限流通过
x-ratelimit-resource: search区分 - 触发 429 后按 §8.3 算法处理,但等待时间通常以分钟为单位
- 建议:批量搜索时在每次请求间间隔 2-3 秒,主动避免触发限流
- Search 结果最多返回前 1,000 条匹配项(GitHub 硬限制),超出需用更精确的查询条件缩小范围