Unity Code Gen

Unity コード生成

本番対応の Unity C# コードを生成します。既存のプロジェクトを分析し、適切なパターンを選択して、コードとテストを生成します。

このスキルでできること

1. リクエストを分析します（機能、システム、コンポーネントの種類）
2. 既存のコードベースを調査します（規約、名前空間、アセンブリ定義）
3. 判断ツリーを使ってアーキテクチャパターンを選択します
4. 適切な Unity 属性を使って、読みやすい C# コードを生成します
5. 対応する単体テストを生成します（NUnit）
6. ファイルを適切なディレクトリに配置します

前提条件

• 識別可能なフォルダー構造を持つ既存の Unity プロジェクト
• Claude Code ツール（Read、Write、Edit、Grep、Glob）を使ってプロジェクトファイルにアクセスできること
• MCP Unity の依存関係は不要です

クイックスタート

1. ユーザーが必要な機能またはコンポーネントを説明します
2. Glob/Grep でプロジェクトを調査し、規約を把握します
3. 判断ツリーを適用してパターンを選択します
4. 適切なディレクトリにコードとテストを生成します

判断ツリー

La chose a creer...
│
├─ Stocke des donnees configurables (stats, settings) ?
│  └─ OUI → ScriptableObject Data Container
│
├─ Sert de canal de communication entre systemes ?
│  └─ OUI → ScriptableObject Event Channel
│
├─ Vit sur un GameObject dans la scene ?
│  ├─ Controle du comportement runtime ? → MonoBehaviour
│  └─ Juste un data holder sur un GO ? → MonoBehaviour simple (struct-like)
│
├─ Definit un contrat que plusieurs classes implementent ?
│  └─ OUI → Interface (+ implementations MonoBehaviour ou pure C#)
│
├─ Logique pure sans dependance Unity (math, algo, parsing) ?
│  └─ OUI → Pure C# class (pas de MonoBehaviour)
│
├─ Utilitaire stateless reutilisable ?
│  └─ OUI → Static class ou extension methods
│
├─ Gestion d'etats discrets (joueur, IA, game flow) ?
│  └─ OUI → State Machine (enum + switch ou state classes)
│
├─ Gestion d'inputs avec undo/replay ?
│  └─ OUI → Command Pattern
│
├─ Objets crees/detruits frequemment (projectiles, VFX) ?
│  └─ OUI → Object Pool
│
├─ Logique asynchrone (chargement, timer, sequence) ?
│  └─ OUI → Async Awaitable Component (Unity 6+)
│
└─ Milliers d'entites similaires a traiter en parallele ?
   └─ OUI → ECS (DOTS) — hors scope de cette skill

手順ガイド

手順 1 — リクエストを分析する

以下を明確にします：

• 何を：機能、システム、コンポーネント、データコンテナ、イベントのどれか
• どこに：プロジェクトのどのモジュールか。どのアセンブリ定義か
• 連携：既存のどのシステムと連携するか
• データ：どのデータを操作、永続化、シリアライズするか

手順 2 — 既存のコードベースを調査する

コードを一行でも書く前に、必ず次の検索を実行します：

Glob("Assets/**/*.asmdef")              → assembly definitions, structure modules
Glob("Assets/**/*.cs", limit aux dossiers cibles) → fichiers existants
Grep("namespace ", type: "cs")           → conventions de namespace
Grep("class .* : MonoBehaviour", type: "cs") → MonoBehaviours existants
Grep("class .* : ScriptableObject", type: "cs") → SOs existants
Grep("\\[SerializeField\\]", fichier cible)  → style de serialisation

以下を確認します：

• 命名パターン（private フィールドに _camelCase を使うか。プレフィックスはあるか）
• 名前空間の構造（Game.Core、Game.Player など）
• 属性の規約（[Header]、[Tooltip]、[Range]）
• 既に使われているパターン（イベント、インターフェース、ステートマシン）

手順 3 — パターンを選択する

上記の判断ツリーを適用します。迷った場合は、コンポジションとシンプルなパターンを優先します。

手順 4 — C# コードを生成する

次の Unity 規約を必ず適用します：

必須属性：

• Inspector で編集するフィールドには [SerializeField] private を使います（public は使用しません）
• スクリプトが別のコンポーネントに依存する場合は [RequireComponent(typeof(X))] を使います
• Inspector を論理的なグループに整理するには [Header("Section")] を使います
• わかりにくいフィールドには [Tooltip("説明")] を付けます
• 範囲が定められた数値には [Range(min, max)] を使います

ファイルの構成：

// 1. Namespace
// 2. Attributs de classe ([RequireComponent], [DisallowMultipleComponent])
// 3. Declaration de classe
// 4. Constantes
// 5. [SerializeField] champs groupes par [Header]
// 6. Events publics
// 7. Proprietes publiques (read-only si possible)
// 8. Champs prives
// 9. Awake / OnEnable / Start
// 10. OnDisable / OnDestroy
// 11. Update / FixedUpdate (si necessaire)
// 12. Methodes publiques
// 13. Methodes privees
// 14. Coroutines

名前空間： 既存の構造に合わせます。プロジェクトで Game.Player を使っている場合は、MyNamespace.Scripts を新たに作成しないでください。

手順 5 — テストを生成する

生成した各ファイルに対応するテストを作成します：

• EditMode テスト：純粋なロジック、計算、ステートマシン、データ検証
• PlayMode テスト：MonoBehaviour の動作、コンポーネント間の連携、コルーチン

テストの配置：

Assets/Tests/EditMode/  → tests logique (assembly ref: Game.Core, etc.)
Assets/Tests/PlayMode/  → tests comportement (assembly ref + UnityEngine.TestRunner)

手順 6 — ファイルを配置する

• アセンブリ定義と既存のフォルダー構造に従います
• テストは対応する Tests/ フォルダーに配置します
• 出力内容：C# ソースファイル、NUnit テスト、概要（選択したパターン、作成したファイル）

厳格なルール

必ず：

• 生成する前に既存のコードベースを確認する（Glob + Grep）
• プロジェクトの命名規則に合わせる
• コードと同時にテストを生成する
• Inspector のフィールドには [SerializeField] private を使用する
• プロジェクトの構造に合った一貫性のある名前空間を使用する
• Inspector で読みやすくするため、[Header] と [Tooltip] を追加する
• 継承よりもコンポジションを優先する
• OnDisable または OnDestroy でイベントの登録を解除する

決して：

• 既存のプロジェクトを確認せずにコーディングしない
• MonoBehaviour の Singleton パターンを使用しない（SO または Service Locator を優先する）
• public フィールドを使用しない（[SerializeField] private とプロパティを使用する）
• 文字列を指定して Find*() や SendMessage() を使用しない
• 参照をキャッシュせずに Update() にロジックを記述しない
• テストなしでコードを生成しない
• 500 行を超えるファイルを作成しない（モジュール化する）
• マジックナンバーをハードコードしない（SO または const を使用する）

---

関連スキル

• アーキテクチャなしで素早くプロトタイプを作成する場合は、/proto（Unity Rapid Proto）を使用する
• 既存のコードをリファクタリングする場合は、/unity-refactor（Unity Refactor）を使用する
• 生成したコンポーネントのカスタムインスペクターを作成する場合は、/unity-editor-tools（Unity Editor Tools）を使用する
• NUnit テストを生成して実行する場合は、/unity-test（Unity Test）を使用する
• オーディオシステムを生成する場合は、/unity-audio（Unity Audio）を使用する
• セーブ機能を実装する場合は、/unity-save（Unity Save System）を使用する

トラブルシューティング

問題	解決策
プロジェクトに明確な規約がない	Unity の標準規約（_camelCase、PascalCase）を使用し、一貫したパターンを作成する
既存の Assembly Definition がない	メインフォルダーにコードを生成し、プロジェクトが大きくなったら asmdef の作成を提案する
名前空間が何にも対応していない	プロジェクト名とモジュール名を使用する。例：ProjectName.Module
すべてが密結合していてテストできない	ロジックをテスト可能な純粋な C# クラスに切り出し、MonoBehaviour は「接着剤」として維持する
プロジェクト内で Singleton が多用されている	新たに追加せず、SO／Service Locator への段階的な移行を提案する
サードパーティーパッケージと名前が競合する	名前空間にプロジェクト名をプレフィックスとして付ける

詳細なコードテンプレートについては、references/code-templates.md を参照してください。