Communitygithub.com

Vibe Science Video

Create or refine Vibe science videos based on papers, scientific mechanisms, or knowledge questions, delivering playable final videos, editable projects, and publishing assets. Suitable for tasks requiring compelling openings, explainable 2D/3D animations, BGM sync, subtitle timing, refined transitions, and audiovisual verification; supports from topic selection to final output, as well as fixing existing videos by timestamp.

What is Vibe Science Video?

This skill is designed for developers and AI agent users who need to produce high-quality science animation videos grounded in research papers, scientific mechanisms, or knowledge queries. It guides the user through a complete workflow: receiving inputs, building content and narrative, creating audiovisual storyboards, producing a quality sample segment, full video production, output and fixes, and finally a publishing package. The skill emphasizes creating videos that are engaging from the first second, with clear causal explanations, and verifiable quality through a detailed QA checklist. It supports multiple platforms like Claude Code, Cursor, and Codex by providing reproducible tools and templates, such as a Remotion + Three.js starter project for environment validation. Key constraints include making the first second meaningful, advancing understanding per segment, using visual metaphors that don't replace mechanisms, aligning punch points with result frames, and ensuring outgoing files are verified. The workflow avoids over-committing to unplayable content and prioritizes reusing local assets, documenting all decisions in structured templates like the fact ledger, storyboard, and asset plan.

Works with~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/S-Fan-ZJU/vibe-science-video/tree/HEAD/skills/vibe-science-video

Ask in your favorite AI

Open a new chat with this agent skill pre-loaded.

Documentation

What does Vibe Science Video do?

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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

PhaseRequired Checkable DeliverablesNext Step Judging Basis
1. Receive InputBrief: question, audience, materials, audio, aspect ratio, scope, project rootWhat the audience should understand after watching; whether there are clear sources and necessary materials
2. Content & NarrativeFact Ledger, one-sentence narrative arc, question chain, first 15-second designKey conclusions traceable; opening has action and promise; questions can be answered
3. Audiovisual StoryboardStoryboard, Asset Plan, final BGM identity, candidate cues, transition planModels match scientific structure; key verbs visible; intensity hierarchy clear
4. Quality Sample SegmentOpening + hardest mechanism shot + one representative transition as real encoded short filmCore assets reach final quality; key actions and sound truly aligned
5. Full Film ProductionEditable project, unified timeline, subtitles, sound events, asset logEach chapter clearly explained; shots flow naturally; no empty waiting or rushed reading in subtitles
6. Output & FixComplete video, corresponding QA, revisions and differencesFile, picture, sound, and version identity all pass inspection separately
7. Publishing PackageCover, title, description, tags, delivery checklist, reproduction instructionsExternal 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."

Related Skills