workbuddy-cli-model-bridge

WorkBuddy CLI モデルブリッジ

CLIProxyAPI を通じて、対応する CLI サブスクリプションを検証済みの WorkBuddy カスタムモデルエントリーに変換します。付属スクリプトを使って、検出、インストール、OAuth の引き継ぎ、機能プローブ、冪等な WorkBuddy の更新を行います。モデルに関する主張は実際のプローブ結果に基づくものにしてください。モデル名やマーケティングページは、特定のプロキシルートでその機能が維持される証拠にはなりません。

Skill ディレクトリの解決

読み込まれたこの Skill のディレクトリを解決し、その絶対パスを <skill-dir> として使用してください。特定のインストール先を想定しないでください。

決定的なエントリーポイントは次のとおりです。

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

デフォルトのワークフロー

1. 変更を加える前に監査する

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

JSON の検出結果を読み取ります。監査では秘密情報を伏せたうえで、次の項目を検出します。

• Homebrew、CLIProxyAPI、アクティブな設定、バインドアドレス、プロキシへの到達可能性
• WorkBuddy の初期化状況と既存モデルの数
• 付属およびローカルの Provider マニフェスト
• トークンの内容を読み取らずに、CLI 実行ファイルとログインの兆候
• アカウント名を公開せずに、CLIProxyAPI の認証ファイル数

既存の CLI ログインは、検出の手がかりとして扱います。CLIProxyAPI には独自の OAuth 許可が必要な場合があります。別の CLI のトークンファイルをコピーしないでください。

2. 必要に応じて CLIProxyAPI をブートストラップする

プレビューします。

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

ユーザーがブリッジのインストール、設定、修復、または収束を依頼した場合は、計画を適用します。

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

ブリッジのセットアップ依頼は、取り消し可能な Homebrew のインストール、ループバックサービスの起動、専用のランダムなプロキシクライアントキーの作成、安全なローカル状態の保存、タイムスタンプ付きバックアップを許可するものです。次の場合にのみ、一時停止します。

• Homebrew が見つからず、そのインストーラーで管理者の操作が必要な場合
• 既存のプロキシがループバック以外でリッスンしている場合。--allow-rebind-local を使用する前に、リモートクライアントへの影響を説明してください
• デプロイメントの重複または設定の競合により、所有者が不明確な場合

正常な既存インストールはそのまま維持します。macOS に新規セットアップする場合は、公式の Homebrew インストールを優先してください。

3. 関連する Provider のみを認証する

付属の OAuth Provider ID は codex、xai-grok、antigravity です。ユーザーがその Provider を依頼した場合、または監査でその CLI／ログインの兆候が見つかり、CLIProxyAPI に対応する認証／モデルルートがない場合に認証します。

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

このコマンドは CLIProxyAPI のネイティブ OAuth フラグに処理を委ねます。ブラウザページで承認するようユーザーに伝え、その後は自動的に続行します。OAuth トークンを貼り付けたり、表示、変換、再利用したりしないでください。生成された認証 JSON ファイルの権限を所有者のみに制限してください。

付属の glm-coding は Coding Plan API キー Provider であり、OAuth ではありません。次の手順に従ってください：glm-coding-plan.md。公式のコーディング /paas/v4 ルートを CLIProxyAPI に追加してから、sync --providers glm-coding を実行します。智谱清言のウェブサイトログインは使用しないでください。

付属しているという理由だけで、無関係な Provider を認証しないでください。

4. WorkBuddy をプローブして同期する

該当する Provider ID のみを渡してください。

python3 <skill-dir>/scripts/bridge.py sync --providers codex,xai-grok,glm-coding --apply

同期コマンドは次の処理を行います。

• 稼働中の /v1/models リストを取得します
• Provider マニフェストから推奨されるチャット／エージェントモデルを選択します
• 宣言されている項目について、テキスト、SSE ストリーミング、ツール、画像、推論制御をプローブします
• Provider が宣言したカタログを優先し、次に情報源が明らかなマニフェストメタデータを参照して、正確なモデル ID ごとにトークン制限を解決します
• 入力／出力制限が不明なモデル、または出力制限のプローブで拒否されたモデルは登録しません
• テキストまたはストリーミングのプローブに失敗したモデルはスキップします
• オプションの機能フラグは、プローブに失敗した場合に無効化します
• ~/.workbuddy/models.json をバックアップして、アトミックに更新します
• 手動エントリと古い管理対象エントリを保持します
• 同じモデル ID の手動エントリは上書きしません
• 所有権情報は ~/.config/workbuddy-cli-model-bridge/ に別途記録します

稼働中の環境では --skip-probes を使用しないでください。このオプションは決定的なオフラインテスト専用です。

ユーザーが Fast モードを明示的に要求し、Fast モデルが見つからない場合は、troubleshooting.md の Fast モデルのセクションを確認してください。Fast エイリアスには、CLIProxyAPI の独立したルートと、検証済みの優先順位セマンティクスの両方が必要です。通常のモデルを Fast として再ラベル付けしないでください。

