unity-cli

このモジュールのスキルを呼び出す前に： 名前や説明から推測したパラメーターでスキルを呼び出そうとしている場合は、いったん停止してください。先にこのファイルを読むか、GET /skills/recommend?includeSchema=true でスキーマを取得してください。recommend/schema からパラメーターの定義をすでに取得している場合は、そのまま dryRun に進めます。

Unity CLI（参考情報）

参考情報モジュール — REST スキルはありません。 ここに記載されているコマンドはすべて、REST サーバー経由ではなく、ユーザーのマシン上のあなたのシェルで実行します。これは、Unity Editor が閉じているときにも使えることが目的です。

ゲート — まずここを読んでください

以下を使用する前に、バインド設定を確認してください。

<projectRoot>/Library/UnitySkills/cli_config.json

• ファイルが見つからない、読み取れない、または enabled: false の場合 → このプロジェクトでは Unity CLI はオフです。このモジュール全体を無視してください。 求められていないのに CLI のインストールを勧めないでください。ユーザーは Window > UnitySkills → AI Config → Unity CLI Setup… からオプトインします。
• enabled: true の場合 → 実行ファイルとして cliPath を使用してください（PATH に含まれていない場合があります）。features の機能ごとの切り替え設定に従ってください。

{
  "schemaVersion": 1,
  "enabled": true,
  "cliPath": "/Users/me/.local/bin/unity",
  "cliVersion": "1.0.0-beta.5",
  "projectPath": "/path/to/Project",
  "editorVersion": "6000.0.32f1",
  "boundAt": "2026-07-26T09:00:00Z",
  "features": { "coldStart": true, "openArgs": true, "cliTest": true, "cliRun": false, "cliBuild": false }
}

古いプラグインバージョンで書き込まれた設定には、cliRun / cliBuild キーがない場合があります。この2つについては、キーがない場合はオフです（最初の3つのキーは従来どおりの意味です）。どちらも新規バインド時はデフォルトでオフになり、ユーザーがパネルでプロジェクトごとに有効にします。

グローバルレジストリ（~/.unity_skills/registry.json）にも、実行中の各インスタンスについて cliBound / cliPath が記録されています。これは稼働状況の確認にのみ使用し、認可には決して使用しないでください。プロジェクトで CLI の使用を認可するのは、そのプロジェクト自身の cli_config.json だけです。レジストリに表示されていても、プロジェクト自身の設定を読んでいないプロジェクトをコールドスタートしないでください。また、設定内の projectPath はバインド時のスナップショットです。実際に設定ファイルを見つけたディレクトリを正しいパスとしてください（ヘルパー get_cli_config() はすでにこの値を書き換えます）。保存されたパスが実際のプロジェクトルートと異なる場合は、そのパスを決して open しないでください。

Unity CLI は実験版（ベータ）で、コマンドの仕様はリリースごとに変わります。このドキュメントは 1.0.0-beta.9 に対して検証済みです（beta.7 はリリース当日に取り下げられました）。設定内の cliVersion はバインド時のスナップショットにすぎず、インストール済みのバイナリはそれより新しいバージョンになっている場合があります。最近仕様が変更されたコマンドを使う前に、<cliPath> --version と <cliPath> <command> --help を実行してください。ディスク上のバイナリについては、--help が常に最終的な判断基準です。beta9 以降の <cliPath> skill show --list / --path <file> は、Unity 独自のエージェントスキルを読み取り専用で出力します（オフラインで合計約44kトークン。一度に読むファイルは1つにしてください）。これは二次的な参照情報であり、認可ではありません。このモジュールのゲートと禁止事項のリストは引き続き適用されます。コマンドが予期せずエラーになった場合は、まず <cliPath> doctor --format json を実行してください（環境のスナップショットを取得します。ログをさらに確認するには --tail <n> を指定します）。再試行する前に、--help も再確認してください。CLI の問題を回避するためにサーバーや設定を変更してはいけません。

1. コールドスタート／ライフサイクル（features.coldStart）

REST では決して実現できない唯一の機能です。エディターが起動していないときに、エディターを起動します。

