youtube-skills: Agent Skills That Put YouTube Transcripts Behind One API Key

The Problem Is IP Reputation, Not Parsing

The README makes one claim that frames the whole project: yt-dlp is blocked by YouTube on all major cloud IPs. That is the constraint this repository is built around. If your agent runs on a VPS, a container platform, or any shared cloud egress, a local extraction library tends to fail for reasons that have nothing to do with your code. Adding a headless browser does not fix the underlying address reputation problem, it just adds a Chromium dependency to your image. youtube-skills sidesteps both by moving extraction to TranscriptAPI, a hosted backend the README also ties to youtubetotranscript.com. The agent makes an HTTP call and gets text back. The intended user is someone wiring YouTube access into an agent runtime, not someone building a data pipeline that needs to own the fetch path. If you control your own residential egress and already have yt-dlp working, this repository solves a problem you do not have.

What Actually Sits in the Repository

This is a skills distribution repo, not an application. The install instructions clone it and copy a directory into a skills path, and the manual route shown is `cp -r youtube-skills/skills/youtube-full ~/.claude/skills/`. Everything under `skills/` is skill definition material that the host agent reads and then follows. There is no server, no daemon, and no local index. The README describes 12 skills, and it is candid that many are narrower variants or aliases of the core five: youtube-full, transcript, youtube-search, youtube-channels, youtube-playlist. The stated reason for the aliases is retrieval: so the agent finds the right skill regardless of how the request is phrased. That is a reasonable design for prompt-driven selection, but it also means the repository is mostly duplicated instruction text, and a fix to shared behaviour has to be applied in more than one place. The README does not document how that duplication is managed.

Installing Into OpenClaw, Hermes, or a Plain Skills Directory

The README gives four install paths. For OpenClaw (also called ClawdBot or Moltbot) it is `npx clawhub@latest install youtube-full`. For Hermes Agent it is `hermes skills install skills-sh/ZeroPointRepo/youtube-skills/skills/youtube-full`. For Claude Code, Cursor, Antigravity, Cline, and Codex the command is `npx skills add ZeroPointRepo/youtube-skills --skill youtube-full`, and dropping the `--skill` flag installs all 12. Installing a single narrower skill looks like `npx skills add ZeroPointRepo/youtube-skills --skill transcript`, and multiple skills can be chained with repeated `--skill` flags. The README also offers a no-terminal route: paste a prompt telling the agent to install the skills from the GitHub URL, and the agent handles it. That prompt is the part I would treat with caution. It delegates both installation and credential setup to the model, and the credential step is the one with real consequences.

The API Key Is the Real Configuration Surface

The README states that on first run the agent asks for an email address, registers it with TranscriptAPI, prompts for an OTP code sent by email, then saves the resulting key. The key is prefixed `sk_`. Manual setup means signing up at transcriptapi.com, copying the key, and either asking the agent to persist it or exporting `TRANSCRIPT_API_KEY` yourself. Persistence locations are listed per runtime: `~/.openclaw/openclaw.json` or `~/.clawdbot/moltbot.json` for OpenClaw, a Hermes secret store where `TRANSCRIPT_API_KEY` is declared through `required_environment_variables` in skill frontmatter, `~/.zshenv` and `~/.zprofile` on macOS, `~/.profile`, `~/.bashrc` and `~/.zshenv` on Linux, `~/.config/fish/config.fish` for Fish, and `~/.transcriptapi` at mode 600 as the fallback. The frontmatter declaration is the cleanest mechanism here, because the runtime enforces the variable rather than relying on the agent to remember. The shell-profile writes are the messiest: appending a secret to `~/.bashrc` puts it in every interactive shell and in anything that sources that file. The mode 600 fallback file is the better default if you are choosing manually.

Credit Accounting Is Undocumented in the README

The README promises a free tier with no credit card and 100 credits on signup. It never says what a transcript costs, whether a channel browse costs the same as a single transcript, or whether a bulk transcript request over a channel deducts per video. That gap matters because one of the advertised prompts is "Get transcripts for every video in this channel." A prompt like that, run against a large channel, is exactly the shape of request that consumes an unknown quantity of a metered allowance. The README points to transcriptapi.com/docs for details, so the pricing model is presumably there, but nothing in the repository material lets you estimate cost before you run it. If you plan to use the bulk and research prompts, resolve the per-call cost first. The 100-credit figure alone tells you nothing about how far it goes.

What the README Does Not Settle

Several things a reader would want are absent. There is no description of rate limits, no retry or backoff guidance, no statement about what happens when a video has no captions, and no error surface for the agent to handle. There is no discussion of transcript quality or language coverage beyond one example prompt asking for Spanish captions. There is no offline mode, no caching layer, and no way to point the skills at a different backend. There is no versioning story: the repository shows no retrieved releases, so pinning to a tag is not an option the material supports, and `npx skills add` will track the default branch. For a dependency that sits between your agent and a paid API, the absence of a documented failure contract is the weakest part of the project. The skills will work in the happy path and the README gives you nothing to reason about outside it.

The Alternative Is Owning the Fetch, and It Costs Differently

The obvious alternative is yt-dlp run locally, which is what this project positions itself against. The difference is not feature parity, it is where the failure lives. With yt-dlp you own the extraction, the update cadence when YouTube changes something, and the egress address, and you pay nothing per call. The README's counterargument is that cloud IPs get blocked, which is a real operational cost if you are on one. A second alternative is Google's own YouTube Data API, and the README gestures at it directly by describing the youtube-data skill as a lightweight alternative to it and the youtube-api skill as avoiding Google quota hassle. That framing is worth reading carefully: those skills still route through TranscriptAPI, so what you are avoiding is Google's quota model, not the third-party dependency. The honest comparison is hosted extraction versus self-hosted extraction, and the deciding factor is whether your environment can reach YouTube at all. If it can, yt-dlp keeps the credential and the data path inside your infrastructure. If it cannot, this repository is the shorter path.

Licence, Maintenance, and Upgrade Cost

The repository is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That covers the skill files in this repo. It does not cover TranscriptAPI itself, which is a separate commercial service governed by its own terms, and the README's own framing makes that split explicit by calling the API the backend. Nothing here is legal advice; if you are shipping this inside a product, read the service terms separately from the MIT text. On maintenance, the practical cost is low but not zero. The skill files are text the agent reads, so upgrading means re-running the install command or re-copying the directory, and because no releases were retrieved from the repository, there is no version to pin to. The heavier maintenance burden sits on the other side of the HTTP call: when TranscriptAPI changes an endpoint or a response shape, the skill instructions have to be updated in the repository before your agent sees the fix. You are a consumer of someone else's release schedule, and the README gives no deprecation or changelog policy.

Editorial conclusion

Adopt youtube-skills if your agent already runs inside a runtime that supports the Agent Skills format (OpenClaw, Hermes Agent, Claude Code, Cursor, Antigravity, Cline, Codex) and you accept that every transcript call leaves your machine for transcriptapi.com. Do not adopt it if you need offline operation, self-hosted extraction, or a guarantee that the free tier's 100 credits will cover your volume. Before installing, verify two things: whether your runtime resolves skills from ~/.claude/skills/ or from a runtime-specific config file, and what the current per-endpoint credit cost is on the TranscriptAPI docs page, because the README states the signup grant but not the price of each call.

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. ZeroPointRepo/youtube-skills on GitHub