mcpField
S
setup-ox

setup-ox

github.com/overextendedエージェントワークフロー209 回インストール2 週間前に更新
リポジトリ

setup-ox について

oxスキルが使う設定ファイルを構成するセットアップスキルです。サブエージェントのモデル設定と、サーバーリソース、フレームワーク、言語などのプロジェクト情報を記録します。

主な機能

  1. 01サブエージェントのモデルと推論レベルの設定
  2. 02利用可能なモデル選択肢の検出
  3. 03サーバーとリソース情報の記録
  4. 04フレームワークと言語の特定
  5. 05ox設定ファイルの作成

活用シーン

  1. 01oxスキルのモデル設定
  2. 02oxスキル用プロジェクト情報の準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/overextended/skills --skill setup-ox

インストール後、Claude Code で/setup-oxを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

ox のセットアップ

ox スキルの実行時に読み込まれる次の 2 つのファイルを作成します。

  • ~/.config/ox/models.md(パート A):各サブエージェントの役割で使用するモデルと推論レベルです。ユーザーとそのハーネスに属するため、ホームディレクトリに置き、コミットしません。
  • .ox/config.md(パート B):このサーバーの実行環境を記述します。場所、使用する ox リソースとバージョン、フレームワーク、言語を記載します。プロジェクトに属するため、サーバーのルートに置きます。

パート A の後に、パート B を実行してください。ユーザーが引数として models または project を指定した場合は、そのパートだけを実行してください。

パート A:モデルと予算

A1. 利用可能なモデルを検出する

ハーネスがサブエージェントの起動に使用するツールのパラメーターを読み取ってください。そのツールに列挙されているモデルと推論レベルのみが有効な値です。Claude Code では、Agent ツールの model と effort パラメーターです。ツールに列挙されていないモデルや推論レベルは、決して記述しないでください。エントリーは <model> と、ツールが推論レベルを受け取る場合は (<effort>) を組み合わせたものです。

ハーネスにサブエージェント用のツールがない場合、またはそのツールがモデルを受け取らない場合は、その旨を伝え、すべての役割に inherit を設定してください。inherit は常に有効です。役割は親セッションのモデルと推論レベルで実行されます。

T3 Code では、サブエージェント用のツールは delegate_task であり、orchestrator_capabilities には canRunChildTask が true のプロバイダーすべてのモデルが列挙されています。エントリーは <providerInstanceId>/<model> (<effort>) です。ここでの推論レベルは、そのモデルについてツールに列挙されているオプションを使います。これにより、パネルで複数のプロバイダーをまたぐことができます。

ハーネス名(claude-code、codex、t3-code、cursor など)を記録してください。エントリーは、それを列挙したハーネスでのみ有効です。

A2. 現在の状態を読み込む

~/.config/ox/models.md がすでに存在する場合は、読み取ってください。その # budget 行と役割の値を現在の選択として扱います。# harness 行にこのハーネスとは異なるハーネス名が記載されている場合、そのエントリーはここでは適用されません。デフォルトから開始し、その旨を伝えてください。A5 にない役割の行は削除してください。

A3. 予算、マッピング、確認

(a) 予算を尋ねます。 スレッドで率直に尋ねます。次の4つの選択肢を、これらの正確なラベルで提示し、ファイルに現在の予算が記録されている場合はその予算を伝えます。

  • unlimited - max reasoning
  • large - xhigh reasoning
  • medium - high reasoning
  • small - medium reasoning

(b) 適用します。 デフォルトから作業用の表を作成し、再実行時にはユーザーが手動で変更した役割を維持します。デフォルトは次のとおりです。