<cliPath> status --format json          # any editor instances running?
<cliPath> open "<projectPath>" --args -unityskills-coldstart

コールドスタート時は必ず --args -unityskills-coldstart を渡してください。UnitySkills プラグインはエディターの起動時にこのマーカーを検出し、ユーザーの自動起動設定がオフでも、このセッションの REST サーバーを強制的に起動します。マーカーを付けない場合は、ユーザーが保存した設定に依存します。このマーカーはエディターセッションごとに一度だけ消費され、セッション中に手動で停止した場合に、それを上書きすることはありません。

事前確認 — 読み取り専用で、機能スイッチは不要です。 open／test／run／build はすべて、プロジェクトの ProjectVersion.txt からエディターを特定します。セッション中に CLI を初めて起動する前に、次の確認を実行してください。どれもプロジェクトを変更しません。

<cliPath> editors -i --format json                       # all versions: is the bound editorVersion installed?
<cliPath> doctor --ci --format json                      # beta6+: exit 6 = definitive blocker, 7 = retryable
<cliPath> projects verify "<projectPath>" --format json  # beta6+: exit 6 = errors, 0 = clean or warnings only

• doctor --ci（プロジェクトルートから実行）は、ライセンス、プロジェクトのエディター、ディスク容量、Unity サービスを確認します。errors[].code（LICENSE_NONE、EDITOR_NOT_INSTALLED、DISK_SPACE_LOW、NETWORK_UNREACHABLE）に応じて処理します。6 → 停止して報告、7 → 数回再試行してからユーザーに伝えます。通常の doctor は常に 0 で終了します。macOS では beta6～8 がキーチェーンのプロンプトで停止することがあるため、シェルのタイムアウトで囲んでください。
• projects verify はエディター、ライセンス、ネットワークを必要とせず、次の項目だけを検出します。META_MISSING／META_ORPHAN／GUID_DUPLICATE／CONFLICT_MARKERS／MANIFEST_INVALID は終了コード 6 です。報告し、手動で修復してはいけません。警告（--expect-editor <version> による PATH_UNVERIFIABLE、EDITOR_VERSION_DRIFT）は、--strict を指定しない限り終了コード 0 です。

エディターがインストールされていない場合は、停止してユーザーに伝えてください。install を実行したり、--allow-install を渡したりしてはいけません（「禁止事項」を参照）。

起動後、UnitySkills REST サーバーの準備が整うまでポーリングしてください（初回のインポート／コンパイルには数分かかる場合があります）。

from unity_skills import wait_for_health
health = wait_for_health(timeout=600)   # polls /health on ports 8090-8100

beta9 以降では、CLI の短い監視時間内にエディターが終了すると、open は 6（OPEN_EDITOR_EXITED）で終了します。その場合は wait_for_health を待たず、直ちに報告してください。この監視時間内の終了のみが対象です。エディターがその後に終了しても検知されず、古いバイナリはどのような場合も 0 で終了するため、wait_for_health のタイムアウトが実際の失敗を示すシグナルとなります。

稼働状況の切り分け — やみくもに再試行するより、こちらを優先してください。 REST に接続できない場合は、コールドスタートを決める前にエディターが実際に起動しているかを確認してください。

1. まず、プロジェクト独自の cli_config.json を読み取ります。 ファイルが存在し、enabled: true の場合にのみ続行してください。
2. UnitySkills レジストリを確認します。 ~/.unity_skills/registry.json を読み、path がプロジェクトルートと一致するエントリーを見つけ、その pid を確認します（ps -p <pid>／Windows の tasklist）。PID が有効なら、エディターは起動中ですが処理中です（ドメインリロード／インポート）。通常の REST の待機と再試行を続け、コールドスタートはしないでください。
3. CLI のプロセス一覧と照合します。 <cliPath> editors running --format json --non-interactive には、CLI が認識できるエディターインスタンスが一覧表示されます。確認材料として役立ちますが、CLI のバックエンドが認識するインスタンスのみが対象です。
4. Library/UnityLockfile を確認します。 ロックファイルが保持されている場合は、レジストリーのエントリーがなくても、このプロジェクトでエディターインスタンスが開いています。
5. <cliPath> status は補足情報であり、確定的な情報ではありません。Unity Pipeline の接続状態のみを反映します。テーブルが空、または終了コードがゼロ以外でも、エディターが閉じているとは限りません。実際に確認したところ、Pipeline パッケージのない起動中のエディターは何も表示されません。

