The old draft should be rewritten because it framed the Unity Claude Template as a speed trick. The stronger claim is operational: this repository is an agent workbench for Unity.

A normal Unity starter gives you folders, packages, and maybe a sample scene. This one gives Claude Code a way to set itself up, talk to Unity through an MCP bridge, create assets, decompose game ideas into assembly-scoped tasks, run bridge or editor checks, and obey rules that protect Unity from common agent mistakes.

That is directly relevant to Codex and Claude Code practitioners. Unity is a hostile surface for naive agents: .meta files carry GUIDs, ProjectSettings can create merge pain, Domain Reload can stall work, and scene or prefab edits need editor context. The template is interesting because it treats those as first-class constraints.

The core idea is a workbench, not a starter

The README says the repo is an empty foundation for a Unity game with Claude, and that the plumbing is pre-wired so an AI agent can assemble scenes, write scripts, and create prefabs. That sounds like a beginner template, but the deeper asset is the operating contract around Claude Code.

CLAUDE.md tells the agent that Assets/Scripts/ starts empty by design, that the default assemblies are Project.Core, Project.UI, Project.Combat, and Project.Rendering, and that those assemblies can be reshaped for the user's game. That gives the agent a legitimate place to add code without pretending the skeleton is missing work.

The setup path is narrow on purpose

The project-level .mcp.json starts claude-bridge through uv run --directory scripts/claude-bridge-mcp claude-bridge-mcp. The /setup skill then checks uv, verifies .mcp.json, calls unity_bridge_status, and reports what remains. The README's promise is that the user types /setup and approves only the uv install step if needed.

That is a good shape for non-programmer Unity users, but it also helps experienced teams. Setup becomes a visible checklist instead of an oral tradition: bridge config exists, the expected Unity editor is detectable, and Claude Code is looking at the correct project root.

ClaudeBridge is the serious part

The bridge is file-based. Claude drops commands into .claude-bridge/inbox, Unity processes them, and results appear in .claude-bridge/outbox. In GUI mode, ClaudeBridgeServer.cs polls every 0.2 seconds on EditorApplication.update and handles one command per tick. In headless mode, /run bridge calls scripts/bridge-run.sh, which runs Unity with an executeMethod entry point.

The op list is practical: scene create/open/save, GameObject operations, component add/set/get, RectTransform edits, prefab open/save/variant/instantiate, asset refresh, SVG-to-sprite import, and a Reflection.Invoke escape hatch. That is the bridge between text agents and Unity state. A filesystem-only agent can write C#; this bridge can ask Unity to assemble and verify editor objects.

Use the skills as process boundaries

The skill set is not decoration. /task-start forces scope before files are opened. /design turns a game idea into design/{slug}/ steps where each step names the assembly area, files, symbols, dependencies, constraints, and completion checks. /make-asset gives the agent a controlled way to create UGUI prefabs, particles, primitive placeholders, and SVG icons. /debug routes the agent through source tracing and Bridge reads instead of asking the user to poke at the inspector. /qa requires criteria-backed pass/fail reports.

That process is why this template belongs in the Codex ecosystem. The value is not one prompt that says "make my game." The value is a repeatable operating loop: brief, implement inside scope, inspect Unity through the bridge, verify, then record what changed.

Run it as a disposable branch first

I would not drop this into a production Unity repo on day one. Start with the template itself or a throwaway fork:

cd ~/Documents/my-game
claude
/setup please
/run editor

After the editor and bridge respond, run one harmless bridge path. Create a blank scene, add a Canvas, add a UI object, save it, and inspect the result in git. Then run the cleanup path. The acceptance check is not whether Claude can produce an impressive scene. The check is whether it respects the repository's rules while doing small Unity operations.

The guardrails are the adoption case

RULES.md is blunt about the failure modes. Do not add new [InitializeOnLoad] attributes. Do not change asmdef autoReferenced to true. Do not write new files into symlink folders such as shared Art, Prefabs, Materials, Textures, Plugins, Resources, ProjectSettings, or Packages. Do not hand-edit .meta files. Do not call physics APIs outside FixedUpdate. Do not write async methods without CancellationToken. Do not let agents edit ProjectSettings.

Those are not style preferences. They protect Unity editor uptime, GUID integrity, merge safety, runtime determinism, and cancellation on Play Mode exit. A team adopting this template should copy the spirit of those rules before copying any game code.

The Unity rules and the bridge have tension

There is one important nuance: the bridge itself uses an existing [InitializeOnLoad] server so the editor polling server can auto-start. The root rules forbid adding new InitializeOnLoad attributes, not running the template's own bridge. That distinction matters.

If your team ports this workbench into another Unity repo, freeze the bridge as infrastructure. Feature agents should not add more editor auto-load hooks. They should use the bridge ops already present, or propose a new bridge op as an explicit infrastructure change.

Map it to a Codex-style workflow

A Codex-style use of this repo should not depend on magic. Treat each Unity task as a bounded job with source evidence and a verification command.

1. Run /task-start and name the assembly and files in scope.
2. Read .claude/INDEX.md, RULES.md, and only the matching skill or rule files.
3. Make code or asset changes inside the declared scope.
4. Use /run bridge or /run editor only when Unity state must be checked.
5. Run /task-done with changed files, rule checks, and any domain knowledge proposal.

That is exactly the pattern missing from shallow Unity AI demos. The agent has permission to act, but it also has named gates where a reviewer can see what it loaded, what it touched, and what it refused to touch.

Where the template is weak

The template is opinionated. It assumes Claude Code, Unity 2022.3 LTS, uv, its custom bridge, the Project.* namespace root, and an assembly layout that may not match your studio. The README is beginner-friendly and Korean-first, with an English version, so teams with strict internal docs will need their own onboarding layer.

The bridge also changes the risk profile. Once an agent can create prefabs, import sprites, and run editor commands, normal code-review habits are not enough. Review .meta churn, asset paths, scene changes, prefab diffs, and ProjectSettings separately. Do not treat bridge output as less risky than hand edits.

A rollout I would accept

Week one should be a workbench trial, not a game sprint. Fork the template. Run /setup. Ask /design to split a tiny game idea into two or three assembly-scoped steps. Let Claude implement only the first _Core step, then run /task-done. Next, let it create one icon or UI prefab through /make-asset. Finally, run /qa against a specific criterion such as no ProjectSettings changes, no .meta direct edits, and no autoReferenced: true in asmdefs.

If that works, move one workflow into your real repo: design decomposition, bridge-based prefab assembly, or criteria-backed QA. Do not migrate all skills at once. The safe adoption path is one workflow, one branch, one rule set, and one reviewer who understands Unity asset diffs.

Save Unity Claude Template as a Claude Code operating layer for Unity work. It is valuable when teams want agents to operate through explicit skills, bridge ops, and Unity-specific guardrails; it is risky when copied into a mature project without testing the bridge and asset rules first.

Practical takeaway

Try the template on a disposable fork before adopting it. Run /setup, verify unity_bridge_status, generate one design/{slug}/ plan, make one scoped _Core code change, create one harmless UI or icon asset through /make-asset, and finish with /qa checks for ProjectSettings, .meta, asmdef autoReferenced, and symlink-folder changes. Only after that trial should you port a single workflow or rule set into a production Unity repo.