explainer-video

Knowledge explainer video

A good explainer video has no standard shape. Explaining clearly why the sky is blue could be a small experiment you can do at home, a journey following a beam of sunlight through the atmosphere, or first putting the misconception "the sky reflects the sea" on the table and then knocking it down; explaining a piece of breaking news might star a few live-action clips plus a comparison table that grows along with the narration, without a single animation. Whether it's good comes down to one thing: did the audience actually understand, were they willing to watch to the end, and can they tell someone else about it. This skill records the questions worth thinking about when making explainers, the common techniques, and the pitfalls that are easy to fall into, to help you make your own judgments well: the structures, styles, and numbers in it are starting points and references—when this episode's content and audience call for a different approach, follow your own judgment, and say a sentence at delivery about why you chose it.

For production steps like building the video, generating visuals, recording narration, mixing audio, and exporting, follow video-production and narration; they are not repeated here. Before starting, use skills_read to read video-production; when writing the script and recording narration, use skills_read to read narration。

"The thing itself is the explanation," visuals and readings driven by the same set of facts, and reviewing these lines of thinking first at a magnified level like a film reviewer—with reference to Ryan's Anatomy skill (https://github.com/wheresryan22/anatomy），按线性视频与大众观众改写。

1. What counts as explaining well

Use these to test ideas, scripts, and visuals; no need to apply them one by one:

Start from the audience. Explain what they are interested in, care about, and can use, not what this topic "should" cover. When no audience is specified, default to an intelligent ordinary person with no background knowledge (roughly high school graduate level): they understand new things by recognizing familiar ones, so examples, subjects, and wording must all be things they have seen; if an audience is specified, all of these change accordingly.
Make them want to keep listening from the first sentence. It relates to the viewers themselves and quickly establishes a question whose answer they want to know.
Connect to something they have seen. For an unfamiliar concept, first find something the audience has seen to connect it to.
One step at a time. Introduce only one new thing at a time; each step stands on the previous one.
Answer what the audience really wants to ask. Including when the answer is "no," "not sure," or "not possible yet."
They gain something from watching. Viewers can retell it to someone else in their own words.
The visuals make the argument themselves. Make the invisible visible; the best visual is a thing that moves, whose operation is the point this episode is making, with the narration merely operating it. Two distances must both work: shrunk to a phone-sized thumbnail, a glance tells you what it's about; paused on any frame, everything in the image is complete and correct.
Facts must be accurate. Simplification is allowed; being wrong is not; the numbers on screen, the quantities in animations, and the numbers in the narration come from the same set of facts.

2. Figure out what to explain

Extract from the conversation: topic, materials or news, audience, what they should be able to do after watching, duration, aspect ratio, final language, style preference. Infer whatever can be inferred instead of asking; for anything missing, follow video-production Section 1 to combine them into one round of questions. If no duration is given, set it by content: one point explained thoroughly is usually one to two minutes; a complete concept takes a few minutes. If it doesn't fit, cut first rather than speaking faster. If the user relaxes the duration ("no time limit"), go by what the content needs and stop advising cuts based on the usual length.
For anything involving news, products, data, or policy, read primary sources (official announcements, papers, documentation); use secondary reporting only to find leads; if the user provided materials, those take precedence. Record the source of every number, date, and quotation used; they will be needed for the deliverable and the body text. On balancing verification and simplification: use skills_read to read this skill's references/script.md Section 1.
Get the real numbers and organize them into a fact table: when explaining a mechanism, how many, how fast, how big, where the threshold is, when it triggers; when explaining an event, when it happened, who said it, how much. Each entry carries its source and what simplifications were made. This table then feeds the script, the visuals, and the publish copy (Section 5), so the three places don't each keep their own set of numbers. For things the materials don't provide but the audience will want to know, make a rough estimate yourself per references/script.md Section 3.1 and label it as a rough estimate.
Report cost by tier: a short video explaining one point thoroughly, just make it; a complete concept with generated characters and scenes, first state the rough workload; for 3D, heavy live-action editing, or two languages and two aspect ratios, first tell the user the cost (bake time, quota, waiting), propose a smaller version that keeps the core, and only make the big one if the user chooses it. In every tier, first make a watchable opening sample (video-production Section 5), then go deeper.

