video-blog

Turn a video into a blog post

The people reading this article have not watched the video, and most likely do not plan to. What they want is a complete article: after reading it, they understand the ideas presented in the video, remember the examples, and can follow the steps themselves. So it is neither a cleaned-up transcript nor a summary: a summary tells the reader what was covered in this episode, while the article retells the content of this episode in full, in a way that keeps people reading.

The two most common ways to write it badly: one is to strip the filler words from the transcript, split it into a few paragraphs, add a few subheadings, and hand it in—it still reads like a record of one person talking, jumping back and forth, with unclear references and unexplained points; the other is to drift into a summary, giving each topic two sentences, with the examples, numbers, and steps all gone. The former is hard for readers to follow, and the latter leaves readers with nothing to take away.

Before you start writing, first use skills_read to read this skill's references/writing-baseline.md: the materials, the baseline (faithful to the transcript, no fabrication, no added material when retelling, fill in background), the two types of readers and perspectives, the tiers of length and style, and the defaults are all there, and are not repeated below.

1. Get the materials

Use videos_inspect to look at the video's documents. If there is no transcript (a document with kind speech), transcribe first, and tell the user that transcription is in progress. If the transcript has not been polished, names and terms may have typos; check them against the video information.
Transcript with time codes: first use speech_sentences to get the transcript numbered by sentence (each sentence has a number and a time; cite the numbers at the end of body paragraphs, see the writing baseline "Sentence numbers and sources"; for long videos, fetch it in several batches with next); when it says there are no numberable sentences, use export instead (kind transcript、format md、timestamps true; when there are several transcripts, specify one by documentId from the candidates it lists), wait with jobs_inspect until completed, and read the files in outputs. Times are on the post-editing timeline; when you need to mark a time point, take it from there and do not estimate it yourself.
Video information: the video name and chapters given by videos_inspect; for the source title, author, publishing platform, and link, use only what is in the video information and what the user provides.
No video (for example, only downloaded from a link and transcribed): the outputs of jobs_inspect include SRT and TXT; read them directly.
For long transcripts, read in sections first (by chapter or by time), and for each section note the topic blocks, the exact quotes to cite, and their time codes, then combine them into the finished piece. Do not write the finished piece when you have only read part of it.
When writing about only one topic, or combining several videos, do not read through each one: use speech_relevant (intent write the topic,videoIds give these videos,order give time) to get the relevant passages; the sentence numbers are the same set as speech_sentences, and cite them as usual;effectiveMode when it is lexical or none, there is no semantic index, so fall back to reading each one as above. When the user wants "related reading", use space_related_videos to list one or two videos on similar content (do not make up ones that are not given).
Look at the visuals when necessaryIn the transcript, wherever someone points at the screen while speaking (demos, slides, code, charts, “this”, “right here”, “take a look”), when the text alone doesn't make clear what they mean, use videos_frames to grab a few frames at those timestamps (at list the times, or range add count to take frames at equal intervals, at most 24 frames at a time, and read each frame's file). Don't grab frames for pure conversation or parts you can understand just by reading the transcript. A frame is the source footage at that moment, without subtitles, text, or overlaid elements; what you see in the frame is background you're filling in, and when you write it in, the reader must be able to tell the difference.

2. Language

Which language to produce in: take the first one available, in this order:

The language the user specified in this request; if none, the language of the message the user gave you this time.
Interface language: use it when the user's interface language is given in the conversation context.
The language of the transcript.

If the user's message is only a few words and the language can't be identified, skip item 1. When unsure, follow the order above; at delivery you can also mention that a version in another language is available. The writing baseline holds for any language; the wording examples on this page are illustrative only.

3. Before you start writing

Think through the following first; they don't go into the final piece:

Which perspective. If the user said, follow it; if not, decide per the “Perspective” section of the baseline: if the user's preferences state their identity and the video is clearly the user's own, use the author perspective; if it's clearly published by someone else, use the viewer perspective; if you can't tell either way, use the viewer perspective, and if unsure you may briefly ask. Attributing someone else's words to the user is worse than writing the user's words as reported speech.

	Author perspective	Viewer perspective
When	The video is the user's own	The video is someone else's
Written for whom	The user's readers: people who follow the user, people who find this article	People who haven't seen the video and want to know what it says
Goal	An article that can be published under the user's name and makes people want to keep reading	An article that can stand in for watching the video: complete and faithful
Tone	The user themselves; first person is fine	Third-person reported speech, with views attributed to whoever said them
Opening	Gripping (Section 4)	State the source, then say what this piece is about and who it's useful for
Fixed sections	Add the byline, closing follow prompt, etc. from the user's preferences	No byline or promotion for the user

What is most worth reading in this article. Write it in one sentence: a conclusion, a result, a question, an experience. The opening starts from it; the title starts from it.
Why the reader will care. What were they already curious about, torn over, taking for granted? How does this land in their own work and life? “What does this have to do with the reader” must be concrete; don't say things like “this matters to everyone”.
The article's skeletonGroup the same topic that is scattered across different places in the video into one section; conclusions can be moved earlier; if the same point is made several times, keep the clearest one. Order it according to what the reader needs to understand, not the video's sequence. During the adjustment, the causality must not change.
Places where the reader will get stuckFor names, companies, terms, metaphors, and skipped steps that the speaker mentions in passing, ask one by one: will someone who has not watched the video know what is being said? If not, add a sentence in the main text, explain the meaning in plain language, or leave it out.
Where to add imagesFor slides, demos, charts, physical objects, and the results of operations that cannot be explained clearly with words alone, note the timecode (Section 6).

4. Opening

The reader will decide whether to keep reading after the first few sentences.

Author's perspective: The first few sentences tell the reader what they will get from reading on, starting from the most worthwhile point. No pleasantries, and do not start with "Today I want to talk with you about" or "Recently many people have asked me." What hooks the reader must be delivered in the main text. The tone should first follow the style for this piece, then the user's preference; if neither exists, follow how the user speaks in the video; the user's views and reservations in the video do not change because of tone.

Audience's perspective: The first paragraph explains whose video this is, which episode, where it was posted (according to the video information), who the speaker is and why they are worth listening to on this topic, then says what this piece covers and who it is useful for. Write the source specifically, but not as a resume: mention the one thing they have done that is directly related to this topic, and do not pile up titles.

Compare (for illustration only, do not copy the sentence patterns):

Bad: Today I want to talk with you about code review. As AI tools become more widespread, many teams have encountered new problems. Below I will discuss this from several aspects based on my own experience.

Good: In the first two weeks after our team launched AI-written code, delivery speed did not increase at all; it actually slowed down. Code output tripled, but it got stuck at review: no one could keep up. This piece explains how we changed the review process, and the second thing we were forced to change after that.

After reading the former opening, the reader only knows "code review is going to be discussed"; after the latter opening, the reader already knows what this piece covers, how it relates to them, and wants to keep reading.

Multi-person dialogueIt can appear in either perspective: either write it as reported speech (grouped by topic, with views attributed to people), or keep the Q&A format; the Q&A format must also be edited, not pasted from the transcript.

5. From speech to writing