役割実行する内容デフォルトのモデル
exploreリソースと ox のソース全体を読み取り専用で検索します。エクスポート、イベント、呼び出し元、convar の特定などを行います検出された最速のモデル
verify apiコードで使用する前に、リソースの現在のソースに照らしてエクスポート、関数シグネチャ、コールバックの形式を確認します検出された最速の高性能コーディングモデル
implementリソースコード(クライアント、サーバー、共有、NUI)を作成または変更します検出された最速の高性能コーディングモデル
review変更を確認し、バグ、ox API の誤用、サーバーの信頼性(クライアントからトリガーされるイベント、未検証の入力、エクスプロイト)を調べます検出された最も高性能なモデル
hardest tasksリソースの設計、リソース間またはクライアント/サーバー境界をまたぐ問題のデバッグ、複数の探索結果に基づくサブシステムの説明を行います検出された最も高性能なモデル
panel1つのタスクを複数のモデルで並行して実行します。候補のアリーナ、アーキテクトのスケッチ、レビュー担当者への尋問などに使います。リスト形式で、各項目が1つのシートに対応します各プロバイダーで検出された最も高性能なモデル。最大3つ。プロバイダーが1つの場合は、そのプロバイダーの最も高性能なモデルを最大3つ

unlimited、large、medium、small は、それぞれすべての項目の effort を max、xhigh、high、medium に設定します。優先順位は max > xhigh > high > medium > low です。モデルに指定した段階がない場合は、そのモデルが対応している段階のうち、優先順位が最も高いものを使用します。それもない場合は、その役割を選択が必要なものとして示します。effort の選択肢がないモデルには (<effort>) を付けません。inherit は変更しません。panel では、すべての項目に effort が適用されます。

(c) 役割を提示して確認します。 すべての役割とその項目を提示し、検出済みのセットに含まれない項目には選択が必要であることを示します。そのまま承認するか、特定の役割を変更するかを尋ね、選択肢として検出されたモデルと inherit を提示します。panel では、ユーザーがリストを選びます。リストの長さによって実行するシート数が決まります。スレッドで率直に尋ねます。

A4. 検証

書き込むすべての項目(panel の各項目を含む)が、A1 の結果に含まれていることを確認します。モデルはサブエージェントツールに列挙されているものを使い、effort が指定されている場合は、その値もツールに列挙されている必要があります。inherit は常に有効です。選択した項目が利用できない場合は、処理を止めて再度尋ねます。

A5. ファイルを書き込む

~/.config/ox/models.md に書き込みます(~/.config/ox/ が存在しない場合は作成します)。再実行しても冪等性が保たれるよう、ファイル全体を上書きします。形式:

# ox skills model configuration. Written by /setup-ox. One line per role.
# Delete a line, or write `inherit`, to run that role on the parent session's model and reasoning level.
# harness: <harness>
# budget: <label> (<effort>)
explore: <model> (<effort>)
verify api: <entry>
implement: <entry>
review: <entry>
hardest tasks: <entry>
panel: <entry>, <entry>, <entry>

Part B:プロジェクト

B1. サーバーのルートを見つける

現在のディレクトリから開始し、server.cfg が見つかるまで上の階層へたどります。または、resources/ と server.cfg の両方を含むディレクトリを探します。そのディレクトリがサーバールートです。現在のディレクトリが単一のリソース(fxmanifest.lua を含む)である場合は、それを越えて上の階層へ進みます。

  • サーバールートが1つ見つかった場合:それを使用します。
  • 複数見つかった場合(例:複数のサーバーを含むリポジトリ):一覧を提示し、どれを使うか尋ねます。
  • 見つからない場合:これはスタンドアロンのリソースリポジトリです。実行先のサーバーのパスを尋ねます。ユーザーがサーバーを持っていない場合は、現在のディレクトリをルートとして使用し、server root: none と記録します。
B2. 検出する

