Build Rigged Game Assets
Meng ToCommunityCreated by Meng To
- Skill
- Workflow
- Software development
- MIT
- Low risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a rigorous, standardized process for developing 3D game actors. It covers the entire lifecycle from source reference and rigging to runtime integration and catalog presentation. The workflow emphasizes maintaining a clear separation between immutable source assets and optimized runtime files, ensuring that characters and monsters meet specific technical budgets and gameplay requirements. It includes strict validation steps, manifest-based contracts, and requirements for interactive catalog inspectors to ensure assets are production-ready.
What it does
- Defines a structured manifest-based contract for character and monster assets.
- Provides guidelines for normalizing models, rigs, and animation libraries for game engines.
- Establishes requirements for equipment systems, socket placement, and collision contracts.
- Outlines the creation of catalog cards and interactive runtime inspectors for asset review.
- Includes a suite of deterministic tests to verify asset integrity and performance.
- Ensures consistent handling of character gear and monster combat states.
When to use it
- When importing or generating new 3D rigged actors for a game project.
- When defining technical requirements for character versus monster assets.
- When setting up or auditing an asset catalog for a game engine.
- When troubleshooting issues with character equipment toggles or animation clips.
- When preparing assets for integration into a gameplay environment.
Advantages
- Ensures high-fidelity source assets are preserved while optimizing runtime performance.
- Promotes consistency across different character and monster assets.
- Provides clear, testable criteria for asset validation and rejection.
- Facilitates easier debugging through standardized runtime telemetry and inspectors.
- Reduces integration errors by enforcing strict manifest-based contracts.
Usage examples
- “How do I add a new character to the game asset catalog?”
- The agent will guide you to copy the character-asset-manifest.template.json, define the actor's requirements, build the model and rig according to the specified constraints, and run the validation scripts.
- “Verify if my monster asset is ready for production.”
- The agent will check your asset against the monster profile requirements, including action roles, collision volumes, and catalog inspector functionality, and run the required validation tests.
- “How should I handle equipment for a new character?”
- The agent will explain how to define canonical slots, bind equipment to named sockets, and ensure that toggling equipment leaves no artifacts, following the character profile rules.
- “What are the requirements for the catalog inspector?”
- The agent will detail the necessary controls, such as action selection, drag-to-rotate, and equipment toggles, and confirm that the inspector uses the actual runtime model.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/mengto/build-rigged-game-assets/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip build-rigged-game-assets.zip -d .agents/skills
Documentation by Meng To
Build Rigged Game Assets
Build one truthful actor package from source reference through gameplay and catalog proof.
Establish the contract first
Inspect repository truth before generating or editing files:
Locate the source image/model, runtime loader, skeleton conventions, action API, equipment system, collision system, catalog schema, review routes, budgets, and tests.
Classify the actor as
characterormonster.Classify delivery as
catalog-only,review-only, orruntime. Do not call an asset implemented until gameplay loads it.Preserve immutable source artifacts separately from optimized runtime files.
Decide target formats before using a credit-bearing generator.
Copy the matching template from assets/, fill it in, and keep it beside the implementation or in the project’s asset metadata location:
character-asset-manifest.template.jsonmonster-asset-manifest.template.json
Run scripts/validate_asset_manifest.py <manifest> before building. Re-run with --root <repo> for shipped-file checks and --require-verified only after every acceptance check has actually passed.
Read references/requirements.md before creating the model, rig, actions, equipment, sockets, or collision data. Read references/catalog-and-testing.md when adding the catalog card, inspector, moveset route, telemetry, or release tests.
Build the common actor package
Preserve the source.
Record reference images, source tasks, imported files, licenses, generator/model, and material provenance.
Never overwrite the high-detail source with the runtime optimization.
Produce the main model.
Normalize scale, Y-up, forward axis, pivot, ground contact, materials, textures, and triangle budget.
Ground from feet or authored contact sockets, never a weapon tip, cloth tail, shadow, or VFX.
Remove isolated triangles, non-manifold fragments, duplicate surfaces, hidden generator debris, and unused nodes.
Build one stable rig.
Name root, hips/center mass, head, limbs, feet, and attachment sockets explicitly.
Keep at most four normalized skin influences per vertex unless the engine contract says otherwise.
Preserve a deterministic bind pose, finite transforms, positive usable scale, and compatible skeleton identity across every clip.
Build the action library.
Give every clip a stable
id, semanticrole, loop policy, root-motion policy, duration, contact events, and source.Prefer animation-only GLBs for separate clips. They must not smuggle duplicate meshes, materials, or textures.
Make non-looping actions restartable and return to the intended locomotion/idle state.
Build runtime integration.
Use one asset-specific loader/factory with disposal for geometry, materials, textures, mixers, events, observers, renderers, and animation frames.
Publish source, model, rig, socket, action, equipment, collider, triangle, material, and status metadata.
Keep a truthful rollback path when replacing a shipped runtime asset.
Apply the character profile
Treat the main model as the persistent body/base layer. Do not fuse swappable equipment into it.
Declare every canonical slot: headgear, vestment, gloves, leggings, boots, main hand, offhand, and back/ranged.
Mark unsupported slots explicitly instead of silently omitting them.
Store supported swords, shields, bows, helmets, armor, and accessories as separate assets or independently addressable roots.
Bind equipment to named sockets. Declare active and stowed sockets when an item changes state.
Toggling a slot off must leave no floating trim, grip, one-triangle shards, duplicate baked weapon, or incidental gameplay prop.
When the source contains no body beneath occluded equipment, create a fitted rig-following underlayer and record that limitation. Do not invent invisible anatomy claims.
Require the character action roles
idle,walk,run,primary-attack,hit,dodge, anddeath. Add block/ward, charged attack, cast, bow aim/shoot, jump, interaction, or class actions when gameplay exposes them.Keep equipment visibility independent from action selection unless the action deliberately changes active/stowed state.
Apply the monster profile
Treat a monster as one authored combat actor, not a player wardrobe.
Do not require wearable slots. Separate only weapons, breakable parts, dropped parts, projectiles, or props that must animate, hide, detach, or collide independently.
Require the monster action roles
idle,locomotion,primary-attack,hit, anddeath.Add secondary attack, ranged attack, pounce, cast, summon, block, stagger, roar, spawn, or phase-transition roles only when the combat design uses them.
Define navigation and hurt colliders plus per-attack telegraph, active, and recovery windows.
Bind attack origins, projectiles, VFX, audio, head/torso targeting, and feet to named sockets.
Keep visual animation separate from authoritative attack volumes, damage timing, AI state, and navigation.
Test every attack at its authored range, facing, contact window, interruption, death, and cleanup boundary.
Build the catalog lab
Create both surfaces:
Catalog card: transparent PNG, truthful label, zero WebGL canvases.
Selected inspector/review route: exactly one live model canvas with source, status, budgets, rig, sockets, actions, and known boundaries.
Provide:
drag-to-rotate while preserving page scroll;
action selection for every shipped clip, including visible Walk, Hit, and Death controls;
restart and pause/play;
equipment toggles for characters, including clean all-off and active/stowed states;
combat-state or attack controls for monsters instead of character gear controls;
a fallback image until the real model is ready;
deterministic runtime telemetry defined in the catalog/testing reference.
The inspector must load the same runtime model, rig, clips, equipment rules, and action API claimed by gameplay. A screenshot or separate look-dev mesh is not runtime proof.
Verify and commit
Run the project’s focused asset tests, manifest validator, build, lint, full tests, and git diff --check.
In the repository-approved browser:
verify the card has one transparent image and zero canvases;
verify the inspector has one model host/canvas;
click every action and confirm the selected/playing state;
toggle every character slot individually and all equipment off;
inspect front, back, and both sides for fragments, holes, grounding, and socket errors;
drag the model, scroll the page, and test the supported narrow/mobile layout;
verify fallback and model-load failure behavior;
verify no broken media or console warning/error.
Commit only the narrow asset lane. Report the manifest, main/runtime models, gear files, rig and sockets, actions, catalog route, status, verification results, known boundaries, and exact commit SHA. Report full-suite baseline failures separately.
Files
- ATTRIBUTION.mdAdded by AutoGineer876 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md7.6 KiB
- agents/openai.yaml295 B
- assets/character-asset-manifest.template.json4.5 KiB
- assets/monster-asset-manifest.template.json3.1 KiB
- references/catalog-and-testing.md5.4 KiB
- references/requirements.md7.5 KiB
- scripts/validate_asset_manifest.pyScript15.8 KiB
references/catalog-and-testing.md
Asset catalog and testing contract
Contents
Catalog surfaces
Inspector controls
Runtime telemetry
Automated tests
Browser acceptance
Reporting
Catalog surfaces
| Surface | Required behavior |
|---|---|
| Card | Transparent PNG, natural dimensions, truthful source/status label, zero canvas |
| Selected inspector | Exactly one live runtime model canvas plus loading fallback |
| Review/moveset route | Stable URL, scrollable page, action and actor-specific controls |
| Provenance | Reference, source/runtime files, generator/import type, task IDs, status, known boundaries |
| Budget | Source/runtime bytes and triangles, meshes, materials, textures, bones, actions, sockets |
The card image and runtime inspector are different artifacts. Do not replace the real model with a turntable render or initialize a renderer in every catalog grid card.
Inspector controls
Common:
action button for every shipped clip;
visible Walk/locomotion, Hit, and Death controls;
selected and playing action states;
restart and pause/play;
horizontal drag-to-rotate with
touch-action: pan-yor equivalent;fallback image until model readiness;
loading/error state that does not leave a blank canvas.
Character:
one toggle for every declared equipment slot;
active/stowed state controls when gameplay supports them;
clean individual-off and all-off states;
no incidental gameplay prop unless the inspector labels and controls it.
Monster:
action and combat-state controls;
attack telegraph/active/recovery or deterministic contact visualization when useful;
no empty player-equipment panel.
Runtime telemetry
Expose stable DOM or runtime metadata sufficient for deterministic read-back:
model readiness and source/provenance type;
actor ID, kind, and delivery status;
canvas count;
source/runtime triangle counts;
mesh, material, texture, bone, socket, and action counts;
current action and play/pause state;
drag rotation enabled, current yaw, and dragging state;
character visible-equipment list or monster combat state;
removed/hidden geometry count when cleaning fused sources;
failure/fallback state.
Telemetry must describe real runtime state, not copy hard-coded marketing text.
Automated tests
Add deterministic checks for:
Manifest schema, required roles, unique IDs, supported slots, and verified gates.
Exact source/runtime/catalog/action/equipment paths and shipped-file existence.
PNG signature, dimensions, alpha channel, and bounded size.
GLB/FBX format, file budget, mesh/material/texture/skin counts, finite attributes, and triangle count.
Skeleton identity, required bones/sockets, maximum skin influences, and bind-pose integrity.
One action per animation-only file, expected clip name, no render mesh, duration, loop, and contact events.
Character equipment visibility, active/stowed sockets, all-off cleanup, and underlayer behavior.
Monster attack roles, authoritative windows, hurt/attack volumes, interruption, death, and cleanup.
Runtime loader/factory integration, disposal, rollback, and truthful catalog status.
Catalog card/no-canvas, inspector/one-canvas, stable review URL, control inventory, scroll, and drag contracts.
Record both that the full suite ran and that it either passed or only retained documented pre-existing failures. Do not mark an unrelated baseline as an asset failure, and do not hide it.
Run:
python3 scripts/validate_asset_manifest.py <manifest> --root <repo> --require-verified;focused asset tests;
build;
lint;
full tests;
git diff --check.
Report unrelated baseline failures separately; do not relabel them as caused by the asset.
Browser acceptance
Use the repository-approved browser. For Vesperfall, use the Codex in-app browser.
Verify:
card PNG loads, remains transparent, and card has zero canvases;
preview navigation lands on the exact route;
one intended model host and canvas become ready;
action count and action labels match the manifest;
every action changes current/playing state and visibly animates;
restart and pause/play work;
every character equipment slot toggles independently;
character all-off state has zero visible equipment and no fragments from front, back, left, or right;
active/stowed equipment appears only in its intended state and socket;
monster controls expose the declared combat actions without character gear UI;
page scroll changes actual document scroll;
horizontal drag changes yaw and vertical touch scrolling remains available;
desktop and supported narrow/mobile layouts have no horizontal overflow or clipped controls;
fallback/error states are readable;
no broken media, duplicate canvas, or console warning/error.
Capture at least:
default equipped or idle view;
character all-off view or monster primary-attack view;
rotated rear/side view;
narrow/mobile view when supported.
Keep the final review tab open only when the user needs to inspect it.
Reporting
Report:
manifest path and actor kind/status;
reference/source/main/runtime/catalog paths;
model budgets and optimization delta;
skeleton ID, bones, sockets, and colliders;
action IDs/roles and clip sources;
character equipment slots/assets/states or monster attacks/windows;
catalog route and inspector controls;
focused/full test, build, lint, diff, and browser proof;
known source inference or underlayer boundaries;
exact commit and deployment state.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs Python
Security
What our scanner noticed· Low risk
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- Meng To
- Publisher
- Meng To (Community)
- Source
- MengTo/Skills · agent-skills/game-development/build-rigged-game-assets · commit 5ea1661
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Meng To.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download build-rigged-game-assets.zip