Video and audio skills for AI agents

Ask an agent to read a video for you and it will produce a command. The command will look right — a fetch, a language flag, an output file. What it will not tell you is which of four different things just happened: a human-written caption track came back, an auto-generated one did, the audio got machine-transcribed, or nothing arrived and the failure was swallowed. Media work fails like that all the way down. Captions arrive doubled and nobody notices until the summary repeats itself. A clip lands a second early because the cut snapped to the previous keyframe. A metered credit gets spent on every retry. The skills worth installing are the ones that name their route — where the text or the pixels actually come from — say what that route costs, and say what happens when it isn't available. That one question separates the documents worth handing your agent from the ones that merely look complete.

Top picks

Captions: take the ladder, not the one-liner

youtube-transcript makes the agent find out what exists before it fetches anything: list the available subtitle tracks, try the human-written ones, fall back to auto-generated, and only then offer local Whisper transcription — after printing the audio size and waiting for a yes. The detail that earns it the top slot sits further down, in post-processing: "YouTube's auto-generated VTT files contain duplicate lines because captions are shown progressively with overlapping timestamps." That is the bug you would otherwise ship straight into a summary, and the document hands over a dedupe pass that keeps the original speaking order.

Set against youtube-watcher, which is one script call plus a note that videos without subtitles will fail with an error, this one owns the whole decision tree instead of the happy path. Two caveats: it pins the Whisper base model with a "USE THIS" marker rather than letting you choose, and it was last updated on 2026-03-11, so treat the install commands as older than the rest of this list.

Same name, same author, opposite rule about your browser

A skill called youtube-transcribe-skill can be either of two documents from the same publisher, held in different repositories, and they disagree about whether your agent may read your cookies. The claude-code-settings copy instructs it to "Always add --cookies-from-browser to avoid sign-in restrictions", defaulting to Chrome from the very first metadata call; its two follow-ups both concern which browser to fall back to, not whether to read a profile at all. The codex-settings copy inverts the default — "Do not read browser cookies by default", retry with a profile only after explaining what the retry does and asking which profile you approve, and "Never print, copy, or persist browser cookies in the transcript or logs."

Take the second, and not only for the consent rule. Where the first assumes a specific browser-automation server by name, the second tells the agent to inspect the tools actually present in the session and, if nothing can do the job, to "report the missing capability instead of claiming success." Both are MIT, both were last updated on 2026-07-27; everything that separates them is in the instructions.

The paid route, with the price list printed in the document

youtube-api does not pretend to be free, and that is the recommendation. Its front matter declares a required TRANSCRIPT_API_KEY, its endpoint table prices every call in credits — a transcript or a search costs one, resolving a channel handle costs nothing — and a section headed "Why Not Google's API?" sets its own route beside the official YouTube Data API on quota, setup and price so you can decide rather than discover. It also names the failure that would otherwise eat an afternoon: omit the User-Agent header and "Cloudflare will return a 403 (error code 1010) and block the request."

The flipside deserves saying plainly. This is a third-party service, so your requests and your key go to a vendor rather than to Google, and the same publisher ships a fan of near-identical wrappers — transcript is the single-endpoint version of the same thing. Read the required_environment_variables block and install the narrowest one that covers your case; if you would rather pay nothing, youtube-content needs no key because it leans on the youtube-transcript-api library, which is cheaper and correspondingly more exposed when that library breaks.

Audio: decide where the inference runs, once

asr-transcribe-to-text opens by detecting the platform and then asks where the model should run wherever the hardware leaves a choice — Apple Silicon is offered local transcription against a remote endpoint, and anything else is told "local MLX requires macOS Apple Silicon" and configured for remote — writing the answer to a config file so the choice is made deliberately and once. Its input step is unusually careful with other people's material: reach for an official transcript only when it is directly accessible to the user's own account, and "If the transcript endpoint requires a login token and none is available, say that clearly and fall back to ASR from the audio URL" — then, for third-party or copyrighted media, save the result to a local file and hand back a path, previews or short excerpts rather than pasting the whole thing into chat.

The preprocessing section is where the reading pays off. Multi-part recorder dumps get merged before transcription rather than transcribed separately, because full-audio context is what the pipeline's quality rests on; the merge then verifies its own output — duration must equal the sum of the parts, and a volume probe at each splice catches a missing or misordered file. faster-whisper is the fuller reference if you want to drive the model directly, and transcription-automation is largely YAML templates addressed to an MCP server it mentions once, in front matter, and never tells you how to obtain. One caveat: speaker labels are the default output and that leg needs a gated HuggingFace token set up once, though plain text is a documented opt-out (--no-diarization), and declining the setup persists a flag that makes the plain-text fallback automatic on every later run.

ffmpeg: fix the argument order before anything else