PID、CLI のプロセス一覧、またはロックファイルによって、このプロジェクトでエディターがすでに起動していると判断できる場合は、open、run、build を実行してはいけません。同じプロジェクトでの2つ目のインスタンスの起動は Unity に拒否されます。上記のどの方法でも、このプロジェクトで起動中のエディターが確認されない場合に限り、open でコールドスタートしてから wait_for_health を実行してください。

2. 引数を指定して起動（features.openArgs）

<cliPath> open "<projectPath>" --args -openscene "Assets/Scenes/Main.unity"

--args の後に指定したものはすべて、標準のコマンドライン引数として Unity Editor に渡されます。特定のシーンや独自の -executeMethod などを指定して、既知の状態で起動する場合に便利です。指定できるのは起動時のみです。起動済みのエディターでは、代わりに REST の scene_load を使用してください。

3. ヘッドレステスト（features.cliTest）

<cliPath> test "<projectPath>" --mode EditMode --filter <pattern> --output test-results.xml --timeout 1800

• --mode <EditMode|PlayMode> — 省略すると、エディターのデフォルトのテストプラットフォームで実行します。両方のモードをテストするには、2 回に分けて実行します。
• --filter <pattern> — 名前が一致するテストのみを実行します。
• --output <path> — NUnit XML レポート（デフォルトは test-results.xml）。CI では、引き続きこのファイルをテスト結果として使用します。
• CI 専用パラメーター — test --help にはレポート／カバレッジのフラグ（beta4 以降：--report-format nunit,junit、--junit-output、--coverage*）と、beta6 以降では --shard N/M、--retries N（失敗したテストのみを再実行し、試行ごとに --timeout を適用します。フレークするテストは test-results.retries.json に記録され、1 度も成功しないテストがある場合は引き続き終了コード 8 になります）、--rerun-failed（--output から失敗したテストを読み込み、test-results.rerun.xml に書き込みます）が表示されることがあります。beta9 以降の --affected --since <ref> は、変更の影響が及ぶ可能性のあるテストのみを実行します（近似判定であり、test-results.affected.xml に書き込みます）。信頼して使う前に、まず --affected-compare を実行して偽陰性率を測定してください。セレクターは相互に排他的です。パラメーターは、現在のバイナリの test --help に記載されている場合のみ使用してください。名前を推測してはいけません。
• --timeout <seconds>（環境変数 UNITY_TEST_TIMEOUT）— N 秒後に Unity プロセスを強制終了します。デフォルトでは無効です。無人実行では必ず設定してください。
• 追加のエディター引数は -- の後に渡します（例：-- -nographics）。
• 終了コード：0 はすべて成功（--retries によってフレークするテストが成功した場合も同様ですが、フレークしたことは引き続き報告されます）。beta6 以降：8 はテスト失敗（errors[0].code は TESTS_FAILED）、6 は判定不能 — コンパイルエラー、ライセンスエラー、エディターのクラッシュ（TEST_RUN_ERROR）、または --timeout の期限切れ（TEST_TIMED_OUT）。beta3～5：6 は両方を意味します。XML を確認して区別してください。7 は CLI の再試行後も Unity サービスに到達できない場合、130 は SIGINT、143 は SIGTERM です。それ以外のゼロ以外の値はコマンド自体の失敗です。XML だけでなく、stderr、JSON エンベロープ、errors[].code を確認してください。6／7 は可能な場合のみ再試行し、8 は再試行してはいけません。

ルーティングのルール：

• 対話的な反復作業（エディターがすでに起動しており、少数のテストにすばやくフィードバックが必要）→ REST の test_* スキル。
• 完全な回帰テスト／CI 形式の実行、またはエディターが閉じている場合 → unity test（ヘッドレス、NUnit XML を出力）。エディターが開いているプロジェクトに対して unity test を実行してはいけません。

