github-actions-pat

GitHub Actions PAT Inspector

把"用 PAT 分析 GitHub Actions CI"这条路径固化成可复用脚本。本 skill 解决的典型场景：

1. Agent 在 bifrost remote 目标机或 caller 上跑，必须走 REST API 自动化，不走浏览器 cookie
2. 需要自动化「修 → push → 盯 CI → 失败继续修」的闭环
3. 需要按 run-id / PR / sha / branch 精确定位失败并拉 job log
4. 需要做 PR diff review（生成 markdown 或直接 POST）

auth 唯一路径：PAT 从 GITHUB_TOKEN 环境变量读取。不支持、不回退到 cookie / OAuth device flow / SSH / gh CLI 登录等其他方式。需要 agent 自主跑的 CI 分析、PR review、fix-push-watch 循环，全部用本 skill。

授权契约（唯一输入：GITHUB_TOKEN 环境变量）

• 本 skill 只从环境变量 GITHUB_TOKEN 读 token。不落盘、不写日志、不回显原文。
• 读取方式推荐（适配用户 shell 配置）：

  # macOS / zsh 用户：交互式 shell 才会加载 ~/.zshrc
  zsh -ic 'python3 scripts/gh_ci.py run <run_id>'
  # bash 用户
  bash -lc 'python3 scripts/gh_ci.py run <run_id>'
  # 或在脚本运行前已 export GITHUB_TOKEN 的环境
  python3 scripts/gh_ci.py run <run_id>
  

• 未设置 → 脚本 exit 2，提示 ERROR: set GITHUB_TOKEN before running this skill。
• 推荐 scope：repo + actions:read（只读分析）。--post 发 review 时额外需要 pull_requests:write。
• 首选 fine-grained PAT 并把 repo 限定到目标仓库，爆炸半径最小。

仓库定位策略

脚本默认读环境变量 GH_REPO（格式 owner/repo），未设置时回退到本仓库。Agent 可在调用前写入：

export GH_REPO=bifrost-proxy/bifrost
python3 scripts/gh_ci.py pr 567

或者在 AGENTS.md 顶部的仓库元信息中固化。

目录结构

scripts/
├── common.py         # token/http/分页/日志切片/归因
├── gh_ci.py          # run / pr / sha / branch / regression
├── gh_review.py      # PR metadata + diff + 分层建议 + 可选 --post
└── poll_run.py       # 轮询一个 run 直到完成
references/
└── pitfalls.md       # GitHub API 坑点清单（job log 302、Accept 415、system proxy MITM）

典型调用

(A) CI 错误定位

# 按 run-id 分析
python3 scripts/gh_ci.py run 25269751068

# 按 PR 号找最近一次 failed
python3 scripts/gh_ci.py pr 567

# 按 commit sha 找
python3 scripts/gh_ci.py sha a96a4257

# 按分支找最近一次 failed
python3 scripts/gh_ci.py branch feat/agent --only-failed

# 与上一次 green 做 regression 对比（给出 compare URL + 提交区间）
python3 scripts/gh_ci.py regression 25269751068

脚本行为：

1. GET /repos/{owner}/{repo}/actions/runs/... 拉 run 元数据
2. GET .../jobs 筛出 conclusion=failure
3. 对每个 failed job：GET .../jobs/{id}/logs → 自动处理 302 到 Azure Blob signed URL（不能带 Authorization）
4. 日志末尾 500 行扫关键词（error:、FAIL、panicked、##[error]、thread '...' panicked、test result: FAILED 等），抽 ±20 行上下文
5. 输出结构化 markdown：失败 job / step / URL / 根因桶（compile / test / lint / fmt / timeout / network / OOM）/ 关键日志片段 / 本地复现命令