video-summary

Video Content Summary

Readers come to a summary because they don't have time to watch the original video. There is only one thing they want to know: what in this episode is worth taking away with me. So a summary is not an abridged version of the original video; it does not need to cover every topic, nor keep the original order; what it should do is pick out the two or three most valuable things, start from the questions the reader cares about, explain them thoroughly, and say little or nothing about the rest.

The easiest way to write it badly is as a running account: introduce the guest's background at the start, then summarize section by section in order, with roughly equal length for each. The information is all there, but the reader has to read from beginning to end to find which sentence matters, which pushes the work of filtering back onto them.

Before writing, first use skills_read to read this skill's references/writing-baseline.md: materials, baselines (faithful to the transcript, no fabrication, no adding to paraphrases, fill in background), the two types of readers, and the length and style tiers are all there; they are not repeated below.

1. Get materials

Use videos_inspect to view the video's documents. When there is no transcript (documents 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 contain typos; check them against the video information.
Transcript with timecodes: first use speech_sentences to get the transcript numbered by sentence (each sentence has a number and time, and the end of body paragraphs cites the numbers back; see the writing baseline "Sentence numbers and sources"; for long videos, fetch in several batches using next); when it says there are no sentences that can be numbered, use export instead (kind transcript、format md、timestamps true; when there are several transcripts, specify by documentId from the candidates it lists), wait for jobs_inspect to reach completed, and read the file in outputs. The time here is on the post-edit timeline; trimmed words are not in it; key points should use this time, do not estimate it yourself.
Video information: the video name and chapters given by videos_inspect; source title, author, description, link, etc. only use what is in the video information and what the user provides.
No video (for example, only downloaded from a link and transcribed): the SRT in jobs_inspect's outputs has timecodes; read it directly.
The user only wants a summary of a certain aspect(such as "what does the guest think about X" or "the part about pricing"), or wants to summarize several videos together: use speech_relevant (intent write that aspect,videoIds give these videos,order give time) to get the relevant passages, with numbered citations as usual;effectiveMode when it is lexical or none, fall back to reading the full text.
Look at the visuals when necessary. Where the transcript points at the screen while speaking (demos, slides, code, charts, "this", "here", "everyone look"), and reading the text alone does not tell you what is being discussed, use videos_frames to grab a few frames at those timecodes (at list the moments, or range plus count for evenly spaced capture, at most 24 frames at a time, reading each frame's fileNot every video needs frame captures: skip them for pure conversation or content that's clear from reading the transcript. Captured frames are only used to clarify what the speaker is referring to and to state it clearly; what you see in the frame is background you add, not what the speaker said, and readers must be able to tell the difference when it's written in. Frames are source footage and do not include subtitles, text, or overlaid elements.

2. Language

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

The language specified in the user's request this time; if not specified, the language of the message the user gave you this time.
Interface language: use the user's interface language when it 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 determined, skip item 1. When unsure, follow the order above; at delivery you may also mention that another language version can be produced. The writing baseline holds for any language; the wording examples on this page are only illustrative—when switching to another language, use the corresponding expressions in that language.

3. Who it's written for

The default reader is someone curious about the topic but not in this field: reads the news, has used related products, can name the big companies, but has never worked in this industry and is unfamiliar with the jargon. If the user specifies a different reader, follow the user's.

This reader is smart, just hasn't studied this field. Don't talk down to them, and don't start everything from scratch; what you need to do is not let them get stuck on jargon. This setting determines three things: what to pick as the essence, how to handle terminology, and how detailed to make an explanation.

4. What the output is

Two parts:

Summary body: a piece of writing organized around the essence. The opening sentences point out what is most worth taking away, the body explains them thoroughly, and secondary content is briefly mentioned in the last few sentences or omitted.
Key points: a set of short sentences, each a conclusion, method, or number worth remembering, noting the time in the video of the segment it is based on, so readers can jump back to that part of the video.

The body gives the full context; the key points are a guide: a glance at the key points tells you which segment to rewatch. The number of key points depends on the content; don't pad it. Places in the body worth rewatching can also be noted with timestamps.

5. Before writing

First figure out the following from the transcript; they do not go into the final product. If the user gave focus points or attached their own thoughts in this request, center steps 2 and 3 on them.

Who is speaking. Identify the host and guests; who each speaker is and in what capacity they speak. Rely only on self-introductions in the transcript, introductions by others, experiences mentioned in passing ("when we were doing X back then"), and the video information. If the transcript only has speaker numbers and there is no way to confirm, use roles like "host" and "guest" and do not guess names.
Pick out the essence. This is the most important step; all later choices are based on it. After reading through, ask yourself: if you could tell a friend only two or three things from this episode, which would they be?

What counts as essence is usually novel or counterintuitive judgments, insider details and specifics only someone who was there can tell, practices readers can directly use, and the strong cases and numbers that support them. Common knowledge, pleasantries, vague outlooks, and viewpoints already done to death elsewhere don't count, even if they take up a long time in the video. How much time something takes up in the video has nothing to do with whether it's worth writing.

When choosing, stand in the position of the target reader, not the position of an insider. For the same video, practitioners and laypeople want to take away different things; content that only insiders care about, no matter how brilliant, should be placed later or briefly mentioned in the last few sentences. Usually there are two to three key points, at most no more than four. If you can't pick them out and feel every topic is about equally important, it means you haven't thought it through yet—read it again.

When the user specifies a focus, that focus is the key point of the whole text: start from it at the beginning, write it the longest and most completely, and compress the other content accordingly.
Think clearly about why readers will care. For each key point, find which question of the reader's it answers: what were readers originally curious about, wrestling with, or taking for granted? For example, readers have always believed A, and the speaker uses personal experience to show that it is actually B; or readers are worrying about something, and the speaker happens to give them a method. This connection point is the entry point for the opening and also the lead-in for expanding each section.
Understand why the speaker is worth listening to. Readers most likely don't know him. What needs to be answered is not "what is his résumé," but which of his experiences on this topic gives him a perspective others don't have. When there are multiple speakers, distinguish the differences in their perspectives (practitioner, researcher, investor; do they complement each other or stand in opposition). The host also needs to be clarified: who he is determines the nature of this conversation—whether it is peers exchanging methods, a layperson asking an expert for advice, or someone asking questions with doubts; a host who only handles transitions and whose identity is irrelevant to the topic does not need to be introduced. The result of this step is for backup use: where a claim needs weight, or where readers need to know "who is asking and who is answering," point it out in one sentence.
Sort the remaining content into tiers. Content other than the key points falls into three categories: content that supports the key points (arguments, cases, background) should be merged into the corresponding key points; content unrelated to the key points but that readers might want to know should be briefly mentioned in the last few sentences; the rest is not written. The way to judge is to ask: if this is deleted, what will readers lose? If you can't say, delete it.
Mark the places where readers will get stuck. Only look at the parts to be written into the summary. The speakers are all insiders, and there are many companies, events, analogies, and terms mentioned in passing. Ask one by one: will the target reader know what is being talked about here? If not, handle it according to Section 7.
Verify the background. Names of people, companies, products, and events to be written into the summary should be based on the transcript and video information; transcripts are mostly machine-generated, names are often misspelled, so check them against the video information. When internet access is available, you can look things up; what you find can only be used to introduce people and supplement background, and must not become the speaker's viewpoint; when what you find conflicts with the transcript, the transcript takes precedence, and note it if necessary. When you cannot search or cannot find anything, write only what has support in the transcript and video information, and do not fill in from memory.

6. How to write the main text

Opening

Readers will decide whether to keep reading after the first few sentences. The opening needs to achieve two things: attract people to keep reading; let readers quickly understand what this episode is about and how it relates to them. Put the most valuable things first. Even if readers leave after only reading the opening, they should already have taken away the core of this episode.

How to start depends on what the best material is for this episode; there is no fixed order:

There is a specific scene or story in the video that itself can explain the core of this episode. Tell this story directly.
The speaker holds a judgment that goes against what most people think. Set the default assumption everyone has side by side with his judgment.
A question the reader is currently struggling with or curious about, which this episode happens to answer.
A surprising number or fact.

"What does this have to do with the reader" should land on the reader's own life and work: what the things he uses will become, whether what he is spending effort learning now is still worth it, whether he should do something. Be specific; don't say things like "this matters to everyone." If this episode's connection to ordinary readers is not direct to begin with, honestly explain what it covers and why it is worth knowing, and don't force a connection.

The opening should read easily: two or three short paragraphs, no more than three hundred characters; if it doesn't fit, that means there are too many points you want to stuff in—keep only the most important one and its one or two most direct supporting points. The relationships between the key points should be visible (because, therefore, but); don't pile them into a string of unrelated bullet points. Try to avoid terms that need explaining.

For comparison (just illustrative; don't copy the sentence patterns):

Bad: The guest of this episode is the head of a programming tool team at a certain company, and has previously done developer tools at several companies. In this episode, he talks about the product's birth process, technology choices, changes in code review, and his views on the future of programming.

Good: AI writes code faster and faster, yet teams' delivery speed has not increased in step—where is the problem? The person responsible for this tool says what's holding them up is code review: code output has grown several times over, but people can't keep up with reading it. Their solution is to have AI review it first and have people look only at the parts AI is unsure about, and this in turn forced them to change something else: the way engineers write requirements.

After reading the former opening, the reader only knows "there is such a video"; after reading the latter, the reader has already gotten the conclusion and knows what is worth continuing to read below.

Two lines: don't be coy—after raising a question or telling a story, give the answer within two or three sentences; don't exaggerate—write exactly as far as the speaker goes. Don't write openings like "In this video..." or "This episode features..." When done, check: if you swap out the names and product names, can this passage still be placed unchanged on another episode? If so, it means it didn't use anything unique to this episode—rewrite it.

Introducing the people

Who each speaker is, why they are worth listening to, and what nature this conversation has should be made clear, but the position and manner are not fixed: it can be brought in with a phrase at the start, concentrated in a short paragraph after the opening, or mentioned casually when they first appear. Don't write it as a résumé. When a judgment comes from his personal experience, point out the source casually ("in the first two weeks of their internal launch," "in the team he leads"); this shows the weight of the statement better than a title; keep only the one item relevant to the current claim, and don't reintroduce it every paragraph.

Expansion

The body expands around the key points one by one, one section per key point. Order by value, with the most important written first, regardless of the order in the original video. Content about the same topic discussed at different points in the video should be merged together.

Each section should explain that key point thoroughly: what the speaker's conclusion is, what basis he has for saying so (argument, personal experience, cases, numbers), and what readers can take away at the practical level. Length follows value: the most important section can be four or five paragraphs, a secondary one two paragraphs is enough; sections do not need to be the same length.

Each section usesa bolded sentenceWrite the subheading as the conclusion or key point of the section itself, so that readers who only skim the headings still get something—for example, "The bottleneck has shifted from writing code to reviewing code" rather than a topic-only label like "About code review." If the content itself is very short, you can leave out the subheading.

Within a section, use natural paragraphs rather than lists: lists cannot hold "because..., therefore..." Content that is itself a list (steps, checklists, comparisons) is the exception.

The body text is reporting, without mixing in evaluation. Readers must be able to tell which sentence is what the speaker said and which is what the author says. Questions raised by the host, figures the host gives, and analogies the host makes should be marked as the host's, not blended into the guest's views. Use indirect speech for important points, with neutral reporting verbs such as "he said," "he thinks," "in his view," and do not add attitude words on someone's behalf; use direct quotation only for short sentences that lose their flavor when reworded, keep them consistent with the transcript, and remove filler words.

Make it understandable to non-expert readers

Professional videos are dense with terminology; copying it over would make readers pause at every sentence, and explaining each term in parentheses would fragment the article. For each term and proper noun, first ask whether it is necessary for the reader to understand this point, then choose one of three approaches:

If it is not necessary, simply leave it out. Specific tools, frameworks, commands, and technical details that the speaker mentions in passing mostly fall into this category. What readers should take away is "she built her assistant a set of checking tools that can open programs on their own and click through them like a user"; which library is called underneath would only get in their way.
Say what it means in plain language, without the term itself appearing. For example, instead of "use static checking rules to constrain the codebase," write "set a lot of automatic checking rules for the codebase, and code that breaks the rules cannot be committed."
Keep only what is necessary, and explain it the first time it appears. Core concepts that cannot be avoided, words readers will keep encountering later, and words the whole piece revolves around fall into this category. Explain them with a sentence readers can picture, making clear what it is and why it matters here, without using another term to explain it.

If a paragraph needs more than two or three new words explained, it is too close to the original wording: step back, first make clear what this thing is and why it matters, then decide which details are worth keeping. Analogies the speaker makes are usually the best explanatory tool, because he himself is explaining to a layperson; when you find a good analogy, use it in the body text to help readers understand the corresponding point, rather than treating it as a sidenote at the end.

The same goes for companies, products, people, and events: if readers are unfamiliar with a name and the name is not important, replace it with a general description; if it is important, explain what it is in one sentence the first time it appears. Add background only insofar as it lets readers understand this argument: one sentence for a company name is enough; if a story needs several paragraphs to tell and it really is part of the essence, write several paragraphs. Do not expand it into a popular-science piece.

Secondary content and the ending

Content in the video that is unrelated to the essence but that readers might want to know should be covered in three or four sentences at the end of the body text, without a subheading, and without evaluating the video itself ("the rest is rather scattered"). If what you want to write exceeds three or four sentences, screen it again; if there is none, do not write it.

In the default style (plain), the body text stops at the last topic or the few sentences covering secondary content, without adding a "in summary" or "in conclusion"-style summary, outlook, or call to action.

When the user provides their own thoughts this time (reactions after listening, personal experiences, points they want to emphasize or rebut), treat them as the most valuable input: open by leading with them, and after the main body write an "Author's Note" in the author's voice that preserves the specific details and tone of the user's own words, only polishing and completing them rather than replacing them with safer phrasing. Keep this passage separate from the paraphrase so readers can tell at a glance that the author is speaking. The author's experiences, numbers, and positions may only come from what the user provides and must not be drafted; if a personal experience is genuinely needed to make the piece stand up and none is available, leave an obvious placeholder (e.g., "[To be filled in: when did you first encounter this problem?]") and tell the user at delivery which spots are waiting for them to fill in. When the user chooses a style with commentary (see Section 5 of the baseline), the commentary is likewise written as the author's words, kept separate from the paraphrase, and grounded in the transcript.

7. Key Points

Each point is one sentence that makes sense on its own: the subject, object, and conclusion are all in that sentence; do not write "he then discussed this issue."
Pick conclusions, methods, numbers, and new things; skip opening pleasantries, transitions, and things everyone already knows.
For each point, note the time it is based on, pointing to where this topic begins, taken from the transcript's timecodes, not estimated.
Order them as they appear in the video; merge two points that say the same thing.
The key points are consistent with the main body and contain no facts absent from the main body; add no commentary—it is a guide, and accurate paraphrase is enough.

8. Different Videos, Different Emphases

Video	Emphasis
Interviews, podcasts, roundtables	The guests' views and the basis for them; keep the host's questions only when they help understanding
Talks, lectures	The main line of argument: problem, claim, evidence, conclusion
Tutorials, demonstrations	What was accomplished, preconditions, steps, common mistakes; write the steps as an ordered list; when an on-screen operation is unclear, grab a frame to look
Reviews, comparisons	What is being compared, under what conditions, the conclusion and caveats
Narratives, documentaries, vlogs	What happened, where the turning point is; do not spoil suspense the user wants to keep
Meetings, discussions	What was decided, who is responsible, what remains undecided

9. Length and Style

Length is determined by the weight of the essence, not by the video's duration: write until it is clear, keep the same content as short as possible, and every extra paragraph the reader reads should give them something. Explaining something clearly to a non-expert reader takes more words, and that length is saved from the professional details that get cut. See Section 4 of the baseline for what the levels mean; for summaries specifically:

Length	Main body	Key points
Short	A few paragraphs: the single most important essence and its basis; omit the rest or mention it in one sentence at the end. No subheadings	Only the most important few
Medium (default)	As in Section 6: an opening, each essence in its own section written so it can be retold, secondary content in a few sentences	Every essence is covered; one point for each place worth revisiting
Long	Write every key takeaway in full: keep every step of the argument, examples, numbers, quotable lines, causes and consequences, and explain how the takeaways relate to one another; give secondary content its own short section too. After reading, there should be no need to watch the video.	One entry per spot worth revisiting

When the transcript is long and a long version is requested, write the second half as fully as the first half; don't make the later parts thin just because the transcript is long.

Style shows in the author's own narration and commentary; what the video says does not change with style (Section 5 of the baseline). Key points carry no commentary regardless of style.

10. What to avoid

Don't summarize in the original video's order and chapters, don't try to cover every topic, and don't give every topic roughly the same amount of space.
Don't open with a guest introduction, don't turn the description of people into résumés, and don't start every paragraph with a person's name.
Don't copy in the tool names, framework names, and technical details the speakers mention one by one.
Don't use bullet points in the body, and don't number the sections.
Don't use empty phrases like "renowned expert", "industry big shot", "many years of deep work", or "unique insights"; replace them with what the person has actually done.
Don't add phrases like "in short", "in summary", or "this episode is packed with content".
Don't make up content that isn't in the transcript; in particular, the speakers' positions, education, experience, and achievements must not be filled in by guessing.
Don't mix evaluation into paraphrase; transitions like "even better" and "ironically" are evaluation too.
Don't use figurative verbs to sound vivid ("grow out", "scrape together", "chew through"); use the plainest wording ("summarize", "iterate out", "finish").
Don't use clickbait headlines, teasers, or exaggeration of what the speakers said just to attract readers.
Don't let "Author's note" contain experiences, numbers, or positions the user hasn't given.

11. Delivery

Write it as a Markdown file in the working directory (e.g. <视频名>.summary.md; for multiple languages, add a language tag before the extension, e.g. <视频名>.summary.en.md). Save each length or style version as a separate file, named by version; before a major revision, save the previous version separately, and for minor edits, edit directly. If the session doesn't belong to the project, the user can't see the working directory: then use downloads_save to put it in the downloads directory and tell the user the path it returns. When the user only wants to see it in the conversation, reply directly with the body and key points.
In the body, use little Markdown formatting other than bold subheadings; put key points in a separate group.
Tell the user: the file's real path; which language the output used and which rule decided it; what background was added beyond the transcript (including what was seen in the visuals); what information was not verified; which preferences were not followed or what content was deleted; and list any placeholders left to be filled in separately.

12. Self-check

Reading only the opening, can readers state the two or three most valuable points from this episode and know how it relates to them? Is the opening within three hundred characters with no terms that need explaining? Does it start from who the guest is and what the show talked about?
If you swap out the names and product names, could the opening be placed unchanged on another episode? If so, rewrite it.
Are the chosen key points what the target readers most want to know, or what insiders most want to know? Is the most important key point the part written most fully in the whole text? When the user specifies a focus, is it the entry point of the opening and the longest section?
Is the order of the sections ranked by value, or has it unknowingly reverted to the order of the original video? Ask of each section: if this section were deleted, what would the reader lose? If you can't say, delete it, or merge it into the paragraph that briefly covers secondary content.
If you scan only the bolded headings, can you tell what the conclusion of each section is?
Every fact, number, and name can be traced back to the transcript, the video information, or the materials provided by the user; nowhere is the speaker's identity guessed; nowhere are the speaker's words made to say more than what they actually said.
No evaluation is mixed into the paraphrase; when using an "author's note" or a commentary-bearing style, the reader can tell which sentence is what the speaker said and which is what the author said.
Read it from beginning to end as a reader who is not in this field: is there any sentence where you need to stop and look up a word? Is there any paragraph where, after reading it, you can't say what it is about? Is every term, company, person's name, and event that is kept necessary, and explained the first time it appears? After reading each story, can you retell it using "because... therefore..."?
Can the reader tell that what is seen from the visuals is added background?
Each key point can be understood on its own, and the thing it states did indeed get said at the time noted for it.
The language of the output follows the order in Section 2; the length and style are the tier and style requested this time; there are no padded paragraphs, and no key facts were lost just to make it shorter.