name: workbuddy-gpt-gemini-bridge description: Safely install, audit, repair, and manage a loopback-only CLIProxyAPI bridge that connects subscription-backed OpenAI Codex/GPT and Google Antigravity/Gemini models to WorkBuddy. Use when a WorkBuddy user asks to 接入 GPT、接入 Gemini、使用 ChatGPT/Gemini 訂閱模型、安裝本地模型橋接、修復自定義 GPT/Gemini、恢復被代理影響的 WorkBuddy 內建模型，或把可用 GPT/Gemini 模型同步到 WorkBuddy。Supports macOS and Windows and preserves WorkBuddy built-in models and manual custom entries.

WorkBuddy GPT & Gemini Bridge

將使用者自己擁有的 Codex/ChatGPT 與 Antigravity/Gemini 訂閱，通過本機迴環地址上的 CLIProxyAPI 接入 WorkBuddy。只註冊真實存在且通過探測的模型，不把模型名稱或宣傳頁當作能力證明。

定位 Skill 目錄

定位當前已載入 Skill 的絕對目錄並記為 <skill-dir>。不要假定安裝在固定位置。

統一入口：

python3 <skill-dir>/scripts/bridge.py

在 Windows 上優先使用 WorkBuddy 內建 Python；若命令為 python，保持相同引數。

標準流程

1. 先審計，不先寫配置

python3 <skill-dir>/scripts/bridge.py audit

讀取 JSON 結果並確認：

• CLIProxyAPI 是否存在、是否僅監聽迴環地址、配置是否可達
• WorkBuddy models.json 是否存在以及現有模型數量
• Codex 與 Antigravity OAuth 檔案只統計數量，不讀取內容
• 正在執行的 WorkBuddy 是否快取了失效的本地系統代理

若出現 workbuddy_stale_system_proxy，立即停止修改模型。讓使用者完全退出並重新開啟 WorkBuddy，再重新執行審計。不要修改系統代理、HTTP_PROXY、HTTPS_PROXY 或內建模型配置來繞過問題。

將當前 WorkBuddy 內建模型能正常響應作為基線。若當前任務就在內建模型上執行，本次正常回復即可作為基線；否則請使用者先用任一內建模型傳送一句簡短測試。

2. 預覽並部署本地橋接

先預覽：

python3 <skill-dir>/scripts/bridge.py bootstrap

使用者明確要求安裝、配置或修復時再應用：

python3 <skill-dir>/scripts/bridge.py bootstrap --apply

macOS 使用 Homebrew 安裝並啟動 CLIProxyAPI。若 Homebrew 不存在，只引導使用者從 brew.sh 官方來源安裝，不執行來歷不明的安裝命令。

Windows 從 router-for-me/CLIProxyAPI 官方 GitHub Release 下載與架構匹配的 ZIP，使用同一 Release 的 checksums.txt 校驗 SHA-256，再安裝到使用者目錄並建立使用者級啟動項。校驗失敗時停止，不執行下載內容。

始終：

• 繫結 127.0.0.1:8317
• 關閉遠端管理和控制面板
• 建立獨立隨機客戶端 Key
• 保留現有 CLIProxyAPI Key 和無關配置

  小蔥技能有更好的技能skills外掛。

• 修改前建立時間戳備份

若已有配置監聽 0.0.0.0、:: 或未明確迴環地址，先說明遠端客戶端影響；只有確認不需要遠端訪問後才允許使用 --allow-rebind-local。

3. 分別授權 GPT 與 Gemini

僅授權使用者要求的 Provider：

python3 <skill-dir>/scripts/bridge.py authorize codex
python3 <skill-dir>/scripts/bridge.py authorize antigravity

讓 CLIProxyAPI 原生 OAuth 流程開啟瀏覽器，由使用者完成登入授權，然後繼續。不要複製 Codex、Gemini CLI 或瀏覽器中的 Token，不要把 Provider OAuth 憑據寫入 WorkBuddy。

