hologram-presenter-video

holographic explainer video

On the premise of reusing one set of character and scene profiles, establish a traceable video production process through multiple confirmation Gates. The explaining character speaks the already-confirmed voiceover script in each generated segment; different segments change viewpoint and composition through hard cuts, and are finally merged into one MP4 video.

Non-violable rules

Maintain only one current Profile; do not implement a Profile selector.
Treat character images and scene images as mutually independent style references. When encountering cartoon characters with realistic scenes or other mixed combinations, do not forcibly unify them into the same art style.
Use the user-confirmed voiceover script as the sole source of truth for knowledge content; do not silently add external facts.
Before Gate3 is confirmed, do not call any video generation API.
Do not add background music or transitions.
Paths in instructions, scripts, configuration, and persistent runtime artifacts must use relative paths. Users may provide absolute source image paths, but after copying images, the absolute path must not be persisted.
Every Gate must wait for explicit user confirmation; do not treat silence as consent.

Relative path baseline

Skill resources are resolved relative to the directory where this Skill is located.
profile/profile.json The paths inside are resolved relative to profile/ .
Runtime artifacts are created under the user's current working directory.
Paths in a single-run manifest are resolved relative to that run directory.
Do not assume that this Skill is installed in any fixed location.

Execution order and phase boundaries

Profile construction and a single video task are two strictly serial phases that cannot be advanced in parallel. Each time this Skill is invoked, the Profile must first be checked, and then start from the currently applicable phase; when a Profile needs to be constructed, only after Gate0 is confirmed and the complete Profile is successfully written may you continue in the same invocation into the single video task phase:

If profile/profile.json is incomplete, referenced images are missing, or the user explicitly requests redesigning the Profile, enter Profile construction phase。
The Profile construction phase only handles character images, scene images, image analysis, long-term style preferences, and Gate0. Before Gate0 is confirmed and the complete Profile has been successfully written, do not ask about the current episode's content, target duration, single-episode audience, single-episode explanation depth, or other requirements for the current video; do not create the hologram-video-runs/ run directory,run.json, voiceover script, or storyboard, and do not execute Gate1 or later steps in advance.
If the user has already proactively provided the current episode's content or target duration, these pieces of information may be retained in the conversation, but the Profile construction phase must not process them, ask follow-up questions about them, or create runtime artifacts based on them. After the Profile is successfully enabled, reuse the information already provided; do not ask again.
Only when the check confirms that the Profile was already fully available at the start of this invocation, or it has just been successfully established through Gate0, may you enter the single video task phase; only at this point obtain the current episode's content and target duration that have not yet been provided.

Do not parallelize or mix questions from the two phases in order to reduce dialogue turns.

Gate0: Establish a reusable Profile

Each time a request is received, first check profile/profile.json Whether it contains all of the following required fields, and whether the two images referenced therein exist.

If the Profile is complete, directly reuse it and skip image collection. If any required file is missing, the user must be required to provide one local character image and one local scene image at the same time. When the user has not provided the two images, explain this prerequisite and terminate the subsequent video production process.

If the user explicitly requests to redesign, replace, or reset the Profile, the two images must also be provided again and the Profile must be completely rebuilt; replacing only one of them is not supported. Before the new Profile is confirmed and ready to be enabled, save the old current Profile as the sole profile.backup/; if an old backup already exists, replace it.

Whenever entering the Profile construction stage, fully read and follow references/profile-interview.md. This reference file is responsible for image analysis, drafting the five description fields, scene scheduling screening, the long-term preference interview, and the Gate0 semantic review; this entry file is only responsible for stage orchestration and persistence. After waiting for the explicit Gate0 confirmation specified in the reference file, copy the two images to profile/assets/, preserve meaningful file extensions, and write the following minimized Profile. The persistence path records only the relative path after copying.

Write the following minimized profile/profile.json：

{
  "updated_at": "YYYY-MM-DDTHH:mm:ss",
  "character_image": "assets/character.png",
  "scene_image": "assets/scene.png",
  "character_description": "一段自然语言描述",
  "scene_description": "一段自然语言描述",
  "visual_defaults": "一段自然语言描述",
  "presentation_defaults": "一段自然语言描述",
  "staging_defaults": "一段自然语言描述"
}

