Unity Shipped 29 Skills for Claude Code and 31 for Codex: Why Domain Skill Packs Beat Generic Agents

Unity did something every agent platform builder should notice. Rather than waiting for the community to accumulate forum posts, it shipped official first-party plugins written by its own engineers. Per published coverage, the Claude Code plugin landed on September 10 with 29 built-in skills, and the OpenAI Codex plugin followed on September 16 with 31, both targeting Unity 6 and later and both maintained by Unity's engineering teams. The line that captures the intent is blunt: stop letting AI coding agents learn game development from forum posts about engine versions nobody uses anymore. Reported coverage of the skills spans UI Toolkit, uGUI, 2D and Tilemap, URP and Shader Graph, audio, navigation, physics, IAP, LevelPlay, multiplayer, web, and localization.

1. What Shipped: The Shape of an Official Skill Pack

Per Inven Global, BigGo, and MIXED Reality News, the defining trait is that it is first-party: the plugins are built and maintained by Unity engineers rather than by a third-party community effort. The engineering difference shows up in the ordering of operations. The agent inspects project structure and status before starting, applies the latest APIs, and delivers results only after passing internal verification. The Codex plugin carries 31 game-development skills covering UI Toolkit, uGUI, 2D, Tilemap, URP, Shader Graph, audio, navigation, physics, IAP, LevelPlay, multiplayer, web, and localization, while the Claude Code plugin arrived first with 29. Notably, per MIXED Reality News, the skills focus on the engine itself and none of them are XR.

# A skill pack is a repository, not a prompt. Lay it out like one.
skills/
  unity-ui-toolkit/
    SKILL.md              # when to use it, what it guarantees
    scripts/validate_ui.py  # deterministic actions the agent calls
    references/uxml.md      # deep docs, loaded only when needed
  unity-urp-render/
    SKILL.md
    scripts/inspect_pipeline.py

Stop letting agents learn APIs from stale forum posts

2. Why Skills Beat Context Stuffing

A general coding agent's knowledge comes from training data, and engine documentation inside that data is often stale; forum posts may describe APIs several versions old. Inject that into context and the agent confidently writes patterns that were deprecated long ago. A skill pack addresses knowledge freshness by turning the currently correct way into a resource the agent loads on demand, maintained by someone whose job is to keep it right. It also addresses action reliability: a skill is not just documentation but a set of deterministic scripts the agent calls rather than improvises. Documentation answers what is true; scripts answer do it correctly. A skill needs both.

---
name: unity-ui-toolkit
description: Build and refactor UI Toolkit and uGUI interfaces for Unity 6+
when_to_use: The task mentions UI Toolkit, UXML, USS, or uGUI canvases.
verify: scripts/validate_ui.py must exit 0 before you report success.
---
# UI Toolkit

1. Read references/uxml.md before editing any .uxml file.
2. Prefer live in-engine APIs; never invent component names.
3. After edits, run scripts/validate_ui.py and paste its output.

Deep reference material lives in references/ and is loaded on demand,
so the skill stays small until the task actually needs the detail.

3. Anatomy of a Good Skill: Three Layers

The first layer is when to use it: a short statement in SKILL.md naming the trigger, such as when a task mentions UI Toolkit, UXML, USS, or uGUI canvases. The second is how to do it: a set of deterministic actions, usually exposed as scripts with structured inputs and outputs, so the agent calls a tool instead of improvising a command. The third is the deep water: detailed reference material in a references directory, loaded only when the task actually needs it, which keeps the skill light the rest of the time. The three layers carry one implicit requirement too, which is that every skill must end in a verifiable check. Without verification, it looks right survives all the way to production.

// Give the agent a typed contract, not a paragraph. Types can be checked;
// prose cannot. This is what makes a skill reusable across models.
import { z } from "zod";

export const InspectPipelineInput = z.object({
  projectPath: z.string(),
  pipeline: z.enum(["urp", "hdrp", "builtin"]),
});

export async function inspectPipeline(input: z.infer<typeof InspectPipelineInput>) {
  const args = InspectPipelineInput.parse(input);
  return runEditor("RenderPipelineInspector", args); // structured, verifiable
}

A skill pack is a repo, not a prompt

4. Writing Your Own: Contracts, Verification, Versions

Three investments matter most when you build your own pack. First, contracts: define typed inputs and outputs for a skill's actions, for instance a zod schema, so the agent can rely on types rather than guesses; a checkable contract travels across models better than a paragraph of prose. Second, verification: end each skill in a repeatable check, such as a validation script or the engine's own test run, so finished becomes an objective result rather than a judgment call. Third, versions: pin skill versions like dependencies and run the skill's own test suite in CI, because an unpinned skill is a silent behavior change the day someone edits the repository behind your back.

# Every skill must end in a verifiable check. 'It looks right' is not one.
set -euo pipefail

python skills/unity-ui-toolkit/scripts/validate_ui.py ./Project   # must exit 0
unity-editor -batchmode -projectPath ./Project -runTests          # engine tests
echo "skill verified: unity-ui-toolkit"

# Verification is what separates a skill pack from a well-written prompt.

5. In Practice: From Layout to Pinned Versions

The first snippet lays out a skill pack: SKILL.md, scripts, and references, each with a job. The second is a sample SKILL.md whose frontmatter declares the name, trigger, and verification requirement, while the body holds only the necessary steps and defers deep material to on-demand references. The third defines a typed schema for a skill action, making the contract checkable and portable across models. The fourth demonstrates the verifiable ending: run the validation script and the engine tests, and treat only a zero exit code as done. The fifth pins skill versions like dependencies and states the policy: review before bump, and run the suite in CI.

// Pin skills like dependencies. An unpinned skill is a silent behavior
// change the day someone edits the repository behind your back.
{
  "skills": {
    "unity-ui-toolkit": "1.2.0",
    "unity-urp-render": "1.0.3"
  },
  "policy": "review before bump; run the skill test suite in CI"
}

Every skill ends in a verifiable check

6. A Checklist: Treat Domain Knowledge as a Maintained Asset

Five checks. First, does the domain knowledge your agents rely on live in a maintained skill pack, or is it scattered across prompts and stale docs? Second, does each skill state when to use it? Third, do the actions have typed contracts rather than prose descriptions? Fourth, does every skill end in a verifiable check? Fifth, are skill versions pinned and tested in CI? The real lesson from Unity is not the numbers 29 and 31. It is the posture behind them. Rather than letting agents guess your APIs from old posts on the internet, have the people who know them best write them down, maintain them, and make them verifiable.