サーバーを読み取り、推測で補わないでください。以下の値はすべて、記憶ではなく、実際に読み取ったファイルから取得します。サーバーの規模が大きい場合は、~/.config/ox/models.md の該当する行を使って explore サブエージェントに任せてください。

  • リソース。 サーバールートの resources/ 以下にあるすべての fxmanifest.lua を探します。[ox] のような角括弧付きフォルダーも対象です。リソース名はフォルダー名です。それぞれの version フィールドを読み取ります。
  • ox リソース。 一覧から、名前が ox_ で始まるリソースと oxmysql をすべて選びます。それぞれの名前とバージョンを記録します。
  • フレームワーク。 リソース一覧から ox_core、qbx_core、es_extended、qb-core、ND_Core を探します。存在するものとそのバージョンを記録します。
  • 起動済みリソース。 server.cfg の ensure/start 行を読み取ります。ほかの .cfg ファイルを指す exec も追跡します。存在していても起動されていないリソースは、存在するが未起動として記録します。
  • ロケール。 cfg ファイルから、設定されている場合は ox:locale の convar を読み取ります。
  • 言語。 ユーザーが所有する各リソース(ox リソースとフレームワーク以外)について、マニフェスト内の .lua スクリプトがある場合は Lua、package.json、ビルド手順、または dist/ を参照するスクリプトがある場合は TypeScript/JavaScript のどちらを使っているかを記録します。
  • リソースディレクトリ。 ユーザー独自のリソースが置かれているフォルダーを探します。通常は resources/[local] などです。ユーザー所有のリソースが最も多い角括弧付きフォルダーを選びます。

cfg ファイルにはシークレット(mysql_connection_string、sv_licenseKey、steam_webApiKey、トークンを含む set 行)が記載されています。シークレットを設定ファイルや返信にコピーしてはならず、シークレットを含む cfg の行全体をそのまま出力してはいけません。

プライベートな情報を含む secrets.cfg や tokens.cfg などのファイルは読み取らないでください。

B3. 現在の状態を読み込む

サーバールートに .ox/config.md がすでにある場合は、読み取ります。その値を現在の選択として扱い、今回の検出結果と異なるすべての行(前回の実行からリソースが更新、削除、追加された場合)に印を付けます。B6 にないキーの行は削除します。

B4. 表示して確認する

B6 のすべての設定について、検出した値を1つの表にしてユーザーに提示します。現在のファイルと異なる値と、検出だけでは確定できなかった値には 選択が必要 と印を付けます。その後、同じメッセージ内で、提示された内容をそのまま採用するか、特定の行を変更するか尋ねます。

選択が必要な行については、次の選択肢を指定されたラベルのまま提示します。

  • framework:ox_core、qbx_core、es_extended、qb-core、ND_Core、standalone。複数のフレームワークが起動している場合は、新しいコードの対象とするものを尋ねます。
  • language:lua、typescript、javascript。ユーザーのリソースの大半で使われている言語をデフォルトにし、判断できない場合は lua にします。
  • resources dir:検出したフォルダー、またはユーザーが指定するパス。

検出結果から明確に確定できた項目については質問を省略します。表に答えが示されています。

B5. 検証する
  • framework は standalone、またはサーバーに存在するリソースのいずれかでなければなりません。存在していても起動されていない場合は、その旨を伝えます。
  • resources dir はサーバールート内に存在しなければなりません。
  • ox_lib が存在しない場合は、ほとんどの ox スキルがこれを前提としていることを警告し、続行するか尋ねます。
  • 記載するすべてのバージョンは、そのリソースの fxmanifest.lua から読み取ったものでなければなりません。

値が条件を満たさない場合は、作業を中断して再度尋ねます。

B6. ファイルを書き込む

サーバールートに .ox/config.md を書き込みます(.ox/ がない場合は作成します)。再実行しても同じ結果になるよう、ファイル全体を上書きします。形式:

# ox setup. Written by /setup-ox. Re-run it after adding, removing or updating resources.
# Delete a line to make skills detect that value themselves.
server root: <path from this file to the server root, "." when they are the same, or "none">
resources dir: <path relative to the server root>
framework: <name> <version>, or standalone
language: lua | typescript | javascript
locale: <value of ox:locale>, or en (ox_lib's default when it is unset)
ox resources: <name> <version>, <name> <version>, ...
not started: <name>, <name>, ... or none

プロジェクトが git リポジトリの場合は、.ox/ をプロジェクト全体で共有できるようコミットするか、.gitignore に追加するかを尋ねます。コミットを推奨してください。

確認

書き込んだファイルをユーザーに伝えます。ox スキルは次回の実行時にこれらのファイルを読み取ります。/setup-ox を再実行すると更新できます。プランまたはハーネスを変更した場合は /setup-ox models、リソースを更新した場合は /setup-ox project を実行します。スキルは .ox/config.md に記録されたバージョンの API を説明するためです。

コメント