Vibe Knowledge Video

Turn knowledge into animations that are fit for purpose, convey relationships clearly, and stand up to actual playback. This skill extends the established production, tooling, and review workflows from Vibe Science Video to different domains and styles. Choose depth, color scheme, sound, and motion independently; both academic and entertaining references are optional directions. Do not promise successful generation on any topic in one shot, nor treat generated source code as a delivered video.

Confirm Purpose and Style for Each New Video

This is the starting step for the skill. First read Purpose and Style, organize the given information, then fill in gaps with 2–3 short questions:

Purpose and Audience: Where will it be used? Who will watch? What is their knowledge base? What should they understand after watching?
Style and References: Academic/teaching, popular science, entertainment, or a mix? Which features from the references should be adopted, and which not?
Pace and Sound: Relaxed/moderate/upbeat? Presence of music, narration, and sound effects? Beat-syncing and music flash: off, subtle, or pronounced?

Record any information already provided, only ask about missing items; when the user explicitly delegates the choice, note the rationale. If purpose or style is still missing, wait for answers before deciding on storyboard, visuals, and music—but you may start organizing materials and fact-checking. Do not automatically apply a style based solely on topic, platform, or the previous video; for routine revisions of the same video, reuse the already confirmed direction.

Write answers, confirmation sources, and pending items into brief. All styles must maintain factual accuracy, clear causality, and traceable sources. Bright colors can be used in scientific diagrams; restrained shots can pair with rhythmic music. No BGM, flash-off, narration-led, and 2D are allowed. Specific evaluation is based on the purpose of this video, not on a universal standard of more colors or more effects.

First, Determine the Task Stage

New project: Read Story and Evidence, Visual Direction, create brief, fact ledger, and storyboard.
Continue an existing project: First read the project's AGENTS.md, planning/brief.md, planning/project-state.md, and reference analysis index; if the project path is different, use the actual entry point. Find the final version, final audio track, timeline, and the user's last feedback. Preserve old outputs; do not overwrite final versions with historical drafts.
Deconstruct a reference video: Read Reference Analysis and Migration, record source video, time range, evidence, applicable purpose, and migration method; distinguish learned methods from already implemented reusable components.
Fix a specific issue: Read the repair section of Production, QA, and Fixes, record the time point, object, phenomenon, and decide whether to replace the audio track, re-render, or rearrange the entire video.
Only cover art or copy: Read Publishing Materials, do not initiate unnecessary video rework.

When creating a new video, redefining visuals, or adding/replacing assets, check the project's existing references, images, data, and models. When 3D candidates are needed, read assets/models/README.md, inventory.json, and existing previews; if no inventory exists, use the read-only inventory tool from Model Reuse Workflow to find real files. Choose based on subject, shot, and confirmed style, documenting files and trade-offs in Asset Plan. When only changing subtitles, mix, or publishing copy, there is no need to re-scan the model library.

Confirm sound, audience, duration, and aspect ratio for this video. 16:9, 4K60 master + 1080p60 playback version are optional delivery specs from past experience; previews can use lower resolutions. When budget, hardware, or subject matter makes them unsuitable, propose specific trade-offs; do not treat 4K, 60 fps, or 3D as substitutes for quality.

Only ask questions that cannot be answered from existing materials and that would change the outcome. Do not force re-selection of a topic if one is already provided. When the user asks for a sample first, deliver a sample; when the user authorizes continuous completion, continue through internal quality checks without pausing to request permission at each stage. Production authorization does not automatically include public release or modification of external accounts.

Core Constraints of This Workflow

Meaningful from the first frame. The first frame shows a subject relevant to the topic; a scientific video can present the research question directly, a teaching video can show a relationship to be understood, and a popular video can use a human situation or counterintuitive contradiction as an entry.
Each segment advances one understanding. Explain mechanisms as "Question → Condition change → Object behavior → Observable result"; answer before introducing the next question. Do not substitute a string of questions for answers.
Separate facts from analogies. Record objects, conditions, causality, sources, differing interpretations, and visual simplifications. Do not piece scientific research into a universal system, do not confuse time with causality in historical events, share models between mathematical figures and data. Verify claims attributed to referenced authors independently.
Audio-visual response enabled by choice. Optional three levels: constant energy, normal beats, and key reveals, each can be turned off. When beat-syncing is needed, let sound attacks correspond to visible results with preparatory actions arranged in advance; do not force every beat to flash.
Compactness is not just cutting words. First remove slow entrances and empty pauses after reading; complex actions still need observation time. Subtitles, action, and SFX are exported from the same timeline.
Refinement serves understanding. Clear subject, material, depth, direction, and visible contact take priority over unrelated particles. For mechanisms involving occlusion, insertion, or wrapping, use verifiable spatial structures.
Transitions are also storyboarding. Define the previous shot's object, occlusion or shape continuation, transition frame, and next shot's landing point. Do not add fades in/out uniformly after the whole video is finished.
Check the final file. Studio view, PNG, encoded MP4, and upload preview may differ. Decode fully, check selected frames, play continuously, and listen to audio separately; do not confuse one check for another.

Executable Delivery Workflow

The table below is for a complete new video. When the user only needs storyboard, reference analysis, cover art, or partial revision, execute and deliver only the corresponding scope; do not add unrelated stages. Do not impose music steps when there is no sound plan.