4. バッチ実行（features.cliRun）

バインドされたプロジェクトのみを対象に、エディターが閉じている状態で実行するワンショットのバッチ自動化です。REST（エディター起動中、対話型）とコールドスタート（起動して稼働状態を維持）の間に位置する、3 つ目のライフサイクルオプションです。

<cliPath> run "<projectPath>" --timeout 1800 -- -executeMethod Your.Static.Method -quit

• -- より後のすべての引数は、標準のコマンドライン引数として Unity Editor に渡されます。典型的な形式は -executeMethod <static method> と -quit の組み合わせです（アセットの再インポート、バッチ修正、カスタムパイプラインなど）。
• エディターログを stdout にストリーミングし、エディターの終了コードを返します。ゼロ以外の場合、バッチ実行は失敗です。beta5 以降では、エディターのクラッシュは stopped with signal SIG… と報告されます（§6 を参照）。これはエディターのクラッシュであり、ビジネスロジックの失敗ではありません。
• --timeout <seconds>（環境変数 UNITY_RUN_TIMEOUT）— デフォルトでは無効です。必ず設定してください。設定しないと、バッチエディターがハングした場合にシェルが永久にブロックされる可能性があります。
• ルーティング：エディターがすでに起動している → REST スキルを使用し、run は使用しないでください（Unity は同じプロジェクトでの 2 つ目のインスタンスを拒否します。コールドスタートと同じ Library/UnityLockfile のルールが適用されます）。エディターが閉じており、永続的なセッションが必要 → コールドスタート。エディターが閉じており、ワンショットのタスクを実行する → run。
• run --command <name> は Unity Pipeline パッケージのコマンドを実行します。これはこのワークフローの対象外です（DO NOT を参照）。

5. ヘッドレスビルド（features.cliBuild）

cliBuild はデフォルトではオフです。ユーザーが有効にした場合は、インストールされている CLI のバージョン、Unity Editor のバージョン、ターゲットプラットフォーム、Build Profile の有無に基づいてビルドパスを選択します。

パス 1 — Unity 6 の Build Profile（beta4 以降）

<cliPath> build "<projectPath>" --profile "Windows" --output-path ./Builds/win64

• --profile には、Build Profile アセットのパス、または Build Profile ウィンドウに表示されるプロファイル名を指定できます。
• Unity 6（6000.x）と、設定済みの Build Profile が必要です。

パス 2 — ビルトインのデスクトップビルド（beta4+）

<cliPath> build "<projectPath>" --target StandaloneWindows64 --output-path ./Builds/win64

• --target は引き続き必須です。
• デスクトップターゲットでは、beta4 以降、--execute-method は任意です。--output-path が指定されている場合、CLI はビルトインのデスクトップビルドを実行できます。

パス 3 — カスタム C# ビルドメソッド（全バージョンで利用可能、モバイル／WebGL では必須）

<cliPath> build "<projectPath>" --target Android --execute-method Builder.PerformBuild --output-path ./Builds/android

• --execute-method は引き続き使用でき、指定した場合は優先されます。Android、iOS、WebGL、またはすでにカスタムビルドパイプラインがあるプロジェクトでは、これを使用してください。
• --output-path は -buildOutput として Unity に渡されます。値の読み取りは execute-method 自体が担います。
• プロジェクトに静的ビルドメソッドがまだない場合、ユーザーにそのことを伝えてください。求められていないのに、プロジェクトにメソッドを書き加えてはいけません。

共通のビルドフラグ

