Use a unified production process, selecting production, optimization, and manual acceptance rules according to purpose, with the source using video frame extraction by default. Video serves as the motion sketch; when the user explicitly selects the image route, form a sequence by interpolating frames based on the actually generated first and last frames, stage keyframes, and dual-image references. The final animation is subject to game requirements and the visual baseline. Resource delivery for the current Work Item returns to the existing control plane, and no separate animation state machine is created.
Within the scope of the current Work Item, internally propose, derive, and maintain the motion timeline design record; when requirements are clear, directly proceed with prompts and real assets according to existing authorization; the user reviews the real video, each keyframe, and the complete sequence, fixes and re-verifies according to feedback, and then returns to the control plane to submit evidence and state transitions. Only when gameplay events, duration, or behavior permissions are truly missing and cannot be derived should the affected actions be asked about.
Scope of application and runtime
This skill produces 2D frame-by-frame bitmap animations, and at runtime uses THREE.Sprite and THREE.SpriteMaterial to display as camera-facing billboards; it can be used for world-space characters/effects, and can also be integrated into an existing orthographic camera or HUD layer. The HUD's layout, scaling, and input still follow the project's existing UI system. This skill does not produce 3D skeletal model animations; assets with bones, skinning, or model motion clips use three.js AnimationMixer. If a character intentionally uses a 2D sprite representation, it still follows this skill's atlas route.
Classification entry
For each animation, first determine the purpose type and read only the corresponding classification reference; for multi-type batches, select rules region by region, and do not load all four documents by default.
| Purpose type | Basis for selection | Read reference |
|---|---|---|
| General animation | Objects, environments, decorations, mechanical motion, and state changes | General animation |
| Character action animation | Body behaviors such as idle, movement, attack, hit reaction, and jumping | Character action animation |
| Effect animation | Visual feedback such as hits, explosions, smoke, light effects, and status effects | Effect animation |
| UI frame animation | Interface motion effects that require frame-by-frame bitmap assets, such as button feedback, prompts, and icons | UI frame animation |
The purpose type does not determine the source route, behavior unit, number of generation batches, or number of runtime animation keys. Loop, one-shot, composite, and final-state hold are playback parameters shared by all types and can be used in combination according to the task. Character actions can further select rules by cyclic motion, active behavior, passive reaction, and continuous combination, without adding a new skill for each action. Simple procedural UI motion effects are handled according to the existing UI/program route.
Source route
When the user does not specify a source, use video frame extraction by default and note it in the internal motion timeline record; image recursive frame interpolation is enabled only when the user explicitly selects it or confirms switching to it. Continue using the source explicitly selected for the current task; source switching is handled according to existing change boundaries and updates the internal record, and confirmed results are not discarded due to changes in default values. If the video source or generation capability is temporarily unavailable, report the gap and do not automatically switch to the image route. The two routes share classification, the game timeline, and manual acceptance, and only the details of the current source are read.
| Source | Applicable basis | Read on demand |
|---|---|---|
| Video frame extraction (default) | Use real video as a continuous motion sketch; select valid intervals and retime by phase before extracting frames | Video rhythm organization、Extract frames by region |
| Image recursive in-betweening (explicitly selected) | The user chooses to control key poses, shapes, or transparent edges one by one; on a fixed canvas, create the first and last frames and necessary keyframes in sequence, then use two adjacent images to generate specified frame positions | Image recursive in-betweening |
For the image route, "in-betweening" is image generation with dual-image reference and specified action time points, not optical flow interpolation that guarantees geometric correctness. For cross-view, contact, occlusion, or loops with identical first and last frames, first fill in the necessary key poses, then recurse; do not infer complete complex motion from only the first and last frames.
Shared workflow
- Read the visual baseline, purpose-type reference, andcomplete motion and timeline, and establish the current animation's internal design artifact. Specify the source route, behavior boundaries, initial/final states, game duration, phase intervals, key poses, events, playback mode, anchors/allowed displacement, complete motion range, target display size, FPS, and background handling. For character actions, also specify the preceding and following action transitions, whether it loops, and the entry/exit conditions, seeTransition and loop design. Read on demandregion planning, and when batching, each region still has independent type and time mapping.
- According tomotion analysis rulesandgameplay and intent design methods, internally derive behavior boundaries, phases and motion basis, transitions/loops, and rhythm trade-offs from gameplay purpose, expressive intent, and existing time constraints, and record the suggested timeline, event time points, key pose intent, size reasoning, and per-phase checkpoints. For video, also derive the 768p/2K region layout, number of strips, whole-group consumption, and recommended plan; for clear requirements, proceed directly with reasonable parameters. Ask questions only about gameplay events, durations, or behavior permissions that are truly missing and cannot be derived, and pause only the affected actions without waiting for confirmation of the entire text design. Do not create graybox or playable geometric mockups.
- Write the formal prompt according to "shared visual and resource constraints + type rules + current animation parameters," and directly create real candidates or previews within the existing authorization scope. For video, followresolution and batching comparisonto choose 768p or 2K: first cover all actions with the minimum number of strips, then choose the option with the lowest whole-group consumption under that strip count, preferring 768p under equal conditions; for images, followimage resolution conventionsfor processing. On first delivery, directly show the real video candidate/preview or the real image first frame and keyframes, with brief checkpoints; do not first deliver a text analysis and wait for confirmation. When the user confirms actual material, you may simultaneously accept the timing expressed by that material without separately confirming a text restatement. When there is no existing generation authorization, observe external operation boundaries and do not treat route selection as authorization.
- The video route receives the real video and verifies the canvas, regions, and audio tracks, selects valid intervals and stage retiming as needed, and saves the derived source, delivering the actual final frame-extraction input for manual user acceptance. When the original video is already suitable, accept the original video directly; extract frames only after the actual video content, regions, and time mapping have been manually accepted. The SHA may serve as a tracking record and does not participate in file acceptance or replace the user's confirmation of the actual video. If it fails, correct and resubmit first; correction notes or textual plans do not replace acceptance of a new video. The image route verifies the actual output dimensions, fixes a unified canvas, and confirms the first and last; the necessary keyframes of the same continuous behavior are produced one by one in chronological order, compared with the real baseline and adjacent confirmed frames, and the next keyframe is advanced only after the current frame is manually confirmed. After the keyframes are complete and confirmed, recursively fill in the target frame positions according to internally derived time points. Actual dependencies andConsistency and continuity gatecentrally maintained; if the parent image has defects, correct them first and do not continue propagation.
- Extract frames from the video by fixed regions, and package images according to the real source list; both share background processing, proportional scaling, fixed cells/anchors, independent atlases, reports, and HTML previews. Perform local frame corrections based on feedback for the current type, retain existing retouching results and source identity, and update the atlas, report, preview, and optional SHA tracking value. Defect repair does not by default replace the entire set of sources.
- Use the real complete frame sequence to manually inspect the performance intent, rhythm, continuity, events, and single/loop/end-state and external action transitions against the stage-by-stage checkpoints in the internal design artifact, and record specific deviations and user conclusions. For local corrections with the same goal, directly rework and show a before-and-after comparison; ask only when the gameplay semantics or source route substantially changes, and do not re-request existing generation authorization. Save the classification rules, gameplay and intent derivation, real candidate review, time mapping, and final manual acceptance evidence, according toworkflow integration contractsubmit the assets, then return to the control plane to complete the ThreeJS integration and runtime verification.
Motion design and real asset confirmation
Action analysis and timeline writing into the internal design artifact; when requirements are clear, no separate textual plan confirmation gate is set. For the video route, the user reviews the real video candidates and the complete sequence; the user's confirmation of the actual video can simultaneously accept the timing expressed in it. For the image route, confirm the real first and last, keyframes, and recursive parent images one by one, then accept the complete real sequence. The real sequence preview provides play/pause, replay, and frame-by-frame viewing, and check marks are placed only in the preview interface. Formal art uses the real baseline and confirmed assets; design diagrams and historical placeholder illustrations must not be used as visual references for image generation. For local corrections with the same goal, directly rework and show a before-and-after comparison; ask again only when gameplay semantics or the source route substantially changes. For detailed requirements, seeMotion design and asset confirmation、Real asset review and acceptanceandthe boundary between design and art。
Shared quality and key constraints
- Accept based on readability, rhythm, hierarchy, continuity, and event synchronization; for specific judgments and optimization methods, seeShared quality and optimization. Weight, degree of exaggeration, pauses, and follow-through motion are configured according to type, object nature, and visual baseline, and combat rhythm is not uniformly applied.
- The duration and rhythm of each animation are first determined independently based on game characteristics, gameplay response, object nature, and expressive purpose. Multiple groups of animations in the same video may have different total durations, stage proportions, pauses, loop cycles, and FPS, and are not forcibly unified for batch processing; for specific planning, seegame time precedes sourceThe game time is independent of the source video duration; the same complete action shares its own timeline, within which events and input transitions can be marked. Production grouping does not increase the number of attacks, automatic combos, or damage, nor does it change the existing input mechanism.
- Duration, phase ratios, hitstop, combo counts, and audio are all determined by the current task; specific action and parameter cases cannot become global default requirements. Videos are laid out in 768p/2K according to actual regions, with the number of strips and whole-group consumption chosen accordingly, not by forcing fixed tiers, compressing the range of motion, or losing necessary details to make up batches. Image resolution conventions remain independent. Image sequences have no video audio track; sound is bound to events independently.
- By default, the content required to be presented and the complete range of motion are kept within frame, preserving safe margins. Cropping exceptions must have explicit authorization from the current task, with the object, scope, and reason recorded item by item; one must not crop edges on one's own for batching or to emphasize force.
- Stable anchors do not mean motion is prohibited. Allowed displacement, pose exaggeration, or deformation must be explained in the design artifact in terms of scope and intent, and accepted according to plan; unplanned drift, flicker, scale changes, and cross-region intrusion are prohibited.
- A fixed canvas, identical anchor records, and passing source verification do not prove the actual object scale, support position, or motion continuity. The image route first confirms the type-related state of the current frame and its adjacent transitions, and only then releases the production that depends on it; one must not substitute error correction with added in-between frames, per-frame scaling and centering, or static duplication.
- Background handling is chosen according to the material edges and type. Color-based background removal is used only for confirmed solid-color hard edges; semi-transparent, glowing, or unknown edges use true Alpha, masks, or frame image correction, and must not be passed off as confirmed hard edges. Whether effects, sound, and camera feedback are baked in is decided according to the task contract.
- Classification and optimization parameters are stored in the design artifact; contract fields are not added because of classification, and scripts or generation API parameters are not fabricated. Video follows the original contract; images use an independent source manifest, report, and accepted contract, recording the real generated image, parent image, time slot, generation/retouching records, and optional SHA tracking values, and must not forge video paths or source timestamps.
- Timeline derivation is recorded in internal artifacts; human confirmation focuses on the real video, image keyframes, and the complete sequence, while the file gate only verifies structure and identity. One must not automatically take screenshots or start real-device acceptance; external writes, payments, and publishing follow independent authorization boundaries.
Execution agent
The timeline design, prompts, time organization, frame extraction/image sequence integration, and corrections for a frame animation Work Item are still uniformly delegated to gpt-6.1-sol、max 's execution sub-agent. The main agent is responsible for requirements, task packages, human feedback, integration scope, review, and final verification, and does not take over animation production.
Use collaboration.spawn_agent, set agent_type="default"、model="gpt-6.1-sol"、reasoning_effort="max"、fork_turns="none". A complete task package includes the Work Item, purpose type and source route, corresponding references, gameplay purpose and presentation intent, existing gameplay time constraints, behavior/input boundaries, phase checkpoints, material and baseline paths, allowed modification scope, current candidate version/internal timeline, allowed advancement steps, acceptance criteria, test level and commands, prohibited operations, and parallel reminders. The first delivery directly provides the real candidate/preview and brief checkpoints, with the rationale for action derivation stored in internal artifacts; only gameplay conditions that cannot be derived block the affected actions. The video route hands off the current real video and human review results, while the image route hands off the currently confirmed frames and existing generation authorization to continue production.
Consecutive revisions of the same work item prioritize reusing the agent; a substantial change in scope or completion of the work item ends that lifecycle. Bitmap generation/editing is still handed to the image generation agent, and the animation execution agent provides the timeline, frame slots, and asset constraints and integrates the results. When a specified tool or model is unavailable, report the limitation; do not silently switch models. Delegation does not expand authorization for files, automated visual verification, or external operations.
Local tools and reference routing
Video frame extraction requires ffmpeg、ffprobe and the project sharp; image planning uses only Node.js, and image packaging uses sharp. First check the actual tool help for the current route:
node <skill-dir>/scripts/video-to-atlas.mjs --help
node <skill-dir>/scripts/image-inbetween-plan.mjs --help
node <skill-dir>/scripts/images-to-atlas.mjs --help
The video tool processes one region at a time (omitting it means the entire canvas), covering the complete input time range;--fps controls sampling and playback simultaneously; there is no time trimming or independent per-frame duration parameter. Image planning first determines game duration, FPS, keyframe positions, and recursive dependencies; image packaging takes FPS/loop from the source manifest, processes only actual images, and does not generate assets. For timing issues, first correct the design and sources according to the shared timeline, not just the report.
| Current stage | Read on demand |
|---|---|
| Purpose determination and type production | A corresponding classification reference above; when independent effects or UI bitmaps are involved, read its rules as well |
| Derive duration, pacing, and checkpoints from gameplay and presentation intent | intent-driven-design.md, read during motion analysis and write into existing design artifacts, reused for production and acceptance |
| Requires feedback semantics, type applicability, or event coverage rules | ThreeJS 2D Juiciness Design Guide; this Skill still produces frame animation according to the existing timeline design, real asset review, and manual acceptance of the complete sequence |
| Game time, grouping, stages, and corrections | action-timing.md |
| Effect image size inference, batching, and spatial cropping | region-planning.md |
| Image start/end, keyframes, dual-image reference recursion, and image source contract | image-inbetween.md |
| Motion design and asset confirmation, prompt composition, and source/retouching evidence | workflow-integration.md |
The global stage is still controlled bythe sole control planemanagement: V2 internally derives and records the motion timeline, V3 directly produces and reviews real video or keyframes and accepts the complete sequence, and V4 connects to three.js based on the report's TextureLoader, horizontal UV,SpriteMaterial、Sprite.center and per-frame update contract and verifies the runtime state.