Communitygithub.com

zxd-666/video-flow

从主题或文稿制作中文讲解视频:联网核实并确认文案、声音形式与视觉风格,再用代码制作配乐字幕版或真人演说 API 配音版。适用于资讯、产品与技术讲解;不用于 AI 生成视频镜头。

video-flow 是什么?

video-flow is a Claude Code agent skill that 从主题或文稿制作中文讲解视频:联网核实并确认文案、声音形式与视觉风格,再用代码制作配乐字幕版或真人演说 API 配音版。适用于资讯、产品与技术讲解;不用于 AI 生成视频镜头。.

兼容平台✓Claude Code~Codex CLI~Cursor
npx skills add zxd-666/video-flow

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

Video Flow|Code-Based Explainer Video

Turn any topic into a factual, easy-to-understand Chinese explainer video. The final output can be either a music-and-subtitle version or an API-dubbed real-speech narration. Use code (HTML/CSS/SVG/Canvas/GSAP) to lay out typography, charts, flow diagrams, and animations. On-demand use of source-attributed web images, user-provided assets, or AI-generated static images is allowed. The final visuals are orchestrated and rendered by code—no AI-generated video footage.

Three-Step Workflow: Script and Production Choices Are Gate Points

  1. Research and Write. Given only a topic, begin researching. Infer the audience, duration, aspect ratio, and expression style (revocable); only ask clarifying questions when key divergences would change the script. Follow Research and Script to search for the latest verifiable information. Promptly save original webpage screenshots, images, and their sources that may appear in the final video. Write a complete content script, source mappings, and brief visual intent. Deliver the script and key visual evidence directory to the user for review.
  2. Confirm Script, Voice Format, and Visual Style. During review, ask the user to choose between "Music + Subtitles" or "Real Speech (API Dubbing)", and one of the three named visual styles. If the user has already specified these, only ask for the missing items. Proceed to production only after the user confirms the script content; a single "ok" confirms the script, but do not choose the voice format or style on the user's behalf if not explicitly stated. Before confirmation, keep research screenshots and materials, but do not generate dubbing, AI images, animation projects, or videos.
  3. Produce and Deliver Directly Based on the Chosen Plan. For the music + subtitle version, convert the confirmed content into short sentences suitable for screen reading, and arrange visuals against reading rhythm and music beats. For the real-speech version, call the voice generation API, and arrange visuals and subtitles around the final audio. Follow Production and QA to write a director's brief and a unified timeline, produce, render, and check the final output. Deliver MP4, subtitles or screen copy, editable project files, and an asset/source list. Confirming the script and plan authorizes local production, not publishing, purchasing services, or using unauthorized personal voice samples.

Visual Styles Offered for Review

  • Clean Documentary: Light backgrounds with white space, clear information typography, real screenshots, and restrained motion effects. Suitable for news, product introductions, and evidence displays.
  • Paper Collage: Warm paper textures, collage/split motion of images and objects. Suitable for case studies, creative content, or concrete topics.
  • Dark Tech Desk: Dark interface, flow lines with local zoom, real tool/code screenshots. Suitable for technical and open-source projects.

Provide a short description of each and a recommendation for the current topic; let the user choose a style. Users can also specify their own style or combination. Once selected, go directly to shot-by-shot production without pre-making three style preview videos. Style previews only if the user explicitly requests them.

When the topic is clear, proceed directly to Step 1 without making the full production brief a barrier to start. User-specified duration, platform, voice, and style take priority; unspecified items are written with default assumptions in the script delivery, allowing the user to modify them together. Do not copy "user long-term preferences" claimed by other skills.

Research and Script Completion Criteria

  • Verify recent, volatile, niche, or contested facts online. Prioritize original announcements, official docs, papers, raw data tables, or event parties; compare publication time with event time. Search summaries do not count as sources. Use existing knowledge to organize questions and explain stable contexts, not as a substitute for evidence of recent facts.
  • While reviewing original materials, simultaneously select real visuals that help the audience see the evidence, such as announcement titles and dates, repository file lists, key original text, product actual interfaces, or data charts. Follow Research and Script to save original screenshots/files and evidence indexes, recording URLs, access times, corresponding paragraphs, available use, and display methods. Preserve especially when pages may change or disappear. Only treat screenshots as representations of the source at that moment, not as independent fact verification. When preservation fails, record the exact entry point and reason.
  • Content script has stable paragraph IDs. For the spoken version, prepare a full word-for-word script that can be read aloud. For music + subtitles, extract screen-ready short sentences from it; do not cram long paragraphs into the frame. Each key fact can be traced back to a specific source; separate facts, inferences, and opinions. For numbers, cases, and effects lacking evidence, do not write them as definite results.
  • For short videos, start with one core judgment. Connect the opening emotional hook, middle explanation, and closing practical insight into a single narrative line; cut side branches when information is heavy. Do not make one video a directory of knowledge points. Plan the hook for the first 2 seconds and mid-roll attention recapture according to the target platform; rhythm is driven by content.
  • The ending must give the audience a practical takeaway. Clearly state where to find the original information, which parts to look at first, and provide 1–3 directly relevant inspirations, judgment questions, or actionable checks. Put searchable material names/paths and essential direct links outside the script and in the ending frame plan; do not end with vague summaries like "worth watching" or "stay tuned".
  • Label estimated durations as estimates. For the real-speech version, actual rhythm is based on the API-generated audio; for the music-subtitle version, based on the final screen copy reading time and music beats. Keep citations and visual notes outside the script; do not mix them into the final narration copy.
  • Deliver for review a script that lets the user directly judge content accuracy and expression suitability, along with the three named voice formats and visual styles for selection. Stop here if the user has not confirmed the script.