推論プローブでは、制御の互換性を検証します。非公開の思考過程を明らかにすることはできません。指導や画面録画を目的とする場合は、通常の回答内容として、意図的な問題の分解を出力するようモデルに依頼してください。

WorkBuddy では、カスタムモデルはそれぞれ個別のエントリとして扱われます。この Skill は検証済みのエントリを登録しますが、現在選択されている会話モデルは変更しません。

5. アプリケーションに変更が反映されたことを確認する

監査を再実行します。WorkBuddy がすでに起動している場合は、現在のメインスレッドログを確認し、models.json changed または Loaded custom models config イベントがあるか調べます。再読み込みイベントが見つからない場合は、モデル設定を開き直すか、新しい会話を開始するようユーザーに依頼してください。同じ設定を繰り返し書き換えないでください。

次の内容を報告してください。

• CLIProxyAPI のバージョン／パスとローカルエンドポイント
• 認証済み Provider（アカウント識別子は含めないでください）
• 追加または更新されたモデル
• 機能プローブの結果
• 競合、スキップされたモデル、保持された古いエントリ
• バックアップパスと、ユーザーに必要な残りの操作
• 有効な入力／出力トークン制限と、その秘匿情報を含まないメタデータの情報源

API キー、一時コードを含む OAuth URL、トークンファイルの内容、未加工のリクエスト本文は絶対に含めないでください。

修復ワークフロー

期限切れまたは動作しなくなったモデルの場合：

1. audit を実行し、プロキシの停止、キーの欠落、OAuth の欠落、モデルの利用不可、Provider のクォータ、WorkBuddy のキャッシュに起因する障害を区別します。
2. 何かを再インストールする前に、既存のサービスを起動または修復します。
3. クォータ回復後も 503 auth_unavailable が続く場合は、再認証する前に Quota recovered but 503 persists の手順に従ってください。
4. 認証情報がない場合、または認証に特化したプローブが失敗した場合に限り、authorize <provider> を再実行します。
5. sync --providers <affected-provider> --apply を再実行します。
6. 実際のテキストリクエストと、宣言されたすべてのオプション機能を検証します。

Provider の OAuth セッションが変わったという理由だけで、WorkBuddy の API キーをローテーションしないでください。プロキシのクライアントキーと上流の OAuth 認証情報は、ライフサイクルが異なります。

障害の分類とロールバック方法については、troubleshooting.md を参照してください。

新しい CLI プロバイダーを追加する

以下の両方を読んでください。

• provider-schema.md
• onboarding-new-cli.md

次の順に優先してください。

1. CLIProxyAPI ネイティブの OAuth プロバイダー
2. 公式の OpenAI 互換エンドポイント
3. 宣言型のモデルエイリアス／プロトコルマッピング
4. 別途明示したうえで、範囲を限定したローカルアダプターを最後の手段として使用

マシンローカルのマニフェストは、次の場所に保存してください。

~/.config/workbuddy-cli-model-bridge/providers.d/<provider-id>.json

使用前に検証してください。

python3 <skill-dir>/scripts/bridge.py validate-provider ~/.config/workbuddy-cli-model-bridge/providers.d/<provider-id>.json

その後、新しいプロバイダー ID で認証し、同期してください。新しいマニフェストは、このスキルを変更しなくても、同じマシン上のすべてのエージェントで再利用できます。インストール、認証の引き継ぎ、モデル選択、機能の正確性、ロールバック動作が隔離テストで確認された場合に限り、公開スキルに追加してください。

安全性の境界

サービスの公開範囲、認証情報の変更、またはローカルアダプターの追加を行う前に、security-boundaries.md を読んでください。

• プロキシはループバックにバインドし、リモート管理は無効のままにしてください。
• ブリッジのシークレット、OAuth ファイル、WorkBuddy の設定、認証情報を含むバックアップは、モード 0600 で保存してください。
• ユーザーが所有するアカウントのみを使用し、プロバイダーのサブスクリプション条件とレート制限を遵守してください。
• BAN 回避、アカウント共有、自動ブロックリセット、トークン抽出、隠れたトラフィックの偽装は実装しないでください。
• ユーザーが作成した WorkBuddy モデルと、無関係な CLIProxyAPI 設定を保持してください。
• プロバイダーマニフェストはコードとして扱ってください。ログインフラグを実行する前に、そのソースを検証し、ローカルのオーバーライドを確認してください。

完了条件

完了には、以下が必要です。

• 監査で未解決のセキュリティエラーがない
• CLIProxyAPI が、専用クライアントキーを使用してループバック上で到達可能である
• 登録した各モデルで、テキストとストリーミングのプローブに合格している
• 有効にしたすべてのオプション機能が、それぞれのプローブに合格している
• 登録したすべてのモデルで、入力／出力制限の出典が明確であり、制限付きの出力制限プローブに合格している
• WorkBuddy が生成されたモデルリストを読み込んでいる
• 同期を繰り返しても冪等である
• バックアップとロールバックの手順が報告されている

条件が一つでも確認できない場合は、成功と宣言せず、そのモデルを未検証として報告してください。