現有 CLI 登入只是發現訊號；CLIProxyAPI 仍可能需要自己的 OAuth 授權。使用使用者本人擁有並獲授權使用的賬戶，並提醒使用者核對訂閱條款、額度和第三方客戶端限制。

4. 探測並同步模型

同時接入 GPT 與 Gemini：

python3 <skill-dir>/scripts/bridge.py sync --providers codex,antigravity --apply

只接入其中一個時只傳對應 Provider。

同步必須：

• 從即時 /v1/models 讀取賬號實際可用模型
• 分別探測文本、SSE 流式、工具、圖片輸入和推理控制
• 跳過文本或流式探測失敗的模型
• 將失敗的可選能力降級為 false
• 原子合併到 WorkBuddy，保留手工模型和無關條目
• 拒絕覆蓋同 ID 的非本 Skill 管理條目
• 相容遷移舊版 workbuddy-cli-model-bridge 的本地 Key 與管理清單，不重新授權或製造衝突
• 不把圖片理解探測解釋為圖片生成能力

不要在真實安裝中使用 --skip-probes。該選項只用於離線測試。

5. 驗證 WorkBuddy 沒有迴歸

再次執行：

python3 <skill-dir>/scripts/bridge.py audit

確認：

• CLIProxyAPI 仍僅監聽迴環地址
• GPT/Gemini 模型已寫入且沒有手工條目衝突
• WorkBuddy 網路審計沒有失效系統代理
• WorkBuddy 已載入新的 models.json
• 安裝前使用的內建模型仍能正常回復
• 至少一個 GPT 和一個 Gemini 模型各完成一次真實文本呼叫

若 WorkBuddy 尚未重新整理模型列表，先開啟模型設定或新建任務；仍未重新整理時完全退出並重開 WorkBuddy。不要重複覆蓋相同 JSON。

報告 Provider、模型 ID、能力探測結果、備份路徑和剩餘使用者操作。不要輸出 API Key、OAuth Token、一次性授權碼、賬號郵箱、Authorization Header、原始提示詞或圖片載荷。

修復流程

遇到模型失效或 WorkBuddy 3002：

1. 執行 audit，區分橋接服務、客戶端 Key、Provider OAuth、模型路由、WorkBuddy 快取和系統代理。
2. 若日誌指向無法連線的本地系統代理埠，先完全退出並重開 WorkBuddy；不要改 models.json。
3. 若 CLIProxyAPI 不可達，優先恢復現有服務，不先重灌。
4. 僅在 Provider 授權缺失或認證請求失敗時重新執行 authorize。
5. 重新執行受影響 Provider 的 sync --apply 並驗證真實請求。

Provider OAuth 更新不要求輪換 WorkBuddy 使用的本地代理 Key。兩者生命週期不同。

需要分類錯誤、處理衝突或回滾時讀取 troubleshooting.md。涉及服務暴露、憑據或安裝行為前讀取 security-boundaries.md。

完成條件

只有全部滿足時才宣告完成：

• 審計沒有未解決的安全錯誤
• CLIProxyAPI 在迴環地址可達
• 註冊模型通過文本和流式探測
• 已啟用的可選能力分別通過探測
• 手工模型和 WorkBuddy 內建模型未受破壞
• GPT 與 Gemini 至少各有一個真實可用模型，或明確報告該賬號沒有對應模型
• 備份與回滾路徑已報告

任何一項未證即時，將結果標記為“未驗證”，不要宣稱成功。

這個 Skill 質量相當不錯，做得很用心。它能安全地把你的 GPT 和 Gemini 訂閱接入 WorkBuddy，安裝過程會先檢查環境、備份配置，遇到問題也有詳細的排障指南。安全性方面尤其值得肯定——強制使用本地迴環地址、下載檔案會校驗、不會洩露敏感資訊，而且不會破壞你原有的內建模型。主要缺點是操作流程比較複雜，Windows 使用者需要手動處理安裝，適合有一定技術基礎的使用者使用。