Remove verbal tics, restatements, half-finished sentences, and off-topic chatter; if the same point is made several times, keep the clearest one.
Write out what was conveyed in speech through tone, gestures, and visuals: what "this" and "over there" refer to, and what was being demonstrated on screen at the time. If you have looked at frames, write clearly what you saw.
Keep examples, numbers, steps, and key wording from the original speech. They are the most valuable part of the article, and also the part most easily lost during "organization."
The stance does not change. Where the speaker left room ("I guess," "maybe," "in our case"), leave room in the article too; do not turn "sometimes works" into "works."
Terminology: when the speaker casually mentions a tool name, framework name, or technical detail, first ask whether it is necessary for the reader to understand this section. If it is not necessary, leave it out; if it can be made clear in plain language, do not bring in the term itself; when a core concept cannot be avoided, the first time it appears, explain it in one sentence the reader can picture, not with another term. The speaker's own analogy is usually the best explanation—use it in the body text.
Paraphrase without mixing in evaluation. The reader must be able to tell which sentence is the speaker's and which is the author's. This is especially true in the viewer's perspective: report what the other person said faithfully; commentary belongs to the author and is written separately.
When adding background, follow baseline rule 4. What you add is facts that help the reader understand the video's content, not your own extended discussion of the topic; do not add viewpoints the video does not express.

6. Structure and illustrations

