SuperAPI AI Directory
Partner中文AI newsFavorites
Skillstitles-and-description

titles-and-description

Writing & research

View repository

Updated 10-20 08:10

About this skill

Titling and writing descriptions

The user's video is done and ready to publish. The title determines whether anyone clicks in the list; the description determines whether those who click watch, and whether those who finish can find the things mentioned in the video. Both are written for people publishing videos: be compelling, and let every sentence be delivered by the video. Title and description work together: first produce title candidates and let the user pick one, then use it when writing the description.

The most common way to write badly: starting from sentence patterns. "Shocking!" "You absolutely won't believe" "One video explains X clearly" — these could be swapped onto any other video, which shows they don't use anything unique to this video; or conversely, the title restates the video's name and the description is a play-by-play of the video, and nobody wants to click.

Before writing, first use skills_read to read this skill's references/writing-baseline.md(materials, baseline, two kinds of readers and perspectives, length and style, defaults). Before titling, also read references/titles.md; before writing the description, also read references/description.md。

1. Gather materials

  1. Use videos_inspect to look at the video: name, chapters (atSeconds and title of chapters), document. When there is no transcript (document with kind speech), transcribe first and tell the user the transcription is in progress. If the transcript has not been polished, names and terms may contain typos; check them against the video information.
  2. Read the manuscript: first use speech_sentences to get the sentence-numbered manuscript (in the description, cite the numbers at the end of paragraphs based on the manuscript; see the writing baseline "Sentence numbering and sources"; titles do not cite); when it says there are no numbered sentences, use export (kind transcript、format md、timestamps true; when there are several manuscripts, specify the one to use by documentId from the candidates it lists), wait with jobs_inspect until completed, and read the files in outputs. When there is no video and only a result downloaded from a link and transcribed, read the TXT or SRT in jobs_inspect's outputs.
  3. Video information: source title, author, original video link, publishing platform — use only what is in the video information and what the user provides.
  4. Series and previous works: when the user wants to recommend related videos in the description, or wants to distinguish this from previous titles, use space_related_videos to list a few that cover similar content (names and the closest original quote); list only what it gives, do not invent, and do not write the content of related videos as if this video covered it.
  5. The user's requirements this time: language, length, style, number of candidates, publishing platform, perspective; the title already chosen; the candidates given before and the one the user wants to follow — find them all in this conversation. When the user says the title and description are published on the same platform, write both for the same platform.

2. Before writing

First think through these two things; they do not go into the final product:

  1. What is most worth watching in this video. Write it in one sentence: an unexpected conclusion, a concrete result, a question everyone cares about but cannot answer, an uncommon experience, a method usable right away. The title starts from it, and the opening of the description starts from it. A video often has several points worth watching; they are the starting points for different candidates.
  2. Why the audience would clickWhat was he originally looking for, curious about, and expecting? What can this video save him, help him avoid, and give him? Make this connection point concrete.

3. Delivery

  • Title: Give candidates directly in the reply, each with an angle and a one-sentence reason, and mark the recommended one; ask the user to pick one, or say they want another batch, or how many more to provide following which one.
  • Description: Give the full text directly in the reply (tags on a separate line). When the user wants a file, write it as a Markdown file in the working directory (e.g. <视频名>.description.md; for multiple languages, add a language tag before the extension); when the session does not belong to a project, then use downloads_save to put it in the downloads directory and tell the user the path it returns.
  • Also explain: which perspective was used and on what basis; the title the user has already settled on (or that is still awaiting the user's choice); which information has not been verified and which links the user needs to supply; if platform rules were mentioned, remind the user to check against the platform's current rules.

4. What to avoid

  • Do not start from sentence patterns; rewrite any title that would still work after swapping out the video name and the person's name.
  • Do not promise what the video does not give: numbers, "most", "first", and the questions left open must all be present in the video.
  • Do not pass off rewrites of the same sentence as different candidates.
  • Do not make up links, chapter timestamps, or platform rules.
  • The description should not begin with a link, tag, or byline, and should not read like a running log.