Producing a Heaven-and-Earth Avatar Video from Consecutive Frames
Break a legible display of power into consecutive states, then assign the motion between adjacent states to video generation. Deliver a plan, keyframes, or a finished video according to the user’s request for this task; do not automatically expand the scope.
Taking Over from the Current Progress
- If there is an approved style image: use it directly as the master and do not run style selection again.
- If there are approved consecutive frames: check for contradictions between frames before producing the video, and do not regenerate the images.
- If only a plan, Skill, prompts, or keyframes are needed: complete the corresponding part and do not automatically submit billable video-generation tasks.
- If the user says “continue after selection,” stop at the selection point. If a selection or authorization has already been made, do not ask for confirmation again.
- When noncritical preferences are missing and autonomous decisions are allowed, proceed with reasonable defaults. A rainy night, eight frames, 25 seconds, a knife, and background music are not fixed requirements.
Event cards from
may be accepted, or the user’s concept may be used directly, with no need to install an additional Skill. Keep source-text facts F, audiovisual treatment P, and new adaptation A distinct. Domains, dharma manifestations, and weapons shown in reference videos must not be treated as facts from the novel. When there is no source text, describe the result as a visual-concept interpretation.
Tool Selection: Platform-Agnostic
This Skill defines a fixed production method but does not prescribe a default delivery platform. Image generation, image-to-video conversion, editing, and audio mixing may be performed with different tools or within the same platform.
- Prioritize a user-specified tool or an existing project, while verifying its actual capabilities. Do not automatically select Pexo merely because it was used in a previous case.
- When no tool is specified, choose based on currently available tools, their ability to handle reference images, duration, downloadable output, and budget, and briefly explain the reason. If a workable plan already exists and the user allows autonomous decisions, no separate confirmation step is needed for platform selection.
- If no callable generation tool is available, deliver standalone keyframes, tool-agnostic segment briefs, and prompts, and explain the missing capabilities. Do not claim that prepared assets have already been turned into a video.
- Verify the current API or interface first, then map the tool-agnostic brief to specific parameters. A platform name does not indicate model capabilities; do not assume that every platform supports multi-image references, first-and-last-frame constraints, or native audio.
1. Lock the Co-Presence Relationship and Continuity
Use a concise continuity table to record the available information:
| Item | Content to lock |
|---|
| Character | Face, age, hairstyle, robe silhouette, materials, and identifying features |
| Dharma manifestation | By default, an enlarged manifestation of the same character with the same face and clothing; if the user specifies a deity or other form, record their relationship |
| Shared-frame space | The true body in the foreground and the dharma manifestation behind it, towering over buildings; the small human silhouette and the giant manifestation’s face must remain simultaneously legible |
| Body and frame coordinates | Which hand anatomically holds what, and where the starting and ending positions appear in the frame |
| Scene | Architectural landmarks, light sources, weather, camera position, and action axis |
| Material progression | For example, silver-gray apparition → skin-tone clothing → dissipation at the edges; do not impose it if the user does not need it |
| Attack | Wind-up → charging → release → recovery, including the number of attacks, direction, force recipient, and environmental reaction |
Matched-action mapping, not a horizontal mirror. The true body’s anatomical right arm corresponds to the dharma manifestation’s right arm. Do not use an ambiguous “mirror pose” that causes a left-right reversal. The dharma manifestation must not become a second opponent in the distance, and a standalone close-up of the giant face cannot replace the required shared-frame key image.
By default, retain the master’s single camera position or use a subtle push-in to reduce continuity difficulty. If the user wants multiple camera positions, clearly specify the cuts and action axis; a single camera position is a default, not a stylistic prohibition.
2. Design State Changes Before Generating Independent Frames
Read references/keyframes.md. For each frame, record the true body’s pose, the dharma manifestation’s pose and opacity, weapon state, environmental reaction, differences from the previous frame, and actions that have not yet occurred. The differences should be visible in the image.
A common structure is “gathering momentum → domain beginning to open → initial appearance → expansion → materialization → blade gathering and hand rising → synchronized release → aftereffects.” These stages may be combined or split. If the gap between gathering the blade and raising the hand is too large, add a transition state rather than packing more requirements into the same prompt.
Use the currently available image-generation or image-editing tools. If the user specifies a platform or model, verify its actual callable capabilities. If the API does not return a version, record the channel and state that the “version was not disclosed”; do not falsely claim a specific model such as GPT-Image 2.
Generate one standalone image at a time and preserve the aspect ratio. Typically, provide the “approved master + previous approved frame.” The master maintains identity, while the previous frame maintains state. If the previous frame contains an error, correct it first rather than propagating the error or submitting all images at once. Early frames must explicitly suppress the climax elements visible in the master: the giant face must not appear before the manifestation does, and the complete blade flash must not appear before the release.
Inspect every generated frame before continuing. If only the dharma manifestation’s arm is incorrect, make a targeted edit while preserving the correct true body, face, clothing, and scene. Reasonable variation in local textures is acceptable, but major contradictions involving identity, hand side, or action stage must be resolved first.
3. Assign Inter-Frame Motion to Video Segments
Read references/video-and-qa.md. Divide the sequence according to duration capabilities and action complexity, with adjacent segments sharing one approved boundary state. A shared image does not guarantee a natural continuation after generation.
For each segment, specify the starting state, ending state, motion references, primary action, camera movement, correspondence between the true body and the dharma manifestation, environmental response to force, sound rhythm, and ending pose. Images fix appearance and state, while the video prompt describes motion between states; do not create a slideshow of static images.
Use dedicated first-frame or last-frame fields if the interface provides them. An ordinary
may only be described as an ordered reference list. When there is no end-frame constraint, inspect the actual end of the segment and, if necessary, use the approved segment ending as the next segment’s starting frame. Independent clips should be submitted simultaneously only when their boundaries are clear and the tool supports the corresponding constraints.
Read the optional adapter instructions in references/pexo.md only if Pexo is actually being used for this task. It is not the default entry point or a required dependency; use the tool-agnostic brief and current capabilities for other tools.
4. Review, Correct, and Composite
Inspect the actual footage before deciding whether to regenerate it. Prioritize corrections to the source relationship, hand side and direction, repeated attacks, reversed motion, and major identity drift. Judge material deviations against the original objective, and do not let a platform’s one-line self-check assessment directly trigger a billable retry.
Sharing the frame does not mean moving in synchronization. A key error occurs when the true body has lowered its knife while the dharma manifestation is still holding its knife up. Inspect the footage before and after the release and at every junction. Use reasonable cropping, matched cuts, and audio bridging to resolve small differences; do not use reverse playback or long cross-dissolves to conceal incorrect poses.
Record both the original and corrected versions, and do not overwrite the only successful asset. Each pass must address clearly defined defects; reserve sufficient budget for retries and post-production. Do not exceed a user-specified limit, and report any deviation from the assistant’s own cost target. Account for each corrected segment individually, and do not describe “one round” as a free retry.
Arrange the audio around the gathering, release, and aftereffects, while retaining useful ambient and action sounds. If the music is too long, trim and fade it first, and consider regeneration only if the content itself is unsuitable. A “replace the audio track” operation must not be described as “overlay and retain.” If the platform cannot mix audio, external post-production may be performed under the existing authorization, but the division of work must be stated accurately.
Example of a local technical check:
bash
python3 scripts/audit_video.py /absolute/path/final.mp4 --cuts 6.04,12.08,17.12 --out /absolute/path/qa
Cut points must use the actual timeline. Python 3, ffmpeg, and ffprobe are required. The script outputs media parameters, a full overview, junction frame extraction, black-frame detection, and volume checks. It does not judge character synchronization, perceived audio quality, or the presence of vocals, so visual inspection and appropriate audio checks are still required.
Delivery
Deliver standalone keyframes and/or a downloadable finished video according to the agreed scope, retaining the state table, prompts, and production record. Record the actual tools and verifiable models, timeline, retries, consumption, and remaining discrepancies. For a finished video, also record the source assets and output specifications. Do not describe upscaled footage as natively high-resolution, and do not treat a platform’s “completion” status as acceptance testing.
Finally, present the finished work and its important limitations directly. For a real-world example, read references/worked-example.md. Historical prices and results do not constitute guarantees of success, budget requirements, or follower growth.