TitleDetermined by the content, starting from the most worthwhile point to read; a title in the author's perspective should also be engaging, and likewise only say what the video delivers.
Body sections, each section's subheading states that section's conclusion or what it covers ("The bottleneck shifted from writing code to reviewing code," not "About code review," and certainly not "Part One"). The video's chapters can serve as a starting point for sections, but chapters are for viewers to jump around in, while the article's sections follow the needs of reading.
Within a section, use natural paragraphs, not lists: lists cannot hold "because..., therefore...". Content that is itself a list (steps, checklists, comparisons) is the exception.
EndingStop where the content ends; do not add "in summary" or "hope this helps"; if the author's perspective has a fixed closing section, add it.
Illustrations: some content can only be explained clearly with an illustration: slides, demos, charts, physical objects, the results of an operation. In these places, state what image is needed and which point in the video it corresponds to (taken from the transcript's timecodes), with a caption below. Illustrations support the text, they do not replace it: remove the image and the paragraph should still read clearly; only add illustrations where an image is needed, not one per section for looks. Frames obtained with videos_frames can be given to the user directly as material (they are source footage, without subtitles or overlays); for frames with subtitles or overlay effects, ask the user to capture them in the editor. Illustrations that are not in the video and need to be drawn separately should be marked as added. When the user agrees to generate illustrations, you can use image generation (without video): draw only diagrams and concept images (a metaphor, a scene, a relationship), do not pass them off as footage from the video, product interfaces, real people, or data; use the same style description throughout, with the aspect ratio according to the image's position in the article (usually landscape 16:9 or 4:3), and no text in the image. Use artifacts_save to save to the same directory as the article, with a similarly flat filename (e.g. <视频名>.blog.fig-1.png), and state in the caption that it is generated. For how to call it and what to do when it cannot draw, use skills_read to read baocut-catalog-media 's "Generating images".
When the user asks for keyframe illustrations(the "Add keyframe illustrations" box is checked on the tool page, or they say in conversation that they want illustrations): only take frames at the places mentioned above that need an image, one frame per place. First choose by content: use videos_match_frames (videoId，text write the image this section needs,near give a source number cited back for this section) to get several candidates, and at the closest match use videos_frames's range copy its framesRange to take two or three frames, and pick the clearest, most on-topic one; it reports MODEL_NOT_INSTALLED、INDEX_NOT_READY or other reasons (no frame index), or when the candidates are all weak and still don't match the point, use videos_frames to grab a frame at the source time of this passage at(seconds on the timeline); when the picture changes while someone is speaking, grab two or three more frames and pick the clearest one. At delivery, state whether the illustration was chosen by content or taken by time. The frame files are in the working directory .baocut-out/frames/<videoId>/ , copy the ones used into the same directory as the article, with the article name in the filename and no subdirectories (e.g. <视频名>.blog.at-12500ms.png; subdirectories won't survive delivery, whereas a flat filename works anywhere), and write it in the article as a relative-path Markdown image ![图注](<视频名>.blog.at-12500ms.png), with a one-sentence caption below saying what the image shows and the corresponding video timestamp. When the box isn't checked and no illustration was requested, don't insert images; just note in the previous item what visuals are needed. When delivering the article per section 9, hand over the images one by one as well, still in the same directory as the article, and tell the user how many there are and where they are.

7. Length and style

Articles have no fixed length: write until it's clear, and every extra paragraph the reader reads should give them something. Explaining one thing clearly to a non-expert reader takes more words; make up that length by cutting specialist detail. See baseline section 4 for what the levels mean; for articles specifically they are:

Length	What the article looks like
Short	A short piece: cover only the one or two most worthwhile things in this video, and explain them clearly
Medium (default)	Cover all the main content of the video; keep the key examples and steps
Long	Retell the video content in full: every argument, example, step and number is there, the background is filled in, and every place that needs a visual has an illustration specified

Style	In the article
Plain (default)	Explain the content clearly, without commentary. The author's perspective defaults to the way the user speaks in the video
Popular science	Reorganize for laypeople: start from what the reader already knows, explain each term, use plenty of examples and analogies
Snark	The author speaks with attitude: commentary and teasing. In the viewer's perspective, relay what the other person said as it was said; the commentary is the author's
Other	Write as the user describes; when a sample is given, learn its tone and structure, but don't copy its sentences

When the transcript is very long and a long version is requested, write the second half as fully as the first.

8. What to avoid

Don't just strip the filler words from the transcript and hand it in as an article; and don't drift into a summary as you write.
Don't open with "Today I'd like to talk with you about" or "With the development of..."; in the viewer's perspective, don't introduce people like a résumé.
Don't copy in every tool name, framework name and technical detail the speaker mentions.
Don't use bullet points in the body text, and don't write subheadings like "Part One" or "About X".
Don't make up content that isn't in the transcript; the speaker's titles, experience and figures especially must not be filled in by guesswork.
Don't mix evaluation into relayed speech; transition words like "even better" and "ironically" are evaluation too.
Don't add "In short", "In summary" or "Hope this helps", and don't force a grand conclusion.
In the author's perspective, don't make promises on the user's behalf that weren't made in the video, or announce plans the user never mentioned.

9. Delivery

Save it as a Markdown file in the working directory (e.g., <视频名>.blog.md; when there are multiple languages, add a language tag before the extension, e.g., <视频名>.blog.en.md). Save each version with a different length or style separately; before a major revision, save the previous version as a separate copy, and make minor edits directly. If the session does not belong to the project, the user cannot see the working directory: then use downloads_save to put it in the downloads directory and tell the user the path it returns; for videos with keyframes inserted, handle each image file the same way.
Explain to the user: the file's real path; which perspective was used and on what basis; which language the output is in and which rule determined it; what background was added beyond the transcript (including what was seen in the visuals); which information was not verified and which links the user needs to supply; which supporting images the user needs to capture; when keyframes were inserted, where the image files are and how many there are in total.

10. Self-check

Perspective is right: the author's perspective uses the user's voice; the viewer's perspective states the source and does not present someone else's views as the user's.
Reading only the opening, does the reader know what this piece is about, how it relates to them, and whether they want to keep reading? For the author's perspective, is what hooks the reader delivered in the body?
It is understandable without watching the video; every "this" and "there" has a referent; every term, person's name, and company that is kept is necessary and explained when first mentioned.
Every fact, number, and name is in the transcript or the video information; added background is distinguishable and certain; readers can tell which things seen in the visuals were added.
The speaker's positions and reservations are all there; no evaluation has crept into the paraphrase.
Examples, numbers, and steps are still there and were not lost while "organizing".
There is no wholesale copying of the transcript, and it is not written as a summary.
Scanning only the subheadings, you can tell what each section is about.
Where visuals are needed, what visuals are needed is specified; it is understandable even without the images. If the user asked for keyframe illustrations, every image has a caption, the path is relative to the article's directory, and the image files are placed together with the article.
The output language follows the order in Section 2; the length and style are the tier and style requested this time.