In the example, the .png only indicates the field format; the actual file names preserve the real extensions of the copied images, and the two paths must be consistent with the files in profile/assets/ .

Start a video task

Before entering this stage, it must be confirmed again that the complete Profile already exists and that the images referenced therein can be read; otherwise, return to Gate0, and do not ask for single-task information. Only after confirmation may the user content and target duration be obtained. The content may be highly condensed notes, a complete script, pasted context, or a readable local file. Extract the audience, explanation depth, degree of wording preservation, and special expression requirements from this request; when the user has not specified them, use presentation_defaults to make reasonable inferences. Ask the user questions only when unresolved ambiguity would significantly change the script.

Using local time precise to the second, create under the current working directory:

hologram-video-runs/YYYYMMDDHHMMSS/
├── run.json
├── script.md
├── storyboard.json
├── prompts/
├── ref2v-tasks.json
├── clips/
└── final.mp4

If a directory with the same timestamp already exists, append a short numeric suffix; do not overwrite an existing directory.

Keep run.json minimized:

{
  "created_at": "YYYY-MM-DDTHH:mm:ss",
  "status": "awaiting_gate1",
  "target_duration": 30,
  "script_path": "script.md",
  "storyboard_path": "storyboard.json",
  "final_path": "final.mp4"
}

status Only awaiting_gate1、awaiting_gate2、awaiting_gate3、generating、failed and completeare allowed. Overwrite the current state directly each time; do not save state history.

Gate1: Confirm the spoken script

From the information provided by the user, distill and rewrite a spoken script of approximately the target duration. Strictly constrained by the input source: it may reorganize, clarify, simplify, and use analogies, but unless the user explicitly requests research, it must not supplement from the internet or fabricate new facts. When encountering substantive contradictions or key omissions, point out the problem; do not guess.

Before generating the script, first calculate the budget for the entire spoken script according to the target number of seconds:

The ideal writing range is 4.6–5.0 spoken units per second.
The range allowed to enter Gate1 is 4.2–5.2 spoken units per second.
When it is greater than 5.2 per second, it must be condensed; when it is greater than 5.8 per second, it is severely excessive and must be rewritten.
When it is less than 4.2 per second, effective explanatory content should be added; if the user explicitly wants to preserve a slow pace, long pauses, or a large amount of performance without dialogue, first explain the impact and obtain confirmation.

The calculation rules for spoken units are exactly the same as Gate2. After drafting according to the budget, first write the candidate spoken script body into script.md; no title, word count, duration description, or other non-dialogue content may be added to the file. Then, in the current run directory, execute:

python3 <skill-dir>/scripts/check_dialogue_density.py \
  --script script.md \
  --target-duration <target-seconds>

If the check fails, Gate1 must not be shown; based on the result, expand or condense the candidate script and run it again. Facts that do not exist in the source must not be introduced to meet the budget. The only exception is when the check result is TOO_SHORT, and the user has already explicitly confirmed before Gate1 that a slow pace, long pauses, or more non-dialogue performance will be used; apart from that, Gate1 may be entered only after the check passes.

Gate1 shows only the target duration and the complete script. When the user requests changes, first overwrite the revised complete body text into script.md and rerun the full-script check; only after the check passes and the user explicitly confirms may the run status be updated to awaiting_gate2. Therefore, the script.md that enters Gate2 is always the fully consistent final confirmed draft.

Gate2: Confirm the H3 storyboard

First, according to complete semantic boundaries, split the script.md confirmed in Gate1 into segment-by-segment dialogue:

The duration of each segment must be an integer from 8–15 seconds, with 10–12 seconds preferred.
Keep a sentence within the same segment as completely as possible.
If a sentence is clearly too long, it should be shortened during the Gate1 stage rather than split across segments.
Each segment corresponds to an independently generated video, containing only one continuous [Shot 1], and must not be cut again.
Change the perspective, composition, shot size, and character positioning between adjacent segments; use hard cuts directly between segments.