Stage	Required Verifiable Output	Decision Basis for Next Step
1. Receive Input	Brief: purpose, audience, style, pace/sound, materials, specifications, delivery scope	Key directions have confirmation basis; pending items and viewing goals are clear
2. Content & Narrative	Fact Ledger, one-sentence main line, question chain, first 15 seconds design	Key conclusions traceable; opening has action and promise; questions can be answered
3. Audio-Visual Storyboard	Storyboard, Asset Plan, sound plan, optional cues, transitions	Objects match facts; relationships visible; style and intensity suitable for purpose
4. Quality Sample	Opening + hardest mechanism shot + one representative transition as a real encoded short video	Core assets at final quality; key actions and sound are genuinely aligned
5. Full Video Production	Editable project, unified timeline, subtitles, sound events, asset records	Each chapter is explained well, shots flow naturally, subtitles have no empty waits or rushed reads
6. Output & Fixes	Complete video, corresponding QA, revision versions and differences	File, visuals, sound, version identity each pass their checks
7. Publishing Package	Cover art, title description tags, delivery checklist, reproduction instructions	External promises match the content; platform cropping and file selection are correct

Read the corresponding references as needed:

Story and Evidence: Paper-to-script, hooks, question chains, subtitle timing, complete narrative examples.
Purpose and Style: Startup questions, independent style dimensions, confirmation and revision boundaries.
Reference Analysis and Migration: Specific methods from 8 references, timecodes, evidence limits, decimation, and migration workflows for new references.
Visual Direction: Design system, asset selection, materials and space, motion recipes, transitions, and clipping checks.
Model Library & Cross-Dialogue Reuse: First discover local assets, verify structure, parts, size, and licensing, then design shots; how to establish discovery entry for new or existing projects.
Music and Timing: Optional music, envelopes and transients, result frames, mixing, and alignment.
Production, QA, and Fixes: Reproducible implementation, render budget, final file verification, partial fixes, delivery structure.
Publishing Materials: Cover composition, platform aspect ratios, title and description, asset sources, publishing package.
Case Studies & Failed Fixes: The final result, feedback, fix rationale, and applicability limits for "Turning Bacteria into Medicine."
Portable Tools: Actual commands and limitations for analyzing BGM, checking timelines, full decoding, and decimation reports.

Onboarding Verification and Project Initiation

When creating a new project, you can copy the Remotion + Three.js starter into the user's project, then follow its instructions to install, preview, and render. Do not directly modify templates of an already installed skill. It is a ~12-second dual-condition spatial motion experiment used to verify the environment, motion, sound, and export pipeline; it is not a fixed intro that automatically turns any topic into a full video.

The Reference Music and Source Record in the package preserve optional test inputs from the original technical experiment; do not decide the soundtrack for a new video. The starter supports custom files and explicit silence; after changing music, update the analysis and event timings. The template timeline timeline.json is an example of a standalone structure, not a fixed beat-sync table for the reference music or starter.

Run tools.md for music analysis, timeline checks, and final media checks on real projects. Read the warnings in the reports and judge based on visuals; do not remove scientific conditions or turn off warnings just to make the script pass. The tools cannot automatically determine if a mechanism is correct, if a result actually appears at the specified frame, or if a sound effect is perceptually prominent; these still require visual and audio review.

Related tools and templates should follow the actual instructions of the repository; do not guess new music timings from example case values. Even without a specific image model, GPU, or additional skill, you can execute this workflow with the tools available. For existing Remotion projects, prioritize using their locked version; when calling new APIs, consult the current official documentation. If an official Remotion skill already exists, it can be used in conjunction; this skill does not depend on another specific skill to understand the core workflow.

Make These Judgments Before Starting Production

Narrative: Write a specific reason to watch; pick 3–5 questions that best form visible answers as starting points, not fixed requirements. Decide which scene is the big reveal and which sections need quiet explanation.

Assets: First inventory local candidates, record the correspondence between each visible object and a fact. Reuse when appropriate; when the object, era, structure, parts, or visual effect is unsuitable, explain why and choose 2D, modified, or new assets. Coloring a chain does not mean the chain can move independently; an existing model does not mean the mechanism animation is already done. First deliver one representative shot at target quality, then propagate materials and motion.

Sound: Confirm choice of music, narration, sound effects, or silence for this video. When using music, record the actual file, length, and version; re-analyze after editing, looping, or time-stretching. Detecting transients is not the same as confirming drum hits; the reference mix is not just a BGM track.

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 relying on the real-time clock, playback history, or resources that are not yet loaded asynchronously.

Risk Shots: First test the full process of the hardest-to-explain mechanism. Chart counts share data with curves; map labels follow correct locations; insert shots return to the main shot preserving its state; when spatial motion is involved, check holes, rotating sweeps, internal/external structures, and contact. Specific relationships are based on this project's materials.

Definition of Done

After each major delivery or user feedback, update planning/project-state.md: final files, actual checks, pending checks, user confirmed / pending evaluation, asset and reference entry points, next steps. Initialization and tool setup provide project continuation entry points, see the tool manual. Write stable methods into reference records; keep the duration, frame rate, color scheme, and preferences of specific works within their scope of applicability; record status separately for samples, complete videos, and reusable components.

For videos without sound, the sound items can be marked as N/A; do not create sound peaks or impose music for the sake of checks. Reference videos and their audio tracks are not provided with this package; only transferable analysis methods are available; the BGM of the original case study indicates its source and licensing scope separately.

Use the QA Checklist to mark "Checked / Not Checked / N/A" along with evidence; do not fill in completed status for actions not executed. A complete video task delivers a playable video, editable project, final script/subtitles, actual sound and event recordings, cover art and copy within scope, preview/render method, asset sources, and known limitations; for storyboard, analysis, or partial revision only, deliver the corresponding results as requested.

If the environment cannot actually render, clearly state up to which step was reached, which command or resource is blocked, and preserve the runnable project; do not write a preview link or "theoretically renderable" as a generated MP4. The user's liking of the work, machine checks passed, and platform viewing data are different pieces of evidence; do not automatically write any of them as "guaranteed high retention."

vibe-knowledge-video