Vibe Science Video
Turn knowledge into animations that viewers will watch to the end, understand causality, and hold up to actual playback. The goal is to establish a quality baseline close to publish standards on the first pass, then fix issues using evidence-based checks. Do not promise that any arbitrary topic will succeed on the first attempt, and do not treat generated source code as a delivered video.
First, Determine Where the Task Is
- New Work: Read Story and Evidence, Visual Direction, create a brief, fact ledger, and storyboard.
- Continue Existing Project: First find the current delivery checklist, final audio track, timeline, and user's latest feedback; preserve satisfactory shots and old outputs, do not overwrite final versions with historical drafts.
- Fix Specific Issues: Read the repair section of Production, Check, and Fix, record the timestamp, object, and phenomenon, then decide whether to replace the audio track, re-render, or rearrange the entire film.
- Only Cover or Copy: Read Publishing Assets, do not start unnecessary video rework.
When producing a new film, redefining visual direction, or adding/replacing visual assets, first check the project's existing model library, then decide to model or download. Read the project's assets/models/README.md, inventory.json, and existing previews; when there is no inventory, use the read-only inventory tool from Model Reuse Flow to find actual files. Choose reuse based on scientific objects, shot needs, and confirmed style, and record files and trade-offs in the Asset Plan. When only changing subtitles, mixing, or publishing copy, no need to re-scan the model library.
The user's current choice overrides the following defaults: general audience; Chinese subtitles + BGM + key sound effects, no narration; duration determined by explanation needs, can be planned from 2–4 minutes; landscape 16:9; preview at lower resolution, final deliverables can be 4K60 master and 1080p60 playback version. When budget, hardware, or subject matter is unsuitable, propose specific trade-offs, do not treat 4K, 60 fps, or 3D as substitutes for quality.
Only ask additional questions when information cannot be obtained from existing materials and will change the result. Do not force re-selection of a topic that already exists. When the user asks to see a sample first, deliver the sample. When the user authorizes continuous completion, continue through internal quality checks without repeating permission requests at each stage. Production authorization does not automatically include public release or modification of external accounts.
Core Constraints of This Workflow
- Make sense from the first glance. The first second shows an object directly related to the topic; clear action occurs within the first few seconds. Raise questions using human situations, counterintuitive phenomena, or observable contradictions; technical names follow later.
- Each segment advances one understanding. Explain mechanisms using "problem → condition change → object behavior → visible result"; answer before introducing the next question. Do not replace answers with a string of questions.
- Visual metaphors must not substitute for mechanisms. The fact ledger records objects, conditions, causality, sources, simplifications, and meanings that cannot be drawn. Different research strategies should be distinguished by chapters or wording, not merged into one universal system.
- Punch points align with result frames. When the music attack point arrives, the audience has already seen contact, opening, membrane separation, or state lighting, not the animation just starting to move slowly.
- Compactness is not about deleting words. First remove slow entrances and empty waiting after reading; complex actions still require observation time. Subtitles, actions, and SFX are exported from the same timeline.
- Refinement serves understanding. Clear subject, material, layering, direction, and visible contact take priority over irrelevant particles. Mechanisms requiring front-to-back occlusion, insertion, or wrapping should use verifiable spatial structures.
- Transitions are also storyboarding. Clearly define the previous scene's objects, occlusion or shape continuity, exchange frames, and next scene's landing point. Do not wait until the whole film is complete to add uniform fades.
- Check the final file. Studio, PNG, encoded MP4, and upload preview may differ. Full decoding, frame-by-frame checks, continuous playback, and actual listening are recorded separately and cannot substitute for each other.
Executable Delivery Workflow
| Phase | Required Checkable Deliverables | Next Step Judging Basis |
|---|---|---|
| 1. Receive Input | Brief: question, audience, materials, audio, aspect ratio, scope, project root | What the audience should understand after watching; whether there are clear sources and necessary materials |
| 2. Content & Narrative | Fact Ledger, one-sentence narrative arc, question chain, first 15-second design | Key conclusions traceable; opening has action and promise; questions can be answered |
| 3. Audiovisual Storyboard | Storyboard, Asset Plan, final BGM identity, candidate cues, transition plan | Models match scientific structure; key verbs visible; intensity hierarchy clear |
| 4. Quality Sample Segment | Opening + hardest mechanism shot + one representative transition as real encoded short film | Core assets reach final quality; key actions and sound truly aligned |
| 5. Full Film Production | Editable project, unified timeline, subtitles, sound events, asset log | Each chapter clearly explained; shots flow naturally; no empty waiting or rushed reading in subtitles |
| 6. Output & Fix | Complete video, corresponding QA, revisions and differences | File, picture, sound, and version identity all pass inspection separately |
| 7. Publishing Package | Cover, title, description, tags, delivery checklist, reproduction instructions | External promises consistent with content; correct cropping and file selection for current platform |
Read the corresponding references as needed:
- Story and Evidence: Paper-to-script, hooks, question chains, subtitle dwell time, complete narrative examples.
- Visual Direction: Design system, asset selection, material and space, action recipe, transitions and clipping checks.
- Model Library and Cross-Dialogue Reuse: First discover local assets, verify structure, parts, size and license, then design shots; how to create discovery entry for new or existing projects.
- Music and Timing: Default case BGM, custom replacement, beat verification, sound effects and mixing, audiovisual alignment.
- Production, Check, and Fix: Reproducible implementation, rendering budget, final file verification, partial repair, delivery structure.
- Publishing Assets: Cover composition, platform aspect ratio, title and description, asset sources and publishing package.
- Case Study and Failed Fixes: Final result, feedback, fix reasons and applicable boundaries of "Turning Bacteria into Medicine."
- Portable Tools: Actual commands and limitations for analyzing BGM, checking timeline, full decoding and frame extraction reports.
Out-of-Box Verification and Project Initialization
When starting a new project, you can copy the Remotion + Three.js starter to the user's project, then install, preview, and render according to its instructions. Do not modify the installed skill's templates directly. It is about a 12-second dual-condition spatial action experiment used to verify the environment, motion, sound, and export pipeline; it is not a fixed intro that automatically turns any topic into a complete video.
The included Reference BGM and Source/Analysis Data provide default music input; user-provided music takes priority. The starter supports custom files; after replacement, update the analysis and cue timings. The template timeline.json is an example of independent structure, not a fixed cue table for the reference music or starter.
Before moving to a real project, run the music analysis, timeline check, and final media check from tools.md. Read warnings in reports and judge them together with visuals; do not delete scientific conditions or turn off warnings just to make the script pass. Tools cannot automatically determine whether the mechanism is correct, whether the result actually appears at the specified frame, or whether the alert sound stands out audibly; these still require visual and audio review.
Always follow the actual documentation in the repository for related tools and templates; do not guess new music timings from example values in cases. Even without a specific image model, GPU, or additional skill, this workflow can be executed with available tools. For existing Remotion projects, stick to their locked version first; when calling its new API, consult the current official documentation. If an official Remotion skill exists, it can be used together; this skill does not depend on another specific skill to understand the core workflow.
Complete These Judgments When Starting Production
Narrative: Write a specific reason to watch; pick the 3–5 questions that best form visible answers as the starting point, not fixed requirements. Decide which scene is the biggest reveal and which passages need quiet explanation.
Assets: First review local candidates, record the correspondence between each visible object and fact. Reuse when appropriate; when the scientific object does not match, essential parts are missing, or the visual effect is unsuitable, explain the reason and choose 2D, modification, or new asset. Coloring a chain does not mean the chain can move independently; an off-the-shelf model does not mean the mechanism animation is already done. First make one representative shot to the target completion level, then extend materials and actions.
Music: Can select the case BGM or use a user-customized track. First identify the actual input file, its length and version; after clipping, looping, or speed changes, re-analyze the final music. Beat detection is only a candidate; needs waveform and actual listening to confirm.
Engineering: Archive inputs, assets, source code, outputs, and QA within the project; the state of the same frame must be reproducible. Use explicit random seeds, avoid animations depending on real-time clock, playback history, or async unfinished resources.
Risk Shots: First test the full process of the hardest action. Dual keys must have real holes and sweep gaps; release must first have internal load then separate; wrapping must be continuous closure of the devourer toward the target. Specific mechanisms are based on this project's materials.
Definition of Done
Use the QA Checklist to mark each item as "checked / unchecked / not applicable" with evidence; do not fill in completion status for items not executed. Final delivery must at least include: playable video, editable project, final script/subtitles, music and cue record, cover and copy (within scope), available preview/render method, asset sources, and known limitations.
If the environment cannot actually render, clearly state how far the delivery reached, which command or resource is blocked, and keep a runnable project; do not write a preview link or "theoretically renderable" as if a generated MP4 existed. User liking, machine check pass, and platform viewing data are different pieces of evidence; do not automatically label any of them as "guaranteed high retention."