Xenoneqq
UserClaude Code skills for making games in Unity, from writing code to working in the editor.
Categories
Indexed Skills (20)
unity-agent-worker
Carry one Unity task end to end in the user's own checkout: read the project's rules first, work in verifiable milestones, do all engine work through `unity-scene-habits` (prefab-first, editor CLI, never hand-edit YAML), send editor-backed runs to the shared editor agent, keep every new asset paired with its `.meta`, verify before every commit, and never push or switch branches. Use when handed a single Unity task to implement — by a user, or as a worker spawned by `unity-manage-work`.
unity-coding-habits
Good Unity C# habits that hold in any project: serialize private fields instead of exposing public ones, keep lookups out of per-frame code, treat destroyed `UnityEngine.Object`s as the fake null they are, pick one way to find things instead of mixing singletons and scene searches, keep types small and namespaced, and never restyle code you are only passing through. Use when writing or changing a `MonoBehaviour`, `ScriptableObject` or any C# under `Assets/`, including tests; "is this MonoBehaviour right", "clean up this component", "how should I write this component", "how do I test this", "write a PlayMode test", "/unity-coding-habits". Reviewing a change is `unity-review-change`; diagnosing a game that already runs badly is `unity-debug-runtime`.
unity-debug-runtime
Work out why a Unity game is running wrong — it crashes, it throws, a reference is null in play mode but looks fine in the inspector, it stutters, the frame rate sags — on a project with no automated tests to tell you. Evidence before theories: reproduce it on demand, read the right log, read the stack trace properly, narrow it, confirm the fix killed it. Use when: "why does my game crash", "NullReferenceException", "MissingReferenceException", "the referenced script on this Behaviour is missing", "my reference is null at runtime", "the game is stuttering", "frame rate drops after a while", "GC spike", "it works in the editor but not in the build", "where is the Unity log", "how do I profile this", "when did this break", or "/unity-debug-runtime".
unity-file-structure-habits
Decide where a new file or asset goes in a Unity project, and keep the layout from drifting: read STRUCTURE.md as the authority, follow what the project already does over any default, move assets only through the editor so references survive, add a category rather than dumping a file in the nearest folder, and update STRUCTURE.md when the tree gains something new. Use when: creating a script, prefab, material or any asset; "where should this go", "where do I put this", "the project structure is a mess", "/unity-file-structure-habits"; or reviewing a change that adds files.
unity-legacy-migration
Move old Unity code and assets onto a project's current conventions deliberately, without breaking a reference: decide whether the migration is worth doing at all, rename and move through `AssetDatabase` so GUIDs survive, carry serialized values across a field rename, add a namespace without losing anything, split a god-object component safely, and land each step as its own commit with no behaviour change mixed in. Use when: "modernise this old script", "bring this up to our conventions", "rename this class everywhere", "put these scripts in a namespace", "split this god object", "this component predates our layout", "migrate the legacy folder", "/unity-legacy-migration".
unity-level-design
Design and build game levels in Unity that play well and look lived-in rather than generated: measure the player's real metrics first, give the level a job and a beat structure, offer a top-down HTML paper map when it would help, block it out in greybox as prefabs, prove the critical path is reachable, then dress it with deliberate irregularity instead of perfect grids and uniform spacing. Use when: designing, blocking out, greyboxing or dressing a level, map, arena, room, dungeon or encounter space; "make a level", "build a test map", "block out this area", "the level feels empty", "this looks too clean", "place props around", "set dress this", "/unity-level-design".
unity-manage-work
Run a Unity task or backlog end to end as a MANAGER: settle the base branch with the user, cut one branch, plan the order from a scene-and-prefab conflict map, delegate implementation to worker subagents that follow `unity-agent-worker`, route all editor-backed work through one shared editor agent, review what comes back, and close with a report and a draft PR file per task. Work happens in the user's own checkout — no worktree per worker — so writers run one at a time. You never write game code yourself. Nothing is ever pushed. Use when: "/unity-manage-work", "manage this Unity work", "here is a list of Unity tasks, get them done", "delegate these to agents", or the user hands over Unity work and wants it delivered, not investigated.
unity-multiplayer-habits
Build multiplayer correctly in a Unity project using Mirror: let the server own game state and the client own its own movement, pick the right direction for every remote call, re-validate anything a client sends, register spawnable prefabs so they actually appear, branch on the right identity flag, and never call it done without two clients agreeing. Settles which networking framework a project uses before any networked code exists. Use when: adding or changing networked behaviour, "sync this across clients", "why does this only work for the host", "it works in the editor but the other player sees nothing", "my prefab doesn't spawn for clients", `[Command]`, `[ClientRpc]`, `[SyncVar]`, `NetworkBehaviour`, Mirror, "test with two clients", or "/unity-multiplayer-habits".
unity-pixel-art
Generate pixel-art textures, sprites, sprite sheets and icons for a Unity project from code instead of drawing them: a fixed palette, a small drawing canvas, seeded noise, tileable textures that wrap without seams, pose-based character frames, and import settings that keep every pixel sharp. The generator is a committed editor builder with a fixed seed, so "make it darker" is a code change and a rerun. Use when: "make a dirt texture", "create a repeating ground texture", "generate a sprite", "make a walk cycle", "draw an ammo icon", "we have no art", "placeholder art that looks decent", "pixel art", "tileable texture", "my pixel textures look blurry", "/unity-pixel-art".
unity-review-change
Review a change to a Unity project — a working tree, a branch or a pull request — read-only, with the triage a general code reviewer cannot do: an asset committed without its `.meta`, a scene that had no business changing, a scene the editor re-serialized, project-wide settings nobody asked for, a renamed serialized field that silently drops every stored value. Reports tagged findings and a SHIP or FIX-FIRST verdict; it never edits, stages, commits or pushes. Use when: "review this change", "review this diff", "is this PR ok", "check this branch before I merge", "look over these changes", "review my Unity code", "/unity-review-change", or as the review step inside `unity-manage-work`.
unity-scene-habits
Prefab-first habits for working in a Unity project through the editor CLI: turn anything groupable into a prefab, make changes as prefab-asset edits instead of scene edits, keep the scene out of the diff unless the task genuinely needs it, never break an asset reference, and say so at the end when another branch already edits the same scene. Use when the work touches a scene, a prefab, an asset or the editor itself: "add this to the scene", "make this a prefab", "why does my scene keep conflicting", "run Unity headless", "-executeMethod", "/unity-scene-habits", or any change that would touch a `.unity`, `.prefab` or `.meta` file.
unity-skill-package-setup
Wire a Unity project up to these skills: install the plugin at project scope, write a CLAUDE.md and AGENTS.md that route each kind of work to the right skill and make every handed-over task offer to run through `unity-manage-work`, check the repo's .gitignore and scene merge setup, install the Unity CLI's Pipeline package so skills can drive a running editor, offer ProBuilder for a 3D game, scan what is already there, generate a STRUCTURE.md describing the real project layout, and scaffold the standard asset folders. Use when: "/unity-skill-package-setup", "set this project up for Claude", "link these skills to my Unity project", "add a CLAUDE.md for this Unity project", "scaffold the asset folders", or opening a Unity project that has no CLAUDE.md.
unity-ui-design
Design and build game UI in Unity that belongs to this game, not to a template or to its genre's clichés: ground the look in the game's art and fiction, plan a small token system, check it against the usual tells, prove it in an HTML mockup the developer approves, then build it in the toolkit the project already uses and capture it at several aspect ratios. Use when: designing or restyling a HUD, main menu, pause menu, inventory, shop, dialogue box or any in-game screen; "design the UI", "make the menus look better", "our HUD looks generic", "mock up the inventory", "restyle this screen", "/unity-ui-design".
agent-worker
Work a coding task end to end in a repo — learn the project's own rules first, branch (or an isolated worktree when asked) and ask before touching a non-main branch, build in milestones, run the project's gate after every chunk, prove each finished milestone actually runs, commit in plain language, never push and never merge. Use when the user hands over a task to implement, fix, or refactor in a repo ("work on this", "implement this", "fix this", "build this feature", "take this ticket"), or invokes /agent-worker.
draft-issue
Draft a copy-paste issue — bug, feature or patch — following the repo's own issue template and contributing rules where it has them, and a short plain-prose default style (`## Problem` first) where it doesn't. Use when the user says "draft issue", "/draft-issue", "write a bug report", "make an issue for this", or hands over a bug/feature to turn into a tracker entry. Never files the issue — output only.
draft-pr
Draft a copy-paste PR description (title + body) for the current change, a diff, or an issue link — following the repo's own template and conventions where it has them, and a plain-language default style where it doesn't. Use when the user says "draft pr", "/draft-pr", "write a PR description", or hands over a change/link to turn into a PR. Never touches a git remote — output only.
humanify-docs
Write Markdown docs that read like a person wrote them, or rewrite AI-generated docs so they do — short sections, lists and tables where they help, minimal formatting, no code unless the doc is genuinely technical. For a broad topic (a codebase overview, how a system works end-to-end) it researches with a small, budgeted set of subagents and writes the doc itself. Updating an existing doc keeps its style by default and only adds what was asked. Use when: "humanify this doc", "/humanify-docs", "make this README readable", "write docs for X", "this doc reads like AI, fix it", "document how Y works", "add X to the docs", "update the docs for Y", "write a README for this project", or the user hands over a Markdown file and wants it human-friendly. Every rule here yields to what the user asks for.
humanify
Turn any text into what a person would actually write and want to read: short, simple and plain. Works on text you hand over, or on something you ask for in the same prompt, such as "write a summary of my changes and humanify it". Covers review comments, PR descriptions, messages, issue text, commit bodies, summaries of changes or findings, and anything else short. Not for docs; humanify-docs covers those. Use when: "humanify", "/humanify", "humanify this", "and humanify it", "make it readable", "make this shorter", "keep it simple", "too long", "make it brief", "draft a comment", "draft a message", "write it like a human", or the user hands over text that reads like AI. Every rule here yields to what the user asks for.
investigate
Investigate a bug OR a feature with up to four independent research agents, then synthesize their reports into recommended next steps. For bugs: find the root cause and a minimal clean fix. For features: find where and how to implement it and the possible approaches with trade-offs. Investigation only — no code changes until the user approves. Use when: "investigate this", "look into X", "how would I build/add Y", "where does Z live", "/investigate", a Linear/GitHub issue link with a request to research, or "spin up agents to find a fix / an approach".
manage-work
Orchestrate a list of tasks/issues end-to-end as a MANAGER: pick the base branch with the user, plan the work, split it into tasks, delegate every task to a worker subagent that follows the `agent-worker` skill (parallel when independent, sequential when they conflict), review what comes back, and close with a session report + a draft PR written to disk per task. A single task, or a strictly sequential one, is managed the same way with one worker. You never write feature code yourself. Workers run in isolated git worktrees, one branch per task, commit rarely. NOTHING is ever pushed — not by workers, not by the manager. Max 4 workers at once. Workers cannot spawn subagents. Use when: "/manage-work", "manage this work", "here is a list of tasks, get them done", "orchestrate these issues", "delegate these to agents", or the user hands over a multi-task backlog (with or without a list of steps to follow) and wants it delivered, not investigated.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.