メニュー
**Unity の UI View (MonoBehaviour) を実装・新規作成・修正するときは必ずこのスキルを呼ぶこと。** 画面・パネル・ダイアログ・オーバーレイ・リスト等、Image / TMP / Button / CanvasGroup を含む UI を伴う View を作るあらゆる場面で発動する。Prefab + SerializeField で構築する手順を定める。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
自作ライブラリ 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 も列挙する。
void2610 の Unity プロジェクト共通コーディング規約。Unity の C# コード（MonoBehaviour / ScriptableObject / ゲームロジック）を新規作成・編集・レビューするときに参照する。SerializeField の扱い、命名規則（private フィールドの `_` プレフィックス）、R3 の Subject<T> によるイベント、UniTask、式本体メソッド、メンバー宣言順序、enum の summary コメントなど、カスタム Roslyn アナライザー（VUA1001〜VUA4001）で強制しているルールを説明する。
| name | prefab-view |
| description | **Unity の UI View (MonoBehaviour) を実装・新規作成・修正するときは必ずこのスキルを呼ぶこと。** 画面・パネル・ダイアログ・オーバーレイ・リスト等、Image / TMP / Button / CanvasGroup を含む UI を伴う View を作るあらゆる場面で発動する。Prefab + SerializeField で構築する手順を定める。 |
Unity の UI View を 最初から Prefab + SerializeField で作るための標準手順。UI 階層をコードで組む (new GameObject / AddComponent で Image / TMP / Button / CanvasGroup 等を生成する) ことは禁止 (CLAUDE.md「UI構築原則」)。新しい View を実装するとき、コードで UI を組み始める前にこの手順に沿う。
[SerializeField] 参照と表示ロジックだけを持つ。Assets/Scripts/Utils/Core/Extensions/LitMotionExtensions.cs に既存のアニメーション拡張メソッド群がある。View のアニメーション・表示演出はこのファイルを起点に考える (フェード・スライド等、CanvasGroup / Image / TextMeshProUGUI / SpriteRenderer / RectTransform 等の拡張が揃っている)。新しい演出が要る場面では まずこのファイルを grep してから LMotion.Create(...) を書き始める (詳細は下「鉄則: 表示/非表示は CanvasGroup、アニメーションは LitMotion + Utils 拡張メソッド」)。作る UI を 2 種類に仕分けてから Prefab を設計する。
| 種別 | 例 | 置き場所 | View からの参照 |
|---|---|---|---|
| 固定要素 (1 個で、表示/非表示を切り替えるだけ) | ルート / コンテナ / タブバー / 全画面プレビュー / 閉じるボタン / ラベル | View の Prefab 内に配置 | [SerializeField] で直接参照 |
| 反復要素 (データ数だけ動的に増減する) | タブ / グリッドのセル / リスト行 / トースト | 独立した Prefab ファイルに切り出す | [SerializeField] GameObject xxxPrefab を保持し Instantiate |
反復要素を独立 Prefab に切り出す理由: View 本体の Prefab に「非活性テンプレート」を同居させる方式より、Prefab ファイルが分かれる方が git の差分がファイル単位で追え、編集の衝突も減る。テンプレートを View 内にコピーとして持たない。
Instantiate(xxxPrefab, parent) は正当な生成 (Prefab 参照からの複製)。禁止されるのは new GameObject / AddComponent での階層組み立て。
ボタン・テキスト・トグル・スライダー等の UI プリミティブは自前で組まない。プロジェクトには基底 Prefab が 必ず存在する ので、まず探して再利用する。 同じ見た目・挙動 (SE / ホバー演出 / フォント配線) が全 View で揃い、二重メンテを避けられる。 基底が見つからない場合、ユーザーに新規作成の可否を確認する。
ls Assets/Prefabs/UI/Buttons/ と Assets/Prefabs/UI/<機能>/ を確認する。ボタンなら TextButton / IconButton / ChoiceButton 等、設定 UI なら Settings_* が既にある。Instantiate) して、ラベル文字やクリックだけを差し込む。new GameObject(...) + AddComponent<Button>() や TMP を手で組み立てるのは、この探索をサボった兆候。まず既存 Prefab を探す。
LMotion) を使う。Coroutine + 手書き lerp や Update でのフレーム毎手動補間は書かない。LMotion.Create(...) を直接組み立てる前に、必ず Assets/Scripts/Utils/Core/Extensions/LitMotionExtensions.cs を grep して既存の拡張メソッドを探す (車輪の再発明禁止 → [[check-utils-before-implementing]])。フェード: CanvasGroup.FadeIn(duration) / FadeOut(duration) / FadeTo(duration, alpha)、Image.FadeIn / FadeOut、TextMeshProUGUI.FadeIn / FadeOut など。完了時に interactable / blocksRaycasts を追従させる後処理も内包済みなので、手動で LMotion.Create(...).BindToAlpha(...) を書く前に必ず確認する。
LMotion.Create(...) を直接組み立てる。その際も、他 View で同じ動きが今後も要りそうなら LitMotionExtensions.cs に拡張メソッドとして足すことを検討する (一点物として View 内に埋め込まない)。GameObject.SetActive ではなく CanvasGroup を積極的に使う (alpha / interactable / blocksRaycasts)。フェード演出が後から必要になっても構造を変えずに済み、SetActive(false) で失われる「非表示中もコルーチン/Tween/RectTransform 計算を継続させたい」ケースにも対応できる。
Void2610.UnityTemplate.CanvasGroupExtensions の Show() / Hide() を使う (alpha/interactable/blocksRaycasts を一括設定、手で3行書かない)。LitMotionExtensions.cs の CanvasGroup.FadeIn() / FadeOut() を使う。SetActive を使ってよいのは、非表示中に一切の処理 (Tween 状態・RectTransform 計算・子オブジェクトの Update) を継続させる必要がない、純粋な ON/OFF のみ (例: ページめくりで前面画像を丸ごと隠す等)。表示状態の一部としてフェード演出が絡む対象は CanvasGroup にする。シーンの Canvas は原則 1 つ。View / オーバーレイ / ダイアログの Prefab に Canvas (+ CanvasScaler / GraphicRaycaster) を持たせない。UI ルートは素の RectTransform (全画面なら anchor 0..1 ストレッチ) にし、シーンの既存 Canvas 配下に配置する (InstantiatePrefab(prefab, canvas.transform))。既存 View も Canvas を持たず単一 Canvas 配下にぶら下がる形にする。
SetAsLastSibling)。描画順は階層順で決まる。overrideSorting / 専用 sortingOrder が本当に要る特殊用途 (別カメラ描画・ワールド空間 UI 等) は、着手前にユーザーへ明示許可を求める。勝手に増やさない。RectTransform は m_LocalScale を必ず {1,1,1} にする (0 のまま保存すると実行時に UI 全体が消える)。このプロジェクトの画面比率は 16:9 に完全固定で、解像度が変わるレスポンシブ対応は行わない。この前提があるため、要素の配置調整は アンカー (m_AnchorMin/m_AnchorMax) やプリセットを変更するのではなく、m_AnchoredPosition (相対座標) と m_SizeDelta (サイズ) の数値だけで行う。
anchoredPosition / sizeDelta を変更する。アンカーを変えると「基準点が変わる」ため既存の座標計算・スクリプト側のレイアウト前提 (中央寄せ計算等) が壊れやすく、原則として変更しない。0.5,0.5 かフルストレッチ 0,0-1,1 か) に 合わせる。View ごと・要素ごとにアンカー方式が混在すると、後から座標を追う人間にとって計算が複雑になる (「このオブジェクトはどの基準点から何px か」を要素ごとに調べ直す必要が生じる)。ls Assets/Prefabs/UI/Buttons/ 等)。見つけた基底 Prefab を再利用する前提で設計する (上「鉄則」)。XxxRow.prefab、グリッド → XxxCell.prefab)。anchoredPosition/sizeDelta の相対値で決める (上「鉄則: 画面比率は 16:9 固定」)。[SerializeField] フィールド、反復要素は [SerializeField] GameObject xxxPrefab。[SerializeField] CanvasGroup で持つ (GameObject で持って SetActive するのではなく)。表示演出は CanvasGroupExtensions.Show()/Hide() かフェードが要れば LitMotionExtensions の FadeIn()/FadeOut() を使う (上「鉄則: 表示/非表示は CanvasGroup」)。Instantiate(xxxPrefab, parent) → 中の Image/TMP/Button を GetComponent / GetComponentInChildren で取り出して値を差し込む。独立 Prefab はアクティブなルートで保存するので複製後の SetActive(true) は不要。[SerializeField] に手動 null チェックを書かない (アナライザ VUA1001。設定ミスは即クラッシュさせる方針)。FindFirstObjectByType で得た View も同様。FindFirstObjectByType<TMP_Text>().font や xxx.font = template.font は書かない)。フォントは Prefab の TMP にエディタ設定する。FindFirstObjectByType<XxxView>() で取得する (Presenter コンストラクタ、DI設計原則)。UI 階層の組み立ては uloop execute-dynamic-code (Editor操作skill) でまとめて行う。
uloop は MCP ではなく CLI ツールである。uloop-* skill から利用すること (→ uloop-guide skill)。
SaveAsPrefabAsset(go, "Assets/Prefabs/UI/**/XxxCell.prefab") で独立ファイル化。アクティブなルート (SetActive(true)) で保存する。new SerializedObject(view) → FindProperty("フィールド名").objectReferenceValue = 参照 → ApplyModifiedPropertiesWithoutUndo()。反復要素 Prefab は AssetDatabase.LoadAssetAtPath<GameObject>(path) で読んで配線。PrefabUtility.LoadPrefabContents / SaveAsPrefabAsset / UnloadPrefabContents で開閉。Object は曖昧参照になるため UnityEngine.Object.DestroyImmediate と明示する。FindProperty はコンパイル済みアセンブリのフィールドを引く。C# のフィールドを追加・改名したら 先に uloop-compile してから配線 dynamic code を流す (未コンパイルだと FindProperty が null → NRE)。CanvasGroup コンポーネントを付けて配線する (Image 単体に頼らない)。アニメーションの実装自体はスクリプト側で LitMotionExtensions.cs の既存拡張を使う (上「鉄則」)。uloop-compile (ForceRecompile) → uloop-get-logs (Error) で 0 件。uloop clear-console して再コンパイルし、構築途中の一過性エラー (SerializedObjectNotCreatableException 等) が残っていないか確認。./unity-coding-standards/scripts/run-format.sh を実行し警告全文を確認 (warning|error|IDE[0-9]|VUA[0-9]|Unable to fix)。[LiminalScenario] で検証する (無ければ書き足す。検証はシナリオ化して回帰コーパスを育てる → liminal-palette-guide skill)。uloop-run-tests --test-mode PlayMode。uloop-execute-dynamic-code で View の MonoBehaviour を直接見つけ、ダミーデータで Show(...) 等を駆動して目視できる状態を作る。Presenter はピュア C# なので FindFirstObjectByType では拾えない (View を直接叩く)。既にコード生成で組まれた View を直す場合も設計判断は同じ。追加で:
grep -nE "m_Name:" <prefab> で掴み、動的生成メソッド (Build... / Create... / Ensure...) を洗い出す。SaveAsPrefabAsset(child.gameObject, newPath) の後に DestroyImmediate で View 内から除去してから配線する。*SDF.asset) がエディタ由来で差分に出ることがある。作業と無関係なら git checkout で破棄しコミットに含めない (不整合な multi-atlas SDF は TMP のクラッシュ源になり得るノイズ)。