菜单
void2610 の Unity プロジェクト共通コーディング規約。Unity の C# コード（MonoBehaviour / ScriptableObject / ゲームロジック）を新規作成・編集・レビューするときに参照する。SerializeField の扱い、命名規則（private フィールドの `_` プレフィックス）、R3 の Subject<T> によるイベント、UniTask、式本体メソッド、メンバー宣言順序、enum の summary コメントなど、カスタム Roslyn アナライザー（VUA1001〜VUA4001）で強制しているルールを説明する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
**Unity の UI View (MonoBehaviour) を実装・新規作成・修正するときは必ずこのスキルを呼ぶこと。** 画面・パネル・ダイアログ・オーバーレイ・リスト等、Image / TMP / Button / CanvasGroup を含む UI を伴う View を作るあらゆる場面で発動する。Prefab + SerializeField で構築する手順を定める。
自作ライブラリ submodule (my-unity-utils / my-unity-settings / unity-coding-standards / novel-kit 等) を修正するときの Git 運用方針。submodule 側には PR を作らず main へ直接マージし、PR は利用側プロジェクトの submodule ポインタ更新として出す。ブランチの切り方、コミット・マージ・ポインタ更新の順序、巻き込み禁止ルール、reusable workflow (@main 参照) の反映タイミングを定める。ライブラリと本体の 2 リポジトリにまたがる変更を扱うときに必ず参照する。
uloop などで Unity Editor を自律操作している最中に、Unity の確認ダイアログ・モーダル・中断メッセージで自動化が無言で固まる／中断するのを、ユーザーにクリックを頼まずコードで解消して進める方法。特に「未保存のシーン変更があるため中断」でテスト実行・Play 入場がブロックされたとき、Domain Reload 後にシーンが dirty になったとき、モーダルで uloop コマンドが返ってこないときに参照する。「Unity 側でボタンを押してください」と頼む前にこの手順で自力解消する。
LiminalPalette（Unity 用汎用デバッグコンソール）の `liminal-*` skill 群をいつ・どう使うかの運用方針。Unity ゲームのランタイム動作確認・回帰テスト・状態観測をするとき、[LiminalCommand] / [LiminalScenario] / [LiminalObservableField] を HTTP API 経由で叩くとき、あるいは「変更後にゲームを起動して目視確認して」と頼みたくなったときに参照する。検証をその場で消費せず [LiminalScenario] として資産化する運用ルールを含む。実際の liminal-* skill 実体は liminal-palette パッケージ側に同梱される。
Unity Editor を外から操作する `uloop-*` skill 群をいつ・どう使うかの運用方針。コード編集後のコンパイル確認・EditMode/PlayMode テスト実行・シーン階層の把握・SerializeField 参照ワイヤリング・スクリーンショット・メニュー操作・Play モード制御など、開発ワークフロー内の Unity Editor 操作をするときに参照する。ランタイムのゲーム動作確認・回帰テストは対象外（それは liminal-palette-guide 側）で、使ってはいけない uloop skill も列挙する。
基于 SOC 职业分类
| name | unity-coding-standards |
| description | void2610 の Unity プロジェクト共通コーディング規約。Unity の C# コード（MonoBehaviour / ScriptableObject / ゲームロジック）を新規作成・編集・レビューするときに参照する。SerializeField の扱い、命名規則（private フィールドの `_` プレフィックス）、R3 の Subject<T> によるイベント、UniTask、式本体メソッド、メンバー宣言順序、enum の summary コメントなど、カスタム Roslyn アナライザー（VUA1001〜VUA4001）で強制しているルールを説明する。 |
unity-coding-standards リポジトリで配布しているカスタム Roslyn アナライザー（Void2610.Unity.Analyzers）が強制する規約。Unity プロジェクトの C# を書く／直す／レビューするときは、以下に沿うこと。CI では run-format.sh --verify-no-changes でこれらが検証される。
| ID | カテゴリ | 重大度 | 説明 |
|---|---|---|---|
| VUA1001 | Design | Warning | [SerializeField] フィールドに対する防御的 null チェックを禁止 |
| VUA1002 | Design | Warning | C# 標準イベント/デリゲート禁止（R3 の Subject<T> を使用。報告のみ・自動修正なし＝呼び出し側を含む手動置換が必要） |
| VUA1003 | Design | Warning | if(IsActive()) Cancel() ではなく TryCancel() を使用 |
| VUA1004 | Design | Warning | StartCoroutine の使用を禁止（UniTask などの代替を使用） |
| VUA2001 | Naming | Warning | [SerializeField] フィールドに _ プレフィックスを付けない |
| VUA2002 | Naming | Warning | private フィールドに _ プレフィックス必須 |
| VUA3001 | Style | Warning | 単一文の public メソッドには式本体 (=>) を使用 |
| VUA3002 | Style | Warning | クラスメンバーの宣言順序を強制 |
| VUA4001 | Documentation | Warning | トップレベル enum メンバーに /// <summary> コメント必須 |
[SerializeField] は Inspector で必ずワイヤリングされる前提。if (_target == null) return; のような防御コードは、本来 Inspector 設定漏れとして気づくべきバグを握り潰す。null なら早期に例外で気づかせる。Subject<T>: C# の event・Action・Func を公開通知に使わない。R3 の Subject<T> を持ち、外へは AsObservable() で公開する。※このルールは報告のみで自動修正されないため、購読側（+= / -=）も含めて手動で置き換える。if (IsActive()) Cancel() ではなく TryCancel(): 「状態を確認してから操作」の 2 段構えは競合しやすい。TryXxx() として 1 メソッドに畳み、内部で状態確認と操作を完結させる。StartCoroutine 禁止: コルーチンではなく UniTask（async UniTask / CancellationToken）で非同期を書く。キャンセル・例外・戻り値の扱いが素直になる。_ を付けない: [SerializeField] private int health;（_health にしない）。Inspector に表示される名前を素直に保つ。_ 必須: SerializeField でない純粋な private フィールドは _camelCase（例: private int _counter;）。VUA2001 と対になり、「_ の有無」で SerializeField かどうかが一目で分かる。public int Double(int x) => x * 2; の式本体形式にする。.editorconfig / アナライザーの定義に従う。/// <summary> を付ける。局所的に無効化したいときだけ #pragma warning disable を使う（濫用しない）:
#pragma warning disable VUA1001
// ここでは警告が出ない
#pragma warning restore VUA1001
リポジトリを submodule として追加し、scripts/init-unity-project.sh で .editorconfig / Directory.Build.props / Directory.Build.targets / FormatCheck.csproj を symlink する。整形は個別コマンドではなく scripts/run-format.sh（analyzers / whitespace / style をまとめて実行）を使う。CI では run-format.sh --verify-no-changes。詳細は リポジトリの README を参照。