Game-Dev Agent Skills: Claude Code, Codex and Cursor Setup
Install awesome-gamedev-agent-skills at project scope, find the actual Claude Code, Codex and Cursor paths, and verify that the router reads the right skills. Understand the current 76-plus-router count, metadata versus loaded context, Godot and Unity smoke checks, and third-party skill review.
Contents
Install gamedev-skills/awesome-gamedev-agent-skills from your game project’s root with npx skills add gamedev-skills/awesome-gamedev-agent-skills, include router, and select your coding agent. Then invoke the router explicitly and verify one small Godot or Unity change before requesting a larger feature. Installing the full catalog does not put every skill body into context: agents discover metadata first and read selected instructions when needed.
As of 2026-10-26, the current repository contains 76 specialized skills plus a separate router, or 77 skill definitions in total. The repository’s About description still says 74; use the current files and installer preview when checking what you will receive. The pack is Apache-2.0 licensed.
This setup is useful when you already use a coding agent and want reusable engine-specific instructions. It supplies guidance for code and workflows; you still need your game editor, project, and a working coding-agent account or API configuration.
Install at project scope
Start with a project-local installation so you can inspect the added files alongside your game. The published skills CLI is 1.7.4 as of 2026-10-26 and requires Node.js 22.20.0 or later, according to its npm metadata. Have Git available for fetching the repository.
Open Bash in the game project’s root and preview the catalog:
node --version
git --version
npx skills add gamedev-skills/awesome-gamedev-agent-skills --listLook for router, godot-2d-movement, platformer, and unity-scriptableobjects. The --list option lists available skills without installing them. Read the router and the skills you intend to use before confirming installation.
Run the pack’s documented installation command:
npx skills add gamedev-skills/awesome-gamedev-agent-skillsIn the interactive choices, include the router and the full catalog for this walkthrough, select the agent you use, and choose Project scope. Add -g only when you deliberately want a user-wide installation across projects.
To explicitly select the full catalog for Codex, use this alternative:
npx skills add gamedev-skills/awesome-gamedev-agent-skills --skill '*' -a codexReplace codex with claude-code or cursor for those clients. Keep the quotes around '*' so Bash does not expand it. The CLI reference distinguishes --skill '*', which selects all skills, from --all, which also targets all agents.
Check the result:
npx skills listConfirm that router and the skills required by your chosen engine check appear. The installer retrieves public skill files; model authentication remains in your coding client, and running the agent still uses its normal model allowance or API billing.
Where do Claude Code, Codex and Cursor load the files?
Use the actual installation destination, because an agent’s supported directories and the CLI’s chosen directory are not always identical. For project installations with skills 1.7.4, the relevant mapping is:
| Agent | Value after -a | Project installation target | Explicit router invocation in chat |
|---|---|---|---|
| Claude Code | claude-code | .claude/skills/ | /router |
| Codex CLI or IDE extension | codex | .agents/skills/ | Select router through /skills or mention $router |
| Cursor Agent | cursor | .agents/skills/ | Type / and select router |
These invocations belong in the agent’s chat, not Bash. Cursor also supports .cursor/skills/ for manual installation, so the pack’s shorter installation page remains useful as a compatibility map; an empty .cursor/skills/ directory does not mean a CLI installation failed.
The current installer agent mapping assigns both Codex and Cursor to .agents/skills/. A single target directory receives copies. When you select clients with different target directories, the installer can share a canonical .agents/skills/ copy through symlinks, or create separate copies. Read its installation summary instead of assuming every installation creates links.
Each installed skill should have the shape <skills-directory>/<skill-name>/SKILL.md. For example, Codex’s movement skill is .agents/skills/godot-2d-movement/SKILL.md; Claude Code’s corresponding entry is .claude/skills/godot-2d-movement/SKILL.md. Keep the skill’s bundled references/, scripts/, and assets/ directories when present, as the manual installation instructions specify.
How does the router avoid loading every skill?
The router selects instructions by engine and task; the host agent supplies the underlying on-demand loading mechanism. The Agent Skills specification’s overview describes discovery through names and descriptions, activation through reading a skill body, and execution using additional resources when needed.
The pack’s router instructions apply that mechanism to game development:
- Identify one engine from the project and read its version.
- Select the smallest relevant engine, discipline, genre, and workflow skill set.
- Read those bodies and open bundled references only when the task needs them.
For Godot, the primary fingerprint is project.godot. For Unity, it is the combination of Assets/ and ProjectSettings/ProjectVersion.txt. A movement request can select godot-2d-movement and platformer; a later saving request should select the relevant persistence guidance instead of loading unrelated engine catalogs.
The router is itself a SKILL.md playbook followed by the model. It is not a separate executable that enforces a maximum number of reads. Installing just the router also does not provide the specialized instructions it references: those skills must be installed and discoverable.
Metadata still consumes context, and loaded instructions, tool results, and retries still consume usage. If your existing skill collection produces discovery-budget warnings, use --skill to install a smaller selection containing the router and the specialists your work needs. There is no measured token-saving percentage to assume from the skill count alone.
Verify one small engine task
Check both instruction loading and the resulting engine behavior. Start a fresh agent session in the game project, explicitly select the router using the table above, and use one of the following prompts.
Where your client exposes tool activity, confirm the actual skill activation or file reads. A sentence saying that a skill was loaded is weaker evidence than a successful read of its installed SKILL.md.
Godot: add one mid-air jump
Use an existing runnable Godot 4 scene with a CharacterBody2D player, a collision shape, and a floor. The router documents godot-2d-movement plus platformer for this request; the movement skill supplies the engine-specific controller guidance.
Use the installed router skill for this Godot project. Inspect project.godot
and the actual editor version before editing, and preserve that version.
Report the resolved paths of the router and selected SKILL.md files you
actually read. Resolve skill names through the installed skill locations.
Add one extra mid-air jump to the existing CharacterBody2D player.
Keep the change in the player controller and preserve the current controls.
A fresh jump press on the ground starts the first jump. One more fresh
press in the air starts the second. A third press before landing does
nothing. Holding the button must not repeatedly jump. Landing restores
both jumps.
List the changed files and give the exact scene and controls for checking
the result. Separate checks you ran from checks I must perform in Godot.Run the named scene. Two separate presses should produce two jumps, a third airborne press should produce no new jump, and landing should restore the sequence. Also hold the button through a jump to check that it does not repeatedly trigger, and check for new script or runtime errors.
The pack’s movement baseline is Godot 4.7, but the engine-detection instructions say to preserve an existing project’s version. Installing the pack is not a reason to migrate the project or substitute APIs from a different release.
Unity: separate shared data from runtime quantities
Use a disposable scene in an existing Unity project. This check exercises unity-scriptableobjects, with unity-csharp-scripting appropriate for the small consuming component. It tests the skill’s shared-data guidance without asking for a complete inventory system.
Use the installed router skill for this Unity project. Read
ProjectSettings/ProjectVersion.txt and preserve the editor and package
versions. Report the resolved SKILL.md paths you actually read.
Create an ItemDefinition ScriptableObject with itemId, displayName,
and maxStack, using CreateAssetMenu. Use one example asset with
itemId "potion", displayName "Potion", and maxStack 10. Treat the asset
as read-only configuration during play.
Create two distinct runtime slot instances referencing that same asset.
Start their quantities at 2 and 5. Add one small probe component that
decrements only the first slot, then reports quantities 1 and 5,
confirms both slots reference the same asset, and checks that the
definition fields are unchanged. Start each probe run with fresh slots.
Keep the output to the data model and probe component. Give exact
asset-creation, component-attachment, Inspector-assignment, and Play-mode
steps. Distinguish checks you executed from checks I must perform.Create the example asset through the generated Assets menu entry, attach the probe to an empty GameObject, assign the asset in the Inspector, and enter Play mode. The observable result should show separate quantities changing from 2 and 5 to 1 and 5 while both slots retain the same definition reference. After leaving Play mode, the asset should still contain potion, Potion, and 10.
Unity’s ScriptableObject documentation explains that consumers can share one asset by reference. The asset is not inherently immutable; this example deliberately keeps changing quantities in separate runtime objects. If both quantities change together, inspect whether the implementation accidentally shares the slot object as well as the definition.
What if the router or selected skill cannot be found?
Check installation, discovery, and file resolution separately. Use the symptom to choose the next action:
| Symptom | Check and next action |
|---|---|
| Preview fails before listing skills | Read the actual error; check the active Node.js version, Git availability, and access to npm/GitHub. Correct that prerequisite, then rerun --list. |
The installed list has engine skills but no router | Rerun installation and include router. A manual copy of only the repository’s skills/ contents omits the separate router/ directory. |
| Files exist but the agent does not offer them | Confirm that the session is in the intended project and that each folder contains SKILL.md. Check the client’s documented paths and restart the session if discovery has not refreshed. |
The agent cannot open a path starting with skills/godot/ or skills/unity/ | Resolve the named skill through its installed location, then confirm a successful file read before editing. |
| The agent selects the wrong engine | Open the correct game subdirectory or name the intended engine and project explicitly; check the fingerprint and version it reports. |
The path-resolution case deserves attention: the router describes source files as skills/<category>/<name>/SKILL.md, while the CLI installer installs individual skill directories under their names. An agent that follows the source-relative path literally can miss an installed skill. This is a source-layout mismatch to check, not evidence that every client fails.
For a Codex or Cursor installation, a selected Godot skill may therefore resolve to .agents/skills/godot-2d-movement/SKILL.md, with its own references alongside it. Use that discovered path rather than creating a second repository-shaped tree inside your game.
Review third-party skills before reusing them
Review these files as instructions that can influence an agent’s edits and command execution. Before first use, read the router, selected skill bodies, required references, and any scripts or external commands they ask the agent to run. Check dependency installation, download destinations, uploads, and destructive operations against the task you actually requested.
The --list preview avoids installing the skill pack, but npx still runs the installer. Keep your normal command approvals and inspect the installation summary for existing skills that would be overwritten.
Also review frontmatter when adopting updates. For example, Claude Code’s allowed-tools documentation explains that this field can pre-approve tool use; it is not a sandbox restriction. Review changed instructions and bundled commands even when the frontmatter is minimal.
Keep the first change small enough to review in a diff. After adopting a skill update, repeat the relevant engine check before relying on it for a larger feature.