First create storyboard.json, using a top-level array. Each element contains only the following four fields:

{
  "id": "001",
  "duration": 10,
  "dialogue": "本分镜中角色说出的完整台词。",
  "prompt_path": "prompts/001.txt"
}

dialogue must come from the script confirmed in Gate1 and is the only dialogue source for that storyboard. For all storyboards, the dialogue when concatenated by number must match the content and order of script.md ; only splitting by storyboard boundaries is allowed, and no rewriting, addition, deletion, or polishing is allowed at this stage.storyboard.json does not store derived fields such as the number of spoken units, density, suggested duration, or check status.

For all storyboards, the sum of duration must be as close as possible to the run.json in target_duration, with a maximum planned error of 10%. If this cannot be satisfied due to the 8–15 second integer segment constraint, explain this to the user before Gate2 and confirm a new target duration; the final plan must not be changed silently.

Dialogue density check

Directly calculate spoken units for the storyboard.json of each storyboard in dialogue :

Each Chinese character counts as 1 unit.
Each continuous English word, English abbreviation, or number group counts as 1 unit.
Punctuation and spaces are not counted as units.
Dialogue density equals the total number of spoken units divided by the set number of seconds for that storyboard.

Use the following thresholds:

Recommended range: 4.2–5.2 units per second.
Warning range: greater than 5.2 and no more than 5.8. It may be retained only when the sentence structure is simple and there are few visual state changes.
Hard upper limit: 5.8 units per second. If exceeded, prompt generation must not continue; the duration must be extended, the dialogue shortened, or the storyboard split. Prefer extending or splitting; if shortening the dialogue would change the Gate1 confirmed draft, the modification must first be submitted to the user for confirmation.
When there are many enumerations, many technical terms, or many holographic state changes, the target density should be no higher than 5.0 units per second.

During planning, 向上取整（口播单元 ÷ 5.0） may be used to obtain the suggested duration, then constrained to within 8–15 seconds; if the result exceeds 15 seconds, it must be shortened or split.

Execute in the current run directory:

python3 <skill-dir>/scripts/check_dialogue_density.py \
  --storyboard storyboard.json \
  --target-duration <target-seconds>

<skill-dir> only denotes the Skill directory obtained through runtime resolution; the absolute path of the installation location must not be written into persistent files. When FAIL appears, it must be corrected storyboard.json and re-run; when WARNING appears, it must be reviewed in combination with the sentence pattern and the visual action load, and must not be directly ignored. Only after the check passes, or the warning items have been reviewed, may the H3 prompt be generated.

Whole-film scene scheduling and diversity

After passing the dialogue density check, read staging_defaults, and plan all storyboards as a whole, rather than choosing compositions in isolation segment by segment.

Ordinary standing explanation is always a valid basic method; it is not required that every segment use a scene anchor.
According to the knowledge semantics of each segment, select suitable high-value scheduling capabilities and their scene anchors; do not use objects that do not exist in the reference image or whose spatial relationships are unreliable merely for the sake of variation, and do not always prioritize the information device most easily associated with knowledge display.
Treat a group of behaviors in the Profile that share a core object, spatial position, or holographic carrying area as the same anchor cluster. Changing behavior within the same anchor cluster does not equal changing the core scene anchor, but unique changes in posture, orientation, explanation state, or action stage still count as meaningful behavioral diversity and must not be lost during merging or planning.
When judging whether two schedules are duplicates, compare the complete observable configuration, including body support, posture nature, the orientation relationship between the character and the anchor, activity state, interaction target, and holographic carrying mechanism; do not compare only action verbs.
State change is not a mandatory item for every storyboard or anchor. Adopt it only when the reference image explicitly supports it, the change is indeed caused by the anchor, it can be completed within a safe composition, and it brings added value relative to other storyboards; otherwise, use a stable posture, operating state, or gestural interaction.
When a state change is indeed adopted, specify in the prompt the observable starting state, the connecting action supported by the anchor, and the ending state; abstract labels such as "change orientation" or "state switch" are not storyboard design in themselves. Prefer describing how the character's relationship to the anchor changes, and do not persist generic camera outcomes such as "fixed frontal" as scheduling capabilities.
Across the whole film, maximize the diversity of scene anchors, character behaviors, character positions, orientations, holographic directions, and safe camera positions as much as possible.
When suitable alternatives exist, avoid adjacent storyboards simultaneously repeating the core scene anchor and character behavior. When reuse is necessary, create obvious differences through other dimensions such as character position, orientation, action stage, holographic direction, or safe camera position.
Scene scheduling should form a credible relationship with holographic knowledge interaction through character actions, information sources, or carrying space; do not replace the core characteristics of this Skill with irrelevant scene actions.
Knowledge expression, character clarity, and generation stability always take precedence over formal difference. When a segment is truly unsuitable for a scene anchor or holographic causal interaction, do not force it in.