• ビルドログはデフォルトで末尾部分が標準出力に表示されます（無効にするには --no-tail を指定します）。--log-file で別の場所を指定しない限り、ログ全体は <project>/Logs/build-<target>-<timestamp>.log に保存されます。beta6 以降では、ビルドされた内容（ビルド失敗時も含む）を記録した <output>.provenance.json も成果物と同じ場所に書き込まれます（スキップするには --no-provenance を指定します）。
• --timeout <seconds>（環境変数 UNITY_BUILD_TIMEOUT、beta6 以降）—ビルドを中断して終了コード 6 で終了します。デフォルトでは無効です。無人ビルドでは必ずタイムアウトを設定してください。beta6 以降の json/ndjson にはハートビートフレームも含まれます（経過時間と、ログの最終更新からの秒数。--quiet を指定した場合も含む）。Editor が停止した場合は、出力が途絶えるのではなく、ログの更新間隔が長くなります。
• ダーティーワークツリーのガード：未コミットの変更がある場合、build は実行されません。この保護は意図的なものです。ユーザーが明示的に許可した場合にのみ --allow-dirty-build を渡してください。
• --versioning-strategy <semantic|tag|custom|none>（デフォルトは none）は、git のタグ／履歴からビルドバージョンを設定します。--build-version は custom の場合にのみ適用されます。
• Android：--android-export-type <apk|aab|android-studio-project> とキーストア／署名用のフラグが用意されていますが、コマンドライン上のシークレットはシェル履歴や CI ログに漏れる可能性があります。署名はユーザー自身に対応してもらい、キーストアのパスワードをシェルコマンドに貼り付けるよう求めてはいけません。
• run と同じライフサイクルルールが適用されます。対象はバインド済みのプロジェクトに限られ、エディターは閉じている必要があります。エディターが再び起動した後は、通常の操作はすべて REST 経由で行います。
• 終了コード／シグナル：0 は成功、6 はビルド失敗、--timeout の期限超過（beta6 以降）、または Editor の異常終了、7 は再試行後も Unity サービスに接続できない場合、130 は SIGINT、143 は SIGTERM です。beta5 以降では、Editor のクラッシュは stopped with signal SIG… と報告されます（§6 を参照）。これを BUILD_FAILED とは別のものとして扱ってください。

6. 自動化の契約（すべてのコマンド）

• 構造化出力：--format <human|json|tsv|ndjson>（環境変数 UNITY_FORMAT）；--json は --format json の短縮形です。標準出力がパイプに渡される場合、既定値は通知なしで TSV になります。そのため、常に --format json を明示的に指定することをおすすめします。JSON レスポンスでは標準エンベロープ {success, command, data, errors, warnings} が使われます。ndjson は、実行時間の長いコマンドの進行状況イベントをストリーミングします。
• 非対話モード：--non-interactive（環境変数 UNITY_NON_INTERACTIVE）を指定すると、プロンプトがシェルを停止させる代わりに致命的なエラーになります。--quiet（環境変数 UNITY_QUIET）および --no-banner（環境変数 UNITY_NO_BANNER）と組み合わせると、機械処理に適した出力になります。
• スクリプトからの呼び出しに推奨される環境変数（推奨設定。上記のフラグと同等です）：
  • UNITY_NON_INTERACTIVE=1 — 対話型プロンプトを無効にします。
  • UNITY_FORMAT=json — 既定の出力形式です。両方が設定されている場合は、コマンドラインの --format が優先されます。
  • UNITY_NO_PAGER=1 — 長い出力をページャーで表示しません（beta4+ では対話型ターミナルでページャーが使用されます）。
  • UNITY_NO_CRASH_REPORT=1 — Sentry による匿名クラッシュレポートの送信をオプトアウトします（beta3+）。
  • UNITY_NO_CLI_INVOKED_TELEMETRY=1 — 実行ごとの使用状況の送信をオプトアウトします（beta9+。分析機能のオプトインとは別です）。
• エラーと終了コード：データは標準出力に、エラーや診断情報は標準エラー出力に送られます（JSON モードのエラーも同様です）。JSON エンベロープ、errors[].code、標準エラー出力を必ず併せて確認してください。終了コードだけに頼らないでください。

