Generated banner for Build Rigged Game Assets
Generated logo for Build Rigged Game Assets

Build Rigged Game Assets

Meng ToCommunityCreated by Meng To

  • Skill
  • Workflow
  • Software development
  • MIT
  • Low risk
  • Has scripts

From the author

Create, integrate, or audit production-ready rigged 3D characters and monsters with a main model, skeleton, animation library, sockets, collision contracts, separate character equipment, optimized runtime files, catalog media, and an interactive moveset inspector. Use when generating or importing FBX/GLB game actors; defining character-versus-monster asset requirements; separating swords, shields, helmets, armor, or stowed gear; adding idle, walk, run, attack, hit, dodge, block, cast, or death clips; wiring an asset into gameplay; or adding action and equipment controls plus deterministic tests to a game asset catalog.
— the description by Meng To

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

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/mengto/build-rigged-game-assets/download
  2. Unzip 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 character or monster.

  • Classify delivery as catalog-only, review-only, or runtime. 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.json

  • monster-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

  1. 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.

  2. 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.

  3. 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.

  4. Build the action library.

    • Give every clip a stable id, semantic role, 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.

  5. 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, and death. 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, and death.

  • 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

references/requirements.md

Rigged game asset requirements

Contents

  • Common deliverables

  • Main model and optimization

  • Rig and sockets

  • Animation library

  • Character contract

  • Monster contract

  • Runtime and provenance

  • Rejection gates

Common deliverables

Every actor package must declare:

DeliverableRequirement
ReferenceImmutable source image/model plus source task, license, or import provenance
Source modelHighest-fidelity recoverable artifact, never overwritten by optimization
Main modelGrounded, cleaned, textured actor without disposable preview staging
Runtime modelBudgeted engine-ready FBX/GLB with stable scale, axes, materials, and rig
RigNamed skeleton, bind pose, skin weights, semantic sockets, and skeleton identity
ActionsStable IDs/roles, loop policy, root-motion policy, duration, contacts, and source
CollisionNavigation, hurt/target, and required attack/guard/projectile volumes
Catalog mediaTransparent card PNG plus real runtime inspector
ManifestMachine-checkable actor contract based on the bundled template
VerificationFocused tests, build, lint, full tests, browser proof, and exact commit

Keep source, runtime, animation-only clips, equipment, catalog images, and review renders in distinct paths. A static render is not a runtime model.

Main model and optimization

  • Use real-world or project-authoritative scale and record actor height.

  • Use the engine’s up and forward axes without per-frame corrective rotation.

  • Place the actor root at the authored ground plane; preserve foot contacts.

  • Count rendered triangles after runtime stripping and splitting, not only source triangles.

  • Remove non-finite attributes, degenerate/isolated triangles, unused nodes, duplicate materials, hidden generator debris, and unreferenced textures.

  • Bound file bytes, triangles, materials, textures, bones, skinned meshes, and draw calls.

  • Keep permanent anatomy/base clothing in the main model.

  • Keep anything that can be equipped, stowed, hidden, broken, dropped, or replaced independently addressable.

If a generated source fuses gear into the body, do not hide the problem with visibility flags. Audit connected components and skin weights, remove or regenerate fused equipment, then prove the all-off state from four sides. Use a fitted underlayer only when the source genuinely has no geometry beneath an occluded item.

Rig and sockets

Require:

  • one deterministic root and one declared skeleton identity;

  • named hips/center mass, head, limb chains, and contact feet;

  • normalized skin weights with no more than the engine-supported influence count;

  • finite bind matrices and animation transforms;

  • no unexpected negative scale or mirrored hierarchy;

  • consistent bone names and hierarchy across the main model and every action;

  • semantic sockets rather than hard-coded world offsets.

Character socket roles:

root, hips, head, left-hand, right-hand, back, left-foot, right-foot

Add active/stowed weapon, shield, bow, quiver, flask, VFX, camera, or interaction sockets as required.

Monster socket roles:

root, center-mass, head, vfx-origin