This planning is only used to guide the subsequent English H3 prompt. Do not add to storyboard.json any scheduling fields, and do not create scheduling checklists, scoring, quotas, or structured duplicate-check scripts. After all prompts are completed, they must be reviewed as a group for overall diversity and cross-segment sound consistency before submitting to Gate2.

Composition safe area

Video models lose identity, facial, limb, and text details when the subject or information elements occupy too small a proportion of the frame, so all storyboards must continuously satisfy the following composition constraints from the first frame to the last frame:

Characters use a close-up composition above the shoulders by default; storyboards that need to reserve more frame space for larger hand movements or interaction objects may be relaxed to a medium close-up, but no farther. Medium shots (above the waist), medium-long shots, long shots, full-body compositions, or complete environment overviews must not be used as character explanation shots.
The opening composition must already be within the safe shot size range, and must not rely on a push-in in the latter half to make the character clear.
The character's face must remain in a clear, prominent area of the frame; hands used for interaction must be clearly visible when the interaction occurs, and may be raised into the frame or positioned at the lower edge of the frame; at other times the frame may retain only the face and shoulders.
Verify shot size by frame proportion, not just by shot size name: video model actual output is usually smaller than the proportion declared in the prompt, so write in the prompt based on the face occupying about 40% of the frame height, and never declare a lower value from the first frame to the last frame.
Use negative phrasing in the prompt to lock the lower limit of shot size: the waist and below must not enter the frame, and furniture, displays, and environment overviews in the scene must not become the main subject of the frame, appearing at most at the lower edge of the frame.
The full Profile is still used to maintain character identity, but detailed_description may only emphasize features actually visible in the current safe composition, and must not widen the shot size in order to show the complete styling.
Small push-ins, lateral moves, pans, tilts, or orbits are allowed; at no time may the camera pull back beyond the medium close-up range, that is, it must not retreat to a medium shot or farther. Storyboard variation mainly comes from camera angle, the character's left-right position, gaze direction, holographic element orientation, and interactive actions, rather than widening the shot size.
The main holographic information unit currently carrying knowledge should be located in the foreground or midground near the character's hands, preferably occupying at least about 25% of the frame width, and must not be shrunk into a distant background decoration.
If a carrying position in the Profile cannot be included in the safe composition at the same time as the character's action, retain the credible scene anchor and action relationship, and adjust the holographic information to a stably visible area near that anchor; do not widen the shot size in order to comply with a low or invisible carrying position.
At the same moment, prioritize highlighting 1-2 main information units. For multi-step content, use the method of appearing in sequence, enlarging the current item, and weakening already-covered items; do not shrink the character or the main holographic elements in order to accommodate all information at once.
If the character and all necessary information cannot remain clear within the safe composition at the same time, the storyboard should be split, and one must not fall back to a wide shot to solve insufficient space.

In H3's English detailed_description , explicitly write: the character maintains a close-up (above the shoulders) composition throughout, or relaxes to medium close-up when permitted by this storyboard, with the face large and clear, occupying about two-fifths of the frame height, and satisfying that proportion in the first frame at the opening; and explain that the camera will not pull back to a medium shot or wider framing throughout, and that the waist and below and environment overviews do not enter the main subject of the frame. Any room layout, complete appearance, or information overview requirement must not override this constraint.

Dialogue verbs and holographic interaction