終了コード	意味
0	成功。
1	一般的なエラー — 標準エラー出力または JSON の errors を確認してください。
2	使用方法または引数のエラー（コマンドが間違っている、必須フラグがない）。
3	認証または認可の失敗。
4	必須の設定がありません。
6	主要な操作が失敗したか、判定に至りませんでした — ビルドの失敗、--timeout の期限切れ（beta6+）、Editor の異常終了またはクラッシュ、判定結果のない test（beta6+。beta3–5 では失敗したテストもここに含まれます）、doctor --ci による明確なブロッカーの検出、projects verify のエラー、監視中に Editor が終了した open（beta9+、OPEN_EDITOR_EXITED）。
7	CLI による再試行後も Unity サービスに到達できない、または doctor --ci が判定に至りませんでした（beta6+）。再試行は回数を制限してください。6 は最終的なエラーで、7 は一時的な可能性があります。
8	テストに失敗しました（test、beta6+、TESTS_FAILED）。再試行しないでください。beta3–5 では 6 として報告されます。
130	ユーザーがキャンセルしました（SIGINT / Ctrl+C）。
143	SIGTERM によって終了しました。

• NDJSON ストリーミング：リアルタイムの進行状況を確認するには、--format ndjson を使用します。beta4 以降、ストリームは最終的に type=result の終端フレームで終了します。最終状態には、進行状況フレームや標準エラー出力の行ではなく、最後の {"type":"result","success":...} フレームを使用してください。beta3 では結果フレームが出力されないため、終了コードと標準エラー出力を使用してください。
• シグナルによるクラッシュ（beta5+）：build／test／run は、Editor のクラッシュを stopped with signal SIGSEGV/SIGILL/SIGTRAP/SIGFPE/SIGBUS と報告します。これらは、業務上の失敗（beta6+ の TESTS_FAILED／それ以前の TEST_FAILED、BUILD_FAILED）や、CLI 側の失敗（引数、設定、ネットワーク、認証）と区別してください。
• --verbose はスタックトレースを含むエラーの詳細をすべて表示します。CLI の問題をユーザーに報告する際に、一度だけ使用すると便利です。

禁止事項

• cli_config.json が存在しないか、enabled:false の場合は CLI を使用しないでください。ユーザーは使用を許可していません。バインドされたプロジェクトのみ（設定ファイルが見つかったディレクトリ）を操作し、他のプロジェクトを open／test／run／build しないでください。
• Unity CLI を自分でインストールしないでください。インストールするかどうかは、パネルでユーザーが決定します。
• --allow-install を渡さないでください（test／run／build で受け付けられます）。また、ユーザーから明示的に依頼されない限り、unity install／install-modules／uninstall／editors upgrade／hub／ライセンス関連のコマンドを使用しないでください。エディターのインストール、アップグレード、削除は時間がかかり、システムに変更を加える大規模な操作であり、ユーザーだけが行うべきです。
• unity mcp をそのまま実行しないでください。ブロッキング状態の stdio MCP サーバーが起動し、クライアントを待機するため、シェルがハングします。
• unity command／unity pipeline／unity run --command を使用しないでください。Unity Pipeline パッケージの経路は UnitySkills REST がすでに提供している機能と重複しており、このワークフローには含まれません。
• unity projects exec や unity projects clean を使用しないでください。これらは複数のプロジェクトを対象とし、「バインドされたプロジェクトのみを操作する」という境界に反します。
• unity projects create|new|clone|link|unlink|upgrade、unity templates、unity cloud、unity collab、または読み取り専用の status／diff／summarize／affected／conflicts／explain／providers 以外の unity vcs 動詞を使用しないでください。これらは、バインドされたプロジェクトの境界外にあるプロジェクトやリポジトリ（ローカル、リモート、Unity Cloud）を作成、移動、書き換えます。projects create は beta8+ でデフォルトでクラウドに対応しています。
• ユーザーから明示的に依頼されない限り、unity close／projects close（beta8+）を使用しないでください。これらは 保存せずに Editor を終了します。正常に終了するには com.unity.pipeline が必要です（ない場合は pipeline_missing となり、終了操作をユーザーに戻します）。また、--force（SIGTERM→SIGKILL）を渡すことは決してできません。まず REST 経由で保存してください。
• unity editors prune や unity editors verify を使用しないでください。これらはグローバルな Editor のインストール構成を変更または検証するものであり、プロジェクトのライフサイクルの範囲外です。
• unity command --detach、unity eval --detach、unity job を使用しないでください。デタッチされたコマンドとジョブキューは、バインドされたプロジェクトのワークフローとは異なる制御チャネルです。
• unity skill install や unity skill refresh を使用しないでください。これらは AI クライアントの設定ディレクトリに書き込みます。また、公式スキルは UnitySkills 独自の助言や機能制限を回避する可能性があります。スキルのインストールは、パネルでユーザーが決定します。unity skill show（beta9+）で読み取ることは問題ありません。Gate を参照してください。
• unity shell --protocol ndjson を使用しないでください。これは beta3 のウォームプロセス用マシンプロトコルであり、公式 MCP 経路と同等のため、このワークフローには含まれません。
• CLI に自己更新（unity self-update、別名 upgrade、self-install／self-uninstall、Homebrew、winget など）をさせたり、同梱ツールを管理（unity plugin install|remove|upgrade、beta8+）させたりしないでください。更新とインストールはユーザーが決定します。
• CLI の人間向け出力を解析しないでください（表示言語は unity language に従います。たとえば、表の見出しが中国語になる場合があります）。プログラムから結果を読み取る必要がある場合は、必ず --format json --non-interactive を渡してください。
• CLI が使えることを REST ワークフローの代わりとみなさないでください。/health が応答した後は、通常の操作はすべて REST スキル経由で行ってください。