Add feet, jaws, claws, weapon tips, projectile origins, weak points, breakable parts, or audio emitters according to morphology and combat.

Animation library

Each action entry must include:

  • id: stable runtime/UI identifier;

  • role: semantic requirement used by validation;

  • file: runtime clip source;

  • loop: explicit boolean;

  • rootMotion: in-place, authored, or extracted;

  • durationSeconds: measured positive duration;

  • contactEvents: named normalized-time or seconds-based events;

  • provenance or provider action identifier when generated/imported.

Animation-only files should contain one clip and zero meshes. Reject duplicate skeletons, materials, or textures hidden inside clip files.

Character baseline roles:

idle, walk, run, primary-attack, hit, dodge, death

Monster baseline roles:

idle, locomotion, primary-attack, hit, death

Optional roles must come from gameplay: block, ward, charged-attack, secondary-attack, ranged-attack, bow-aim, bow-shoot, cast, summon, stagger, roar, spawn, phase-transition, jump, or interaction.

Test locomotion contact at normalized times 0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, and 1. Test non-looping clips at start, every contact event, recovery, and completion.

Character contract

Declare all canonical equipment slots even when unsupported:

SlotExpected socket behavior
headgearHead or authored helmet socket
vestmentSkeleton-bound armor layer or torso sockets
glovesSkeleton-bound hand/forearm layer
leggingsSkeleton-bound hips/leg layer
bootsSkeleton-bound foot/lower-leg layer
main-handActive hand plus optional stowed socket
offhandActive hand plus optional stowed socket
back-rangedActive hand/back and optional quiver/projectile sockets

For every supported slot:

  • identify a separate file or independently addressable root;

  • record socket roles and local transform;

  • define active, stowed, and hidden states;

  • keep collision/guard/weapon volumes aligned with the visible item;

  • dispose cloned geometry/materials safely;

  • test slot-on, slot-off, all-off, and action transitions.

The main model must remain visually coherent when equipment is absent. Do not leave shield rims, sword shards, empty grips, duplicate scabbards, or review-only flasks.

Monster contract

Monsters use combat parts rather than a character wardrobe.

Require:

  • navigation collider and target/hurt volumes;

  • authored attacks mapped to real action IDs;

  • telegraph, active, recovery, range, facing, damage, interruption, and cleanup contracts;

  • attack origins and effect sockets;

  • AI role and locomotion compatibility;

  • death/corpse visibility and collider cleanup;

  • explicit LOD behavior that does not change authoritative collision or timing.

Separate a monster part only when gameplay must independently animate, hide, collide, break, detach, drop, or replace it. Otherwise keep it in the main model.

Runtime and provenance

Expose metadata for:

  • asset ID, kind, status, and gameplay use;

  • reference, source, runtime, action, equipment, and texture paths;

  • generator/model/task IDs or imported/procedural provenance;

  • skeleton ID, bone/socket counts, action IDs, and current action;

  • source/runtime triangles, materials, textures, meshes, and bytes;

  • equipment visibility or monster combat state;

  • colliders, known inference boundaries, and rollback.

Use truthful status language:

  • catalog-only: recorded and reviewable, not loaded by gameplay;

  • review-only: live inspector exists, still not gameplay;

  • runtime: authoritative gameplay path loads it.

Rejection gates

Reject or block release when:

  • a character main model still contains swappable gear;

  • action files carry duplicate render meshes;

  • skeletons or bone names differ unexpectedly across actions;

  • any required role, socket, collider, equipment slot declaration, or provenance field is absent;

  • toggling gear leaves visible fragments or holes without a declared underlayer boundary;

  • a monster attack animation has no authoritative timing/collision contract;

  • the catalog card initializes WebGL or the inspector uses multiple unintended canvases;

  • controls do not exercise the real runtime action/equipment API;

  • the page cannot scroll or drag rotation blocks vertical touch scrolling;

  • browser, build, lint, focused tests, or required manifest validation fails.

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 or Meng To.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download build-rigged-game-assets.zip