3. First decide the form of this episode

Before writing, answer a few questions; the form grows out of the answers, not from the previous episode:

What kind of thing is this episode about? How a mechanism works, something that just happened, a common misconception, the history of a discovery, a set of data and trends, a method or practice, the difference between a few things. Different kinds call for different approaches, subjects, and visual sources.
What should the audience be able to do after watching? Restate an idea, understand a piece of news, make a judgment, try it once. It determines how deep to go and where to end.
What is the subject that runs through the whole video? A movable model, something from live footage plus an animated reenactment, a diagram that comes with the materials, two things side by side, an experiment, a timeline, one person's day... For how to choose the subject, see Section 5.
What mainly carries the visuals? Code-drawn models and diagrams, generated illustrations and scenes, live footage and screenshots, original images from the materials, 3D, slide-style key points. Decide by subject and materials; not every episode is animation.

For the same big topic, the answers often differ: explaining how the attention mechanism computes—the subject is a movable model, and the audience watches it operate step by step; covering what a company released—the subject is the thing in the demo, live footage proves it really happened, animation explains only one or two "whys," then answers "what does this have to do with me"; asking "will it replace a certain profession"—there's no mechanism to draw, so the subject can be one person's day, or a comparison table that grows alongside the narration. The workflow follows the form: for code-driven visuals, segment the script per Section 6; for live-action-driven, follow references/footage.md and video-production; slide-style, screenshot-heavy footage video-production shot by shot. When several episodes of the same series run back to back, don't let every episode land on the same form.

4. Find the approach, write the script

Ask the questions on the audience's behalf first. Put yourself in the audience's position, list the questions they would ask, and pick out the few they most want answered and whose answers are most specific; answer everything the user named. This list is a research tool: it decides what this episode answers and what it doesn't, and it's worth showing to the user; it doesn't dictate structure: it can become a Q&A-style video, or the answers can be buried in a journey, an experiment, or a story.
Then choose the approach. The approach grows out of the content: start from a misconception, follow one thing on a journey, a small experiment, a story of discovery, a chain of questions…references/script.md Section 3 lists several common ones; you can mix them or strike out on your own; Section 3.1 covers a few tools for making an argument convincing (elimination, building up step by step, doing a rough calculation yourself…), chosen to fit the question rather than laid out as a fixed paragraph template. When several episodes of the same series run back to back, don't let every episode land on the same convenient structure.
Narration is the hand that operates the subject. Once the subject is set, every line of narration does one thing to it: add one, take one away, cut it open, change the angle, slow it down, draw the wrong version and then reject it. As you write, note next to each line the subject's state at that moment; the visual beat comes from there. If a line of narration has no action on the subject, it's probably being told beside the video rather than in it.
Lay out the script line by line, one visual beat per line; estimate length by the measured speaking rate in narration Section 1, and for the first draft read at skills_read for baocut-catalog-voice-language-rates. For how to write hooks, explanation, and read-aloud lines: use skills_read to read Sections 2–6 of this skill's references/script.md .
Show the user the script before voiceover: the narration, estimated duration, form and subject, which audience question each section aims to answer, sources, and what simplifications were made. When visuals are possible, attach a style sample, a cover, and a few sample frames taken at the estimated timestamps: from text alone, users struggle to voice specific feedback like “the opening is too hard” or “too few examples.” Voiceover and visuals both cost time and quota, and any script change means redoing them; when the user has said “just make it,” don't stop—attach these to the delivery.
The user adds or makes small changes after “just make it”(add a section, change a few lines): redo only the affected parts (re-record, re-align, re-import those sections), finish it directly, and don't stop again to confirm; if the change touches the approach, structure, or style, say so first and then do it.

