Animated Sprites

Treat character identity, animation behavior, and the target's technical contract as separate requirements. A valid atlas can still contain a distracting or unreadable animation.

Establish the target

• Resolve the actual reference art, existing asset, requested change, and delivery destination. Review-only requests do not authorize regeneration or application; supplied local bytes can be reviewed without a remote fetch or mutation.
• Read the target's current format/runtime contract: required states and their meanings, frame order/counts, canvas and cell geometry, anchors, transparency, timing, repeat/trigger behavior, and available controls. Do not infer a schema from a previous pet. For custom Codex/ChatGPT pets, use the available product-specific creation/update skill and current sprite contract for formatting, validation and lifecycle operations; this skill supplements their art and motion decisions.
• Distinguish technical state identifiers from user-visible meanings. A state called running can mean active work rather than foot-running.
• Record approved artwork and protected frames before revising. Preserve existing asset identity and activation state unless the user requests otherwise.

Build or revise

For character design, new choreography, directional poses, or repeated generation failures, read Art direction and generation.

Stage the action for the intended display size: approve readable key poses and silhouettes before filling the timing budget. Use anticipation, arcs, spacing, easing and follow-through where they clarify the action; keep secondary motion subordinate to its meaning.

Define the identity lock and a short frame plan before generating: what communicates each state, what moves, what stays anchored, and how the motion returns. Generate coherent pose families using the approved character reference. Register with a shared scale; never independently fit every pose into its cell. Intentional jump lift and gait bounce must survive assembly.