ffmpeg-command-syntax opens on the claim that the most common ffmpeg mistake is putting options in the wrong place, and it is built entirely around that: "Options are applied to the next file. They are reset between files", followed by a placement cheatsheet for the options whose meaning flips across -i — -ss is a fast keyframe seek before it and the accurate-but-slow decode-and-discard seek after it, -c:v picks a decoder before and an encoder after, and encoding options quietly fail to carry over to a second output file.

That last one alone is worth the install. Test it against the clipping one-liner in c-video, which places -ss after -i and says nothing about the distinction: by this reference's own classification that is the slow form, and a reader copying it would never know there was a choice. Know what you are getting, though — this is a syntax reference, not a workflow. It will tell your agent how to phrase a command, never what to cut.

Editing: the skill that tells you where it stops

wjs-segmenting-video cuts a long recording into stand-alone short clips and then deliberately halts, handing off raw clips, per-clip SRTs and a midpoint frame to a named downstream skill for covers and captions. It defaults to re-encoding instead of stream copy and explains the choice with a consequence you can check: a stream copy seeks to the keyframe before your timestamp, so captions sliced at that boundary run ahead of the audio, and on H.264 source with a two-second GOP "every clip is off by 0.6–1.5s." Better still, it ships the ffprobe line that prints your own file's keyframe positions, so the number is falsifiable on your material rather than taken on faith.

It also refuses to guess about orientation: probe the aspect ratio, and where it does not match the target platform, ask before cropping — "Never silently skip the check". video-processing-editing covers more ground, and its colour-space normalisation walkthrough before concatenation is a genuinely good section, but its headline recommendations rest on comparison tables that mostly leave their conditions unstated: the timing table names a one-hour video and stops there, and the quality table reports VMAF scores and encode times with no hardware, no source and no method attached. A number you can re-measure on your own footage beats one you cannot.

A skill's name is only its topic

Skill names are not namespaced, so the same name routinely covers different documents — sometimes different tools entirely, sometimes the same document with the rules reversed, as the two youtube-transcribe-skill copies show. A skill called youtube-content can be any of three different documents. Two of them, the moltis copy and the kheish copy, run byte-identical from the # YouTube Content Tool heading down — the kheish copy simply carries a compatibility preamble above it, remapping legacy tool names and resolving helper files from its own skill directory; NousResearch's differs mainly in routing its helper script through uv. Only one of the three tells you where it came from — moltis declares an origin block in front matter naming an upstream repository and a commit — and the three do not even agree on licence, two MIT against one Apache-2.0.

So the check is: publisher and body first, name last. A skill called youtube-transcript can be the laddered document recommended above, or it can be the glebis copy, which is shaped differently — deduplication there is a separate script you run over an already-saved transcript rather than a step inside the fetch. Neither is wrong. But the name did not tell you which one you were installing, the star count on the card will not either, and the glebis copy declares no licence at all — which is its own reason to open a file before you install it.

Before you install: read the boundary section, then check it is real

The shape to look for is a document that states its route, its cost and its rule in the same breath as its commands. youtube-tools is a fair example: it says what it costs you (no key, no per-video charge), what will go wrong under load — "YouTube may temporarily block IPs with excessive requests" — and what it expects of you, "Only download content you have rights to access", printed next to the scripts rather than buried in a footer.

Then confirm the boundary section is actually about that skill. youtube-downloader has a real Legal Considerations section, separating what is generally fine from what needs checking first; directly below it sits a Skill Boundaries section whose list of things the skill cannot do includes "Access or edit audio files directly", which is byte-identical to the block in the same publisher's whisper-transcription and contradicts the download and audio-extraction commands earlier in its own document. Shared boilerplate is not a boundary. The line genuinely worth searching for is the cookie rule: youtube-downloader from daymade says "Ask before extracting browser cookies" and forbids echoing cookie details back to the user, matching the codex copy above — two different publishers who both concluded that reading your browser profile is your decision, not the agent's.

What to install

The quiet failures named at the start each have an owner now. For the question of which of the four things actually came back, michalparkola's youtube-transcript walks the ladder and reports which rung it landed on, and its dedupe pass stops the doubled captions before they reach a summary. For cost, ZeroPointRepo's youtube-api prints the credit price of every call before you spend one, and daymade's asr-transcribe-to-text makes the local-or-remote decision explicit rather than defaulting you onto someone else's meter. For the clip that lands a second early, jianshuo's wjs-segmenting-video explains the drift, bounds it, and gives you the probe to measure it yourself, with ffmpeg-command-syntax underneath to keep the arguments in the right order.

And the thing you would most likely have gotten wrong alone: two skills with the same name from the same author can hold opposite rules about your browser cookies, and the catalogue card cannot show you that. Open the body, find the paragraph where the document admits what it needs from you, and install the one that asks.