Claude Skills for Unity: Development Review Templates

Claude skills for Unity are saved instruction sets you activate before reviewing a scene, a component script or a set of play-mode results. Each skill focuses the session on a specific part of the development process: checking that a scene change fits the project's design rules, reviewing a new component for correctness and edge cases, or analyzing play-mode output for unexpected behavior. Tools like fenbs preserve the approved design decisions and the current development plan between sessions, so every review can check the work against the intent behind it.

Unity development involves many interdependent systems: scene hierarchy, component references, physics, rendering, input and build settings. A change that looks correct in isolation can break something elsewhere. A structured review skill helps catch those problems before they compound. The Unity Scripting API reference↗ (opens in a new tab) and Manual↗ (opens in a new tab) are useful primary sources when a review needs to check a specific class or Unity behavior.

What makes a Unity review skill useful

A useful skill for Unity reviews is specific to the type of change being reviewed. Scene hierarchy changes raise different questions than component script changes, which raise different questions than a play-mode performance review. One skill per review type keeps each session focused and produces answers that address the actual concern rather than covering everything at once.

The skill should reflect your project's conventions, not just general Unity best practices. If your project uses a specific component pattern for handling input, the review skill should check against that pattern. If your naming convention for scene objects follows a particular structure, the skill should include that check. Generic skills produce generic feedback; project-specific skills produce actionable corrections.

When writing a Unity review skill, start by listing the feedback that comes up in every team code review or QA session. If null references in MonoBehaviour Awake methods appear every sprint, that check belongs in the skill. If the team consistently forgets to rebuild baked lighting after scene changes, add that check too. Build the skill from the actual history of the project rather than from a general Unity best practices guide, and it will catch the problems you have actually encountered rather than hypothetical ones.

See claude skills examples for patterns across other development contexts. The claude skills marketplace and claude skills files explain how to store and share skills once they are written.

Skill 1: reviewing a scene change

Use this skill when you or a teammate adds, removes or restructures objects in a Unity scene. It checks the hierarchy, component assignments, prefab integrity and whether the change is consistent with the project's scene organization conventions.

Review the Unity scene change I describe below.

Check:
1. Hierarchy: whether the new or modified objects follow the project's naming and nesting conventions.
2. Component assignments: whether required components are attached, references are set, and no obvious references are null.
3. Prefab integrity: if the change involves a prefab, whether the prefab instance is consistent with its definition or if an intentional override is needed.
4. Dependencies: whether the change affects lighting, occlusion, navmesh or other baked systems that need to be rebuilt.
5. Conventions: whether the change follows the agreed structure for this scene type.

For each issue, name the object, describe the problem, and say what to fix.

Describe the change in plain terms or paste a diff of the scene file. If you paste the scene YAML, keep it to the affected objects rather than the full file. Focus the review on the change itself rather than asking Claude to audit the entire scene.

Skill 2: reviewing a new component

Use this skill when adding a new MonoBehaviour or reviewing a significant change to an existing one. It checks the script for correctness, Unity lifecycle usage, null reference risks and adherence to the project's scripting conventions.

Review the Unity component script I paste below.

Check:
1. Lifecycle methods: whether Awake, Start, Update and other Unity messages are used correctly and in the right order.
2. Null references: fields that are assigned in the Inspector or found at runtime, and whether the code handles the case where they are not set.
3. Performance: whether Update or FixedUpdate contains work that should run less frequently or be cached.
4. Coupling: whether the component has direct references to other components that could be decoupled through events or interfaces.
5. Project conventions: whether the naming, access modifiers and serialization attributes follow the project's scripting standard.

For each issue, give the line or method name, describe the problem, and suggest a correction.

Paste the full script rather than a snippet. Claude needs to see how the lifecycle methods, fields and references relate to each other to give a complete review. Add a brief note about what the component is supposed to do if that is not clear from the code.

Skill 3: reviewing play-mode results

Use this skill after a play-mode test to analyze unexpected behavior, performance readings or console output. Paste the console log, a description of what you observed, and any profiler data you want to include.

I will share Unity console output and a description of what I observed in play mode. Help me understand what went wrong and where to investigate.

For each warning or error:
1. Identify which GameObject or system it likely originates from.
2. Explain what the message means in plain terms.
3. Say whether it is a critical error, a likely source of incorrect behavior, or a low-priority warning.
4. Suggest where in the code or scene to start investigating.

For unexpected behavior I describe:
1. List the most likely causes based on the description.
2. Describe a simple test that would confirm or rule out each cause.

The more specific the console output and behavior description, the more useful the review. Include the exact error message text rather than paraphrasing it. If the behavior is intermittent, note what seems to trigger it.

How to do this with fenbs

Pair these review skills with a record of the project's design decisions so reviews check the work against what the team agreed, not just against general Unity conventions.

1. Create a free account and add a project for your Unity game or application.
2. Add the current development milestone as a task with a description of what is in scope. Link specific scene or system tasks to it.
3. Save the review skills in fenbs Skills and prompts with names that make the scope clear: "Scene hierarchy review," "Component script review," "Play-mode results review."
4. Record design decisions in Decisions and rules: the agreed scene structure, naming conventions, scripting patterns and performance budgets. These become the standard every review checks against.
5. After a bug that a review should have caught, add a lesson. Update the relevant skill to include the check that was missing.

When a one-off prompt is better

A skill is worth saving when the same type of review will come up again. A solo project with a single developer who rarely revisits the same system may not need a shared skill library. A team working on a long-running project with multiple contributors benefits significantly from consistent review language. See claude projects vs skills vs artifacts for help deciding which format fits your situation.

Skills for Unity work also pay off on projects with long development cycles or team turnover. When a developer returns to a system after several months, the review skill surfaces the conventions they may have forgotten. When a new team member joins, the skill reflects the project standard from their first session rather than requiring months of accumulated feedback to convey the same information. The skill preserves the project-specific knowledge that would otherwise live only in the memory of the longest-serving team members.

A well-maintained skill also makes it easier to bring a different AI app into the same project without losing consistency. If the team tries a new coding assistant for a sprint, the skill ensures the review applies the same checklist regardless of which AI tool or session ran the previous one. That consistency matters more as the project grows and more systems are touched across more sessions.