7. Linux の互換性に関する注意事項

beta4 以降、Unity CLI を Linux で使用するには glibc 2.34 以降が必要です。また、Ubuntu 20.04 以前、Debian 11、RHEL/CentOS 8、Amazon Linux 2 はサポート対象外になりました。これらのシステムでは、通常の「コマンドが見つかりません」というエラーではなく、glibc 関連のエラーが発生して CLI の起動に失敗する場合があります。

これを「CLI がインストールされていない」と判断して、ユーザーに再インストールを促さないでください。代わりに互換性の制約を示してください。インストールされているバイナリは、この OS/glibc バージョンでは実行できません。選択肢は、beta3 の機能を使い続ける、OS をアップグレードする、または別のマシンを使用することです。UnitySkills によってグローバルな最小バージョンが強制されることはありません。機能は CLI の実際の動作に応じて分岐します。

• beta3 — 従来の build セマンティクス（--execute-method が必須）。NDJSON のターミナル結果フレームはありません。
• beta4+ — Build Profile に対応し、デスクトップビルドを内蔵。NDJSON のターミナル type=result フレームに対応します。
• beta5+ — 名前付きの Editor シグナル診断（SIGSEGV、SIGILL、SIGTRAP、SIGFPE、SIGBUS）に対応します。
• beta6+ — test の終了コード 8 = 失敗 / 6 = 判定なし、build --timeout、doctor --ci、projects verify、test --shard/--retries/--rerun-failed、来歴マニフェスト <output>.provenance.json に対応します。
• beta8+ — unity close と vcs / plugin コマンドグループ（DO NOT を参照）、unity upgrade が self-update に名称変更（エイリアスは維持）、projects create がデフォルトで Unity Cloud プロジェクトを作成します。
• beta9+ — Editor が早期終了した場合、open は終了コード 6 / OPEN_EDITOR_EXITED を返します（以前は常に 0）。build はすでに開いているプロジェクトを拒否します。test --affected、読み取り専用の skill show、version --format json、UNITY_NO_CLI_INVOKED_TELEMETRY=1 に対応します。doctor は macOS のキーチェーンプロンプトでハングしなくなりました。projects verify はネイティブプラグインフォルダー（.bundle/.framework/.androidlib/.plugin）を誤ってフラグ付けしなくなりました。

最も安全な分岐方法は、セッションの開始時に <cliPath> --version（beta9 以降は version --format json）と <cliPath> <command> --help を実行し、バイナリが実際に報告する内容に基づいて処理することです。

正確なシグネチャ

正確な名前、パラメーター、デフォルト値、戻り値は、このファイルではなく、GET /skills/schema または unity_skills.get_skill_schema() で定義されています。