5. Visuals: one subject running through the whole video

General visual practices (choosing a style, cover and layout, how heavy the effects should be, using generated images and code together, vertical vs. horizontal) are in the visual guidelines at video-production : use skills_read to read video-production, following its Section 2 “Visual design” point by point. For explainer videos, think a few things through on top of that:

The thing itself is the explanation. Find a concrete object for this episode that viewers can recognize, whose way of working corresponds one-to-one with the concept being explained: rate limiting is a coin slot that automatically refills coins, and caching is a "last computed" sticky note stuck on a drawer. The narrator operates it, the viewer watches it change, and the reasoning lives in the picture rather than relying on labels beside it to explain. Two common failures: too abstract (boxes, arrows, labels, looking like nothing), too decorative (mascots, stickers, particles that look good but carry no logic). How to choose the subject, how to test it, and what to do when there is no mechanism to draw: use skills_read Read this skill's references/subject.md。
One set of facts drives everything: the numbers on screen, the quantities in the animation (how many, how fast, how big), and the numbers the narrator says all come from the fact table in Section 2; in code, write the mechanism as a small pure function, and derive the readings, animation, and pacing from it, so that at the moment the narrator says that number, that number is on screen. Say so when a number is illustrative.
Prefer diagrams that come with the source material: if the source already has a diagram that lays out the reasoning clearly (a flowchart, a layered diagram, a timeline), use its structure as the main line for that part, redraw the visuals according to it, and have the explanation follow it step by step. Use the subject only to help viewers connect one or two unfamiliar links in it, and do not force the whole segment into it; when the subject and the original diagram tell things in a different order, follow the original diagram. If the user provided the original text's accompanying images, follow the original images first for composition (stacked vertically or arranged horizontally, who comes first and who comes after).
Light up whatever is being mentioned: one focus per screen, and only one thing lights up at a time; one color represents only one thing throughout the whole piece (one each for right, wrong, and key numbers). The text on screen is a distillation of the narration; leave full sentences to the subtitles. A segmented piece can keep a small header in the corner ("Part 2 | ...", "Question 2 | ...") so viewers always know where they are.
Draw the misconception, then overturn it: first draw the intuitive wrong answer carefully, then cancel it with an action (sweep it away, cross it out, shatter it); this is more memorable than just saying it.
Detail comes from structure, not decoration: a picture is rich because everything in it is making a point (the subject's parts, readings, comparison objects), not because of particles, glows, and borders; all changes have easing, events have rise and fall, and nothing appears or disappears out of thin air within a single frame; reserve heavy impact for the most critical conclusion only, landing at the moment the narrator says that word.
Metaphors, characters, and stickers as needed: when the subject already contains characters and objects (a little photon, a coin, a guide), use image generation to draw them as a set of stickers, and swap poses, move, and deform them in code, while diagrams, numbers, and text to be read are still drawn by code; when the subject is a machine, a table, or live-action footage, do not add them. One guide character per episode is enough.
Style comes from the topic and the audience; do not let several consecutive episodes in the same series fall into the same handy style; and do not treat any one way of drawing (isometric instruments, glowing on black, flat infographics) as the default for every episode.
The topic is three-dimensional(how things move, which way forces point, what is hidden inside): use 3D; one subject carries the whole piece, give invisible things a fixed way of being drawn, explain the inside with in-place perspective, and draw text and numbers on a 2D layer above. For the approach and common pitfalls, use skills_read Read this skill's references/3d.md。

6. Production

Follow video-production Sections 4-6. Commonly used for explainer videos:

When an entire shot and segment are drawn by code, follow video-production Section 5, "Code Visuals": read its code-scene details (packaged import by segment, determinism, fonts and layers); generated characters, objects and backgrounds go into the code package and come to life. Short captions, keywords and big numbers follow motion-graphics。
When covering real products, people, events or places, use real footage, screenshots or the user's own material; generated images only depict metaphors, diagrams and imagined scenes, and never pose as real. When you have the original footage, live-action proves "it really happened" and animation explains "why": how work is divided and connected (look first then ask, watch it again after explaining, readings as evidence, the subject's own voice against narration with room to breathe), live-action joined into blocks with few cuts back and forth, full-screen cut versus picture-in-picture, transitions only at the boundary between animation and live-action, how to place old footage, labeling sources; use skills_read Read this skill's references/footage.md。
Write the subject's drawing as a reusable part: centered on the origin, with scaling; state and text passed in by the caller, so the same subject can be reused across shots, aspect ratios and language versions.
Beats follow the real voice: once the narration is measured and aligned to get word timings, the entrance moment of on-screen elements is the moment the corresponding word is spoken, not an estimated proportion; after re-recording, re-time by the new word timings. After edits, check that the keyword each beat uses is still in its corresponding narration line (changing "it is" to "it's" or rephrasing will break the match); report and fix mismatches, and don't quietly fall back to estimated positions.
Build and revise by segment: record narration by segment, align by segment, cut code visuals into per-scene packages, and keep each segment's results. When revising or inserting a segment, redo only that segment (re-record, re-align, re-import that package); unchanged segments keep their original recordings, word timings and visuals, with no full re-render. When code visuals dominate and a command-line environment is available, use this skill's scripts/: the five steps of voiceover, alignment, packaging, placing on the timeline (when a segment gets longer or shorter, shift later clips together with their subtitles) and building subtitles are all written out, plus two optional steps for preview page configuration and live-action clips and watermarks; content-related settings live in one config file, and it works once copied into the project; for usage, config fields and how to revise a segment, use skills_read Read this skill's references/production-scripts.md. For other forms, follow video-production 's steps manually.
Pronunciation check: use transcribe to transcribe the narration material (model selection as in narration Section 4: the one with word timings at native, the one that accepts prompts; set the language assertion to the script's language and put proper nouns in the prompt), and compare the recognized words with the script line by line. Differences in homophones, punctuation and number formatting are the recognizer's issue; mismatches on proper nouns, foreign words, numbers and polyphonic characters may be real misreadings: change the script to the pronounced spelling (narration Section 2) or re-record that line with a different seed, then check again. To transcribe again with a second recognizer, first save the narration material as a file with artifacts_save, then transcribe with file and noVideo(transcript only, no new video, no replacing the transcript used for alignment). For words that differ across two or three transcriptions, note the timestamps in the delivery and ask the user to listen. If it was read correctly and only the characters were misrecognized (homophones, proper noun spellings), before building subtitles use edits_apply's updateWords to change this transcript back to the script's spelling (pass only the changed words; timings stay unchanged; for the method use skills_read to read baocut-catalog-subtitles 's "polish write-back"), and build subtitles from the corrected transcript; don't put recognized wrong characters on screen.
Show the user a moving picture before baking: after the narration and alignment are set and before importing, make each segment into a local preview page for the user to see (for the method, see video-production code scene details section 7 "Self-check": use skills_read to read video-production, then read the details according to its section 5 "Code Picture" item). Comments on explainer videos mostly concern whether a certain segment is explained clearly; fixing it on the page before baking is much faster than fixing it after the whole video is baked. When the user has said "just do it", do it; attach the preview page to the delivery.
The first frame is the cover(general rule of the main skill): at 0 seconds the title, one viewer question, and the subject of this episode are all in place, and the title is legible even when shrunk to a small thumbnail on a phone. Subtitles by default appear about half a second before the first character of each line (subtitle style's displayTiming.leadIn); when the narration starts within the first second, the first subtitle will press onto the cover: either keep the cover static for about 1 second before the narration starts, or move the first narration line later until the title is read, or use edits_apply's trimItem to trim the start of the subtitle segment that begins at 0 seconds to the first character (scripts/captions.mjs will do it).
Credits and brandingonly do what the user gave: fixed intro, outro voice-over, corner badge, or watermark—copy them word for word and form for form as the user gave them; do not invent column names, slogans, or watermarks yourself. BaoCut has no tool to automatically insert intro/outro voice-over or an end card: write fixed voice-over into the script as a fixed segment, and synthesize it yourself and make the end card yourself.

7. Watch it once like a reviewer

First export a preview and watch it once at normal speed, as if you were a viewer seeing it for the first time and not knowing the answers: which line did you not follow, at which moment did you not know where to look, which number did you not know what it was. Then use compositions_preview to grab frames by segment and stitch them together to watch frame by frame: compare each frame with what you want the viewer to see and read at that moment, and ask "can the viewer understand this second", not just whether it looks good. videos_frames grabs the source frames of the topmost segments; subtitles and overlay elements are not included (the result's composited is false): to check subtitle positions and whether they press on text in the picture, use export to export a short section with purpose: preview and range , and extract frames from the exported file to look at. After a round of changes, compare the same spot side by side with the previous round's frame, to confirm it is fixed and nothing else was broken; measured things (duration, character timings) do not count as watched; only what has been watched gets written as "watched". Common problems in explainer videos, for you to compare against:

Incomplete cover: the title, question, or subject is not in place, and it is illegible when shrunk.
Text too close to the background color: white or light text on a light background, dark text on a dark background, semi-transparent text smeared on the background.
Empty cards, cells, and bars; when a group that appears in sequence has all appeared, the last frame is missing a few items.
Text too small, outside the safe area, pressing on subtitles; vertical format crowded in the upper half with the lower half empty.
Numbers do not match the script or the source (for rolling numbers, look at the final value); the quantity in the picture does not match the number the narration says (says "five" but draws eight).
Old content flashes when switching segments; a picture stays still for a long time and viewers start to drift; things appear out of nowhere within one frame.
Numbers that appear on screen (parameter count, layer count, percentage) are not explained by the narration as to what they are.
Two or three things are lit at the same moment and you do not know where to look; the same color means different things in different segments.
The subject only appears at the beginning and the end, and the middle section is replaced by boxes and arrows.
The subtitle breaks a word in the middle ("fix pro|gram crash"): the cut is already made at word boundaries (Latin-alphabet words go as whole words, Chinese is segmented by dictionary, and when the width limit is reached it extends to the end of the word); what still gets broken are proper nouns and new words the dictionary doesn't know, or words too long to fit in the remaining space. If you see this, change the line break for that entry, or add a comma before that word in the transcript (updateWords, timing unchanged) and rebuild the subtitles, or shorten that sentence in the script.
Subtitles burned into the picture that exceed one line (about 9–10 Chinese characters for vertical) will wrap to two lines: the break point first looks for punctuation, spaces and Chinese word boundaries, and lines are made as even in length as possible; words the dictionary doesn't know (proper nouns, new words) may still be split. export's maxCharsPerLine only controls the subtitle file, not the picture. If you want each entry to occupy just one line, add punctuation to long sentences in the transcript, or rephrase them.
Text, watermarks, distorted hands and faces appear in generated images; the same character doesn't look consistent from shot to shot; matting carries a fringe of the background color.
Too many impact effects, so the real conclusion doesn't stand out.
Live-action footage covers the diagrams that should be seen; source labels press onto the subject or subtitles; when cutting to live action, viewers can't tell it's the same thing as in the animation. For common problems with 3D visuals, see references/3d.md Section 5.
Versions in another language have source-language text mixed in, and long words are truncated when they exceed the width.
It looks like it came from the same mold as the previous episode.

For read-back and the three-column report, see video-production Section 7.

8. Publishing copy

The publishing draft is one of the deliverables (Section 9): title, description, body and sources written in a single Markdown file, and not provided only if the user says not to. Read the title and description with skills_read and write them with titles-and-description ; read the body with skills_read and write it with video-blog(author's perspective). A few points for explainer videos:

TitleGive one recommended title, with at most two alternates: say clearly what this episode covers, then leave a question or contrast that makes people want to click, usually the cover headline plus a viewer's question; put keywords early. Conclusions with qualifying conditions are not stated in the title as universal facts.
DescriptionThe first sentence must stand on its own (many platforms show only the first one or two lines): the hook → what this episode makes clear → which questions it answers → a one-sentence takeaway; write for people who haven't watched yet, without spoiling all the answers; put sources at the end of the body. Word count depends on the publishing platform; if the user doesn't specify, about 300 Chinese characters or about 100 English words.
BodyUse the narration as the base draft so that people who haven't watched the video get the same information: rewrite references to the visuals, and put information that appears only on screen (numbers in charts, comparison results) into words; change read-aloud phrasings back to written style; remove the fixed opening and closing spoken lines; add subheadings by content, and use the viewers' questions directly as subheadings for the Q&A part; qualifying conditions simplified in the video may be written out in full, but must not contradict the video; list sources at the end (name, publisher, date, link).

9. Delivery

Each version delivers three things, and one is withheld only if the user says not to include it:

Final video: the exported video file, with the path taken from the outputs in the export result path。
Cover image: simply frame 0 of the final video (Section 6), with the same aspect ratio and dimensions as the final video, saved as a PNG next to the final video, with the filename being the final video's name plus "-cover" (English version adds -cover). When frame 0 is a code screen, use compositions_preview to get the frame at 0 seconds from the first code package: lossless, with clear edges on text and seals; do not capture it from the exported final video, which is compressed. When the opening is live-action footage or a screenshot, take frame 0 from the final video. If it exceeds 2 MB, save a separate JPG copy (the thumbnail limit on many platforms is 2 MB). Embed the cover image in the reply for the user to see.
Publishing draft: the title written per Section 8 (recommend one, with at most two alternates), description, body text, and sources, as one Markdown file placed together with the final video; also paste the title and description into the reply.

Then write the task summary per the main skill's "Delivery" section. Viewers of explainer videos rely on these to judge whether the video can be published: which viewer questions it answered, where the facts came from (including clearly noting materials provided by the user), what simplifications were made, and whether there are any unverified claims (if so, list which sentence separately); then describe the chosen format, presentation approach, subject and style, why these were chosen, which visuals were generated, whose live-action footage was used, and how long each segment is. When pronunciation is inferred only from transcription, state clearly that "no human has listened to it," and list the words and timestamps that remain doubtful. In the publishing draft, state the word count of the body text.

10. Versions in another language or aspect ratio

When the user wants two versions (for example, one vertical and one horizontal, or two languages):

First make the main version(the language and aspect ratio in the brief), deliver it, and after the user confirms, make the other version; carry any changes the user requests on the main version into the other version. If the user says from the start to make both versions directly, follow the user's instruction.
Another language must be rewritten for viewers of that language, not translated sentence by sentence: the facts, conclusions, questions answered, and subject stay the same; the hook, local examples, and sentence rhythm are rewritten for viewers of that language, and content meaningful only to the original-language audience is removed or replaced with an equivalent (replacements must likewise be verified). For the writing approach and self-check, read references/script.md Section 7.
Another aspect ratio requires recomposing the shots; visuals for another language must also be rearranged (different character widths, labels replaced with short words). Lay out per the two sections on vertical and horizontal versions and on another language in video-production the visual guidelines.
Shared by both versions: style, the subject's drawing method and textures, voice and tone specifications, fact table, and sources. Build the other version as a new video; do not modify the main version.
The other version likewise delivers its own final video, cover image, and publishing draft (Section 9), with the text on the cover rearranged in that language; when delivering, explain how it differs from the main version (examples changed, content removed or added).