Verbs in spoken dialogue are the easiest source of standout holographic interaction. Before writing each prompt segment, check whether that segment's dialogue contains verbs suitable for translation into holographic interaction; if so, design it as the highlight beat of that segment.

Applicability determination. The verb must be semantically capable of taking holographic information as its object and be translatable into a visible hand or body action, such as "take out, write in, compress, expand, dismantle, stack, compare, flip". Abstract static verbs (think, mean, represent), pure speech verbs (say, tell, explain), and weak pointing verbs (look, point) do not apply; weak pointing belongs to generic gestures and does not constitute a highlight. When the verb acts on an entity anchor in the scene (rather than holographic information), handle it as scene scheduling; this section does not apply.

Design method. The verb interaction must be synchronized with the moment the verb is spoken in the dialogue: in detailed_description write clearly that when <Subject 1> (S1) says the word, the action occurs, and describe it in the order of initial state → hand action → holographic end state; the character maintains natural narration during the action. The interaction is one beat within the segment, not dragging through the entire segment, and remains stable explanation the rest of the time. At most one active verb interaction per segment; when there are multiple candidates, choose the one with the strongest relationship to the knowledge and the most visible action. Verb interaction is the preferred implementation for causal interaction between the character and holographic information; when there is no suitable verb, fall back to existing rules, and do not force it.

Constraints。

The action must be credibly completed within the composition safe area, and the interacting hand must be in the visible area of the frame; for verbs that require large arm movements or low-position space to complete, abandon the interaction and use stable gestures instead.
The interaction reuses the segment's current main holographic information unit, and does not add a new information unit for the action.
Do not rewrite, add, or delete confirmed dialogue in order to create an interaction.
When reviewing diversity across the whole film, adjacent storyboards must not repeat the same type of verb interaction; when dialogue verbs are similar, change the hand action, holographic response method, or interaction orientation.

Few-shot examples(This only explains judgment and writing, and does not constitute a fixed mapping; the same verb should be redesigned in different storyboards according to the current holographic content.)

Positive:

Dialogue "let's take this concept out and look at it" → as <Subject 1> (S1) says "take out", she reaches into the floating holographic cluster near her hand and pulls one glowing panel forward into the foreground, where it settles enlarged beside her face.
Dialogue "write the result in" → as <Subject 1> (S1) says "write in", she traces a short stroke toward the holographic panel, and a new line of text inscribes itself onto the panel under her fingertip.
Dialogue "this information is compressed into one metric" → as <Subject 1> (S1) says "compress", she brings both hands inward, and the scattered holographic blocks shrink and merge into a single compact readout between her palms.

Negative (ignore, do not design interaction):

"let's take a look at this data" — weak pointing verb, use regular gaze and gestures.
"this means higher efficiency" — abstract static verb, no translatable physical action.
"I'll tell you a pattern" — pure speech verb, the action is unrelated to holographic information.

After passing the dialogue density check, you must clearly tell the user that you are using the h3-prompt-writing Skill. Load that Skill and its complete reference mode Ref2VA guide, and follow its current field names, section order, tags, timing rules, and detail requirements. Do not copy or approximately reproduce external rules from memory, and do not use scripts to concatenate, replace, or inject H3 prompts.

For each segment:

