GitHub Forker

从文本或图像中提取 GitHub 仓库并执行 Fork 操作。你需要在环境中设置具有 repo 权限的 GITHUB_TOKEN。

你的操作流程

1. 提取 输入内容（文本、图像或两者）中所有 GitHub 仓库 URL
2. Fork 每个仓库（通过 GitHub API）
3. Fork 成功后，Star 原始仓库
4. 清晰报告 执行结果

步骤 1：提取 GitHub URL

从文本中提取

扫描输入内容，匹配以下格式的 URL 模式：

• https://github.com/{owner}/{repo}（允许结尾带斜杠、路径或片段标识符）
• github.com/{owner}/{repo}（不带协议前缀）
• 仅含 {owner}/{repo} 的形式 —— 仅当上下文明确表明其为 GitHub 仓库时才接受

将每个匹配项标准化为规范格式：https://github.com/{owner}/{repo}。移除任何额外路径段 —— 你只需提取 owner 和 repo 名称。

从图像中提取

当用户提供图像（截图、照片、示意图）时，请使用你的视觉能力识别图像中可见的 GitHub URL 或仓库引用，并对识别出的文本应用上述相同的提取规则。

截断的 URL

URL 常在截图或社交媒体预览中被截断，例如：

• github.com/openchamber/op...
• github.com/some-owner/proj…

当你检测到一个截断的 URL（以 ... 或 … 结尾，或仓库名明显不完整）时，请按以下步骤处理：

1. 在 GitHub 上搜索匹配的仓库：

   curl -s -L 
     -H "Authorization: Bearer $GITHUB_TOKEN" 
     -H "Accept: application/vnd.github+json" 
     "https://api.github.com/search/repositories?q={owner}/{partial}+in:full_name&per_page=5"
   

   尽可能利用已有信息进行搜索 —— 同时提供 owner 和部分 repo 名最佳；仅有 owner 也可尝试。

2. 结合上下文选择最匹配的结果。 参考周围文字、推文正文、提及的项目名称、描述关键词以及 star 数量。若某条结果显著突出，则可采纳：

   • 仓库名以可见的截断部分开头（例如 op... → openchamber 匹配）
   • 仓库描述与用户所述一致（例如用户说“UI真好”，则优先选择 UI 相关的仓库）
   • 该仓库 star 数量明显高于其他候选结果

   若你有足够把握，请直接执行操作，并向用户说明推理依据：

   "github.com/openchamber/op..." → 推断为 openchamber/openchamber ⭐1.5k（OpenCode 的桌面 UI，符合上下文 “UI真好”）
   

3. 仅在确实无法判断时才向用户提问 —— 即多个候选结果均合理，且上下文无法帮助区分：

   发现截断 URL "github.com/foo/bar..." —— 您指的是哪一个仓库？
   1. foo/barista ⭐420 — 咖啡店 POS 系统
   2. foo/baroque ⭐38 — 巴洛克音乐生成器
   请输入编号（或输入 0 跳过）：
   

   切勿在未获得明确推理结论或用户确认的情况下，对截断 URL 执行 Fork 操作。

步骤 2：通过 GitHub API Fork 仓库

对每个唯一的 {owner}/{repo} 组合，调用 Fork 接口：

curl -s -L -X POST 
  -H "Authorization: Bearer $GITHUB_TOKEN" 
  -H "Accept: application/vnd.github+json" 
  -H "X-GitHub-Api-Version: 2022-11-28" 
  https://api.github.com/repos/{owner}/{repo}/forks

-L 参数为必需 —— GitHub API 将返回 307 重定向，必须跟随该重定向。

• 若未设置 GITHUB_TOKEN，请提示用户设置并终止操作：

  export GITHUB_TOKEN="ghp_..."   # 经典 PAT（推荐）
  # 若要在会话间持久生效，请添加至 ~/.zshrc 或 ~/.bash_profile
  

• GitHub 后端的 Fork 请求是异步的 —— 返回 202 表示“已接收”，不代表“已完成”。
• 若仓库已被 Fork，GitHub 将返回已有 Fork（而非报错），此行为属正常。
• 需妥善处理 HTTP 错误：
  • 401：Token 无效或已过期
  • 403：Token 缺少 Fork 权限。对于 经典 PAT，需具备 repo 或 public_repo scope；对于 细粒度 PAT，需授予“Administration: Read and write”权限（仅 contents 权限不足）。
  • 404：仓库不存在，或为私有仓库且当前 Token 无访问权限

步骤 3：Star 原始仓库

Fork 成功后，Star 原始仓库：

curl -s -L -X PUT 
  -H "Authorization: Bearer $GITHUB_TOKEN" 
  -H "Accept: application/vnd.github+json" 
  -H "X-GitHub-Api-Version: 2022-11-28" 
  https://api.github.com/user/starred/{owner}/{repo}

返回 204 表示 Star 成功。Star 失败属于非致命错误 —— 若 Star 失败，仅需在最终报告中注明，无需将整体操作标记为失败。

步骤 4：报告结果

完成所有 Fork 尝试后，输出清晰的汇总报告：

共发现 X 个仓库：
✓ owner/repo — 已 Fork → https://github.com/YOUR_USERNAME/repo  ⭐ 已 Star
✓ owner/repo — 已 Fork → https://github.com/YOUR_USERNAME/repo  （Star 失败：<原因>）
✗ owner/repo — 失败：<原因>

若 Token 对应的用户名不明确，请从 Fork 响应中提取（响应中的 full_name 字段形如 your-username/repo-name）。

边界情况

• 未找到任何 URL：明确告知用户 —— “输入内容中未发现 GitHub 仓库 URL。”
• 私有仓库：若 Token 无访问权限，Fork 将返回 404；请如实报告该错误。
• 重复 URL：Fork 前需去重 —— 每个唯一仓库仅 Fork 一次。
• 非仓库 URL：忽略不符合 owner/repo 格式的 github.com/ 路径（例如 github.com/features、github.com/login）。