Production Completion Criteria

  • For the "Music + Subtitles" option, use background music and sound effects aligned with visual actions; do not generate voice. Subtitles are on-screen explainer text aligned with readability and music/action. For the "Real Speech (API Dubbing)" option, call an available and authorized voice generation API to produce natural voiceover narration; optional low-volume background music may be added. "Real speech" refers to voice performance, does not require a real person on screen, and does not default to replicating the user's timbre. Do not replace with system TTS or pure music. Listen to the emotional hook and technical terms first, then finalize the sound and timeline. Do not clone personal voices without authorization, and do not activate paid services on your own. When the user chooses MiniMax timbre replication and voice generation, follow MiniMax Voice Integration to verify account entitlements, timbre authorization, and billing. Use the final audio to measure duration. Subtitles are from the confirmed script; revise and verify if the actual speech changes. Clearly label word-level timing as measured, ASR-aligned, or estimated; do not pass off estimations as precise synchronization.
  • Paid API Keys must NOT be written in plain text into this skill's SKILL.md, references/, agents/, scripts/, or any other files, nor into video projects, commands, logs, or delivery packages. When calling, only read from configured secure credential sources; record only service, model, timbre, and non-sensitive parameters; do not record key values.
  • Every frame must carry an explanatory task. Plan visible objects, actions, and information changes according to script paragraphs: when talking about a request entering, show the request flow; when talking about scheduling, show allocation; when talking about limits, show boundaries; when talking about data entry points, make paths readable. A unified visual language does not mean repeated use of the same medium-shot animations or cards. Favor code-drawn text, numbers, structures, charts, UI, and comparisons; static images only when they explain better than code visuals. Record external asset sources and usage conditions; do not use watermarked images as final deliverables.
  • Produce directly according to the visual style chosen by the user during review; do not make "three-style preview" a gate. If the user specifies their own style, follow that. Subtitles or on-screen explainer text are part of visual design; need separate consideration of hierarchy, line breaks, dwell time, and relationship with the main frame on a mobile screen.
  • After confirming script and plan, write a short director's brief: core judgment's rise and fall, visual motif, per-shot action and its explanatory relationship, shot/subtitle/sound cues. For the spoken version, use the final voiceover audio to set a unified timeline; for the music+subtitle version, set the timeline based on screen reading duration and music beats. Real screenshots are prioritized for moments of "evidence appearance"; processes and mechanisms are explained with code animations. Within the same visual language, switch objects, scales, and perspectives to avoid mid-roll card repetition. Follow Production and QA to review the actual output.
  • Prioritize using the locally available huashu-motion CLI as the code motion and rendering backend; first check its capabilities, then produce and verify according to its project contracts. If unavailable, explain the gap and choose a verifiable code rendering path in the current environment; do not claim video output without actual rendering. Do not hardcode backend versions or absolute paths into the project.
  • After rendering, check the real MP4 for audio, duration, aspect ratio, subtitle readability, key frames, and scene transitions. In addition to automatic checks, actually watch or spot-check key time windows. Save editable source files, music or voiceover audio, subtitles/screen copy, and asset mappings. Mark checks that were not run as "unverified".

Rework Boundaries

When modifying already-confirmed facts or content, first show the changes and affected paragraphs, obtain user confirmation of the new script, then redo the corresponding audio or screen copy, subtitles, and shots. When only changing visuals, pacing, or sound mixing, rework the affected segments accordingly. If feedback points to repetitive mid-roll shots or a disconnect between visuals and narration, rearrange the visual narrative of that segment rather than just swapping colors or adding decorative animations. Do not seek permission for every ordinary production step; handle billing, public release, and personal voice samples separately.

相关技能