Use the copied character image as reference image 1 and the scene image as reference image 2.
Define the explanation character from <Picture 1> as <Subject 1>, and define the environment from <Picture 2> as <Subject 2>。
In the prompt, fully reproduce the character, scene, visual, and explanation style descriptions to ensure that each segment independently receives the reference constraints and does not rely on the prompt context of other segments. For staging_defaults, only write the scene staging method actually selected for this segment; do not enumerate all unused possibilities in every prompt.
Always mark the character as speaking with <Subject 1> (S1)。
Use storyboard.json as the sole dialogue source for this segment's dialogue , and have h3-prompt-writing write the corresponding <d>[Language] ...</d>according to its current specification. Do not rewrite the wording; only the language tags and punctuation normalization explicitly required by that Skill are allowed.
All six prompt sections of H3 use English; dialogue, proper nouns, and on-screen visible text retain their original language.
Use the explanation preferences in the Profile to describe voice performance, facial expressions, and actions; the voice descriptions of all segments are verbatim identical, and performance embellishments are limited to outward-facing emotions; descriptions that change the vocal mode, such as whispering or hushed speech, are prohibited.
When the content is suitable, prioritize designing clearly visible causal interactions between the character and the holographic information; when a segment has no suitable content to carry, do not force interactions into it.
If charts, models, comparisons, processes, or highlighted concepts can convey knowledge, do not generate only decorative holographic effects.
Text is allowed to appear in holographic information only when it is itself knowledge-bearing (key numbers, formulas, or core terms); decorative labels, titles, and list text are all replaced with graphics; the glyph height of any text that appears must not be less than one third of the frame height, each storyboard has at most one text element, and this threshold applies uniformly to Chinese, English, and numerals.
No emoji characters may appear in the prompt; all required graphics are described in text; there is also no need to write negative statements such as "do not use emoji" in the prompt.
Include character dialogue, appropriate ambient background noise, and restrained holographic interaction sound effects.
Explicitly prohibit background music, and write in non_diegetic_music: N/A。

Save the complete English prompts in order as prompts/001.txt、prompts/002.txt and other files, and keep each prompt_path consistent with the actual files. Dialogue density is verified only based on the structured storyboard.json in dialogue ; dialogue consistency in the prompts is semantically reviewed by the Agent against storyboard.json , and the prompts must not be reverse-parsed or rewritten with scripts.

Gate2 displays only each segment's number, duration, and English prompt path. Do not create Chinese prompts or Chinese review translations. After waiting for user confirmation, update the status to awaiting_gate3。

Find generation capabilities and execute Gate3

After Gate2 confirmation, check the currently available Skills and look for a capability that can generate video based on multiple local reference images and prompts. Do not hard-code the name of any video generation Skill.

If none is found, explain that the process must rely on a multi-reference-image video generation Skill, and terminate the subsequent process.
If only one is found, select that Skill.
If multiple are found, list their names and substantive differences and let the user choose.
Load the Skill selected by the user and follow its input, batching, retry, and output rules. Do not reimplement its upload, polling, retry, or download logic yourself.

Generate according to the requirements of the selected Skill ref2v-tasks.json. Within the file, use paths relative to the current run directory, and invoke the generation process from that run directory. All tasks use the same reference image order: character images first, scene images after. Save or normalize the returned successful clips to clips/<id>.mp4, ensuring the final order is definitive.

Gate3 displays the number of storyboard shots, the sum of the planned durations of each segment, the two reference image paths, the clip directory, and the final video path. You must wait for explicit user confirmation before making any external generation calls.

Generation, failure recovery, and concatenation

After Gate3 confirmation, update the status to generating, and submit the task through the selected generation Skill.

When some tasks fail, retain the clips that already succeeded, and never concatenate an incomplete video. The selected generation Skill is allowed to perform the internal retries specified in its documentation; after all internal retries are exhausted, update the status to failed, report the failed storyboard shot numbers and errors, and wait for user confirmation before initiating again any generation call that may incur costs. After the fix is confirmed, modify only the failed prompts or tasks, unless the user explicitly requests to expand the scope of modification.

When all numbers in storyboard.json have readable normalized clips, execute:

python3 <skill-dir>/scripts/concat_videos.py \
  --storyboard storyboard.json \
  --clips-dir clips \
  --output final.mp4

The above <skill-dir> represents this Skill directory resolved at runtime; the placeholder or the absolute path of the installation location must not be written into persistent artifacts.

The concatenation script performs hard cuts; when necessary, unify incompatible clips to H.264/AAC, and verify that the result is readable. The script must not add transitions or music, nor check the final duration. Retain all original clips. After success, update the status to complete, and inform the user of the final local path.

Modifications requested by the user

Execute modifications strictly according to the user's requirements. Do not design automatic invalidation, fallback, or versioning rules on your own, and do not overturn the scope of modification specified by the user. If a modification requires re-invoking external generation capabilities, first display the updated generation scope and obtain user confirmation before calling.