Build the Claude Code skill that makes your videos
The short version: the reel that sent you here was made by Claude Code running one skill: a plain text file it reads before it starts. You can write one for any job you repeat, and it takes no code. Four steps: pick one job and write its phases, put in stops where a human decides, name every tool with its exact command, and add a mistakes section you feed after every run. Below: what a skill is, each step with a fill-in block, the full template, my video pipeline as the example, and a second template for a job that is not a video.
First, what a skill actually is
Start with the tool. Claude Code is Anthropic’s version of Claude that runs in your terminal, the black window where you type commands. Unlike the chat app, it can open the files on your computer, run programs, and edit code. You give it a job in plain English and it works through the job using those abilities.
A skill is how you teach it a job you want done the same way every time. Anthropic’s own description is short: “Create a SKILL.md file with instructions, and Claude adds it to its toolkit. Claude uses skills when relevant, or you can invoke one directly with /skill-name.” That is the whole mechanism. A folder, a text file inside it called SKILL.md, and the folder name becomes a command.
The file has two parts. A short header that says what the skill is for, so Claude knows when to reach for it. Then the instructions: ordinary markdown, the same thing you would write in a note to a new hire. Anthropic’s docs put it well: a skill is “organized like an onboarding guide you’d create for a new team member.”
~/.claude/skills/your-skill-name/SKILL.md
That is everything you need to know before writing one. The rest of this page is the four things that separate a skill that produces something forgettable from one that produces something you would put your name on.
What you need before you start
A Claude plan that includes Claude Code, and Claude Code installed. A terminal you are not afraid of. And one job you already do by hand every week, so you know what good looks like. That last one matters more than the tools. A skill is a written procedure, and you cannot write down a procedure you have never done.
Pick one job and write its phases, in order
Not “make content”. One job, with a start and an end. Mine is: one short explainer video and the article it links to. Yours might be the Monday client report, the fortnightly newsletter, or the podcast edit.
Then write the phases the way you would explain them to someone covering for you. Not the clicks, the stages. For a video the stages are: find the topic, write the script, make the video, publish it, prepare the post. Each phase gets its own heading in the file, and under it the two or three things that phase must produce.
# <Job name>, start to finish One <thing> a week, from a blank page to published. Four phases. ## Phase 1 - <Find / gather> What this phase produces: <a shortlist, a brief, a draft topic> 1. <first thing to look at> 2. <second thing> 3. <what "done" looks like for this phase> ## Phase 2 - <Make> What this phase produces: <the draft, the file, the cut> - <the shape it must have: length, sections, format> - <the one rule about quality you would tell a new hire> ## Phase 3 - <Check and publish> What this phase produces: <the live thing, verified> ## Phase 4 - <Package> What this phase produces: <the caption, the email, the summary>
Write it badly first. The file will be rewritten by what happens in step four, so the first draft only has to be honest about the order.
Put in stops, and never let it skip one
A stop is a line in the file that says: present what you have, then wait for me. Mine has three, and they are the reason I trust the output. It shows me the topic before writing a word. It shows me the video before publishing anything. And it asks before anything goes live, and never posts on my behalf.
Put a stop wherever you would want to see the work before the next phase spends time on it, and wherever a mistake would be public. Write it as a rule, not a suggestion. The exact wording in my file is “never cross a stop on your own”, and it is at the top, before any instruction.
Three HARD STOPS where I decide. Never cross a stop on your own. ## Phase 1 ... -> STOP Present ONE recommendation and two runners-up, with honest reasons. Ask me which to run. Do not start Phase 2 until I answer. ## Phase 2 ... -> STOP Deliver the draft with a short summary of what you built and why. Expect changes. Wait for my notes. ## Phase 3 ... Ask me before the first publish. Never post on my behalf. Confirm the live link actually answers before calling it live.
Three is not a magic number. A job with no public step might need one stop. A job that touches money might need five. The point is that the file decides where a human is in the loop, so the model does not.
Name every tool, with the exact command
Claude Code will run programs for you, but it has to know which. “Transcribe the audio” leaves it guessing. “Run python scripts/transcribe.py --days 12” does not. For every phase, list the tool and the one line that runs it, copied from a run that worked.
For a video, these are the tools my file names. Yours can be different; what matters is that each one is in the file with its command.
| Stage | Tool | What it does |
|---|---|---|
| Everything | Claude Code (Anthropic) | Reads the skill, runs every command below, writes the script, the scene code and the article |
| Research | Playwright | Opens the accounts in a browser and pulls the recent posts and their numbers |
| Words | faster-whisper (OpenAI Whisper) | Turns audio into text. First on other people’s videos, later on your own voice, with a timestamp per word so the animation lands on the words |
| Voice | ElevenLabs | Text to speech through the API. Rule in the file: the whole script in one generation, never sentence by sentence, or it sounds like a robot |
| Drawings | Remotion | “Create videos and motion graphics with React.” Every scene is a small React component Claude Code writes |
| Render | ffmpeg | Remotion’s renderer encodes the MP4; ffmpeg pulls check frames and the cover image out of it |
| Article | Next.js on Vercel | The site you are reading. A push deploys it |
| DM | OpenReply | Watches the post for the keyword and DMs the link to anyone who comments it and follows |
| Delivery | Brevo | Emails the finished bundle to the inbox |
## Tools and commands (copied from runs that worked) - Research: `npm run daily` (scrape, score, transcribe, report). Rank by the last 12 days, not all time. - Voice: `python scripts/render/el_tts.py <script.txt> <out.mp3>`. ONE generation for the whole script. - Word timing: `python scripts/render/timing_from_external.py <spec.json>`. Then print every beat's words and read them against the script. - Probe before rendering: `npx remotion still Reel3 out.png --frame=<N>` at each scene's key moment. Expect one fix round. - Render: `npx remotion render Reel3 out.mp4` (about ten minutes, run it in the background). - Verify the publish: `curl -sI https://<your-site>/<page> | head -1`
Two things to notice. Every line is a real command, not a description. And two of them carry a rule that came from a bad run: one generation for the voice, and read the transcript against the script. That is step four leaking into step three, which is exactly what should happen over time.
Add a section called mistakes, and feed it every run
This is the step that matters most, and it is the one every “AI made my video” post leaves out. Your first version will be short, and the output will be fine and forgettable. It gets good when the mistakes section is longer than the instructions.
The mechanism is simple. Every time a run goes wrong, you write one line: what happened, and the rule that prevents it. The next run reads that line before it starts. The file stops being a description of the job and becomes the memory of everything the job has taught you.
Some of mine, word for word, so you can see the shape of a good line:
1. “Never point the robot at text. The hand is a solid dot and it lands on the word.” The line in the video. It exists because the first pointing robot covered the caption he was explaining.
2. “The voice ad-libs.” The voice model rephrases freely, so every timing trigger has to be checked against what was actually said, not against the script.
3. “ChatGPT transcribes as two tokens.” So a cue waiting for the word “ChatGPT” never fires.
4. “Rank by recency, not by all-time outlier factor.” Otherwise the same months-old viral posts win every research run.
5. “The article delivers every promise the script makes.” Added after a video promised twelve lines against an article that had five.
6. “Eased counters never reach the target.” A counting-up number once stopped at 237,768 instead of 238,000, a claim anyone could check. Now every on-screen number snaps to the exact value.
Notice that none of them is advice. Each one is a specific thing that happened and the rule that came out of it. That is the test for a line in this section: could it only have been written by someone who ran the job?
## Traps that have actually cost time (Add one line here every time a run goes wrong. This section is the skill.) - <what happened> -> <the rule that prevents it> - <what happened> -> <the rule that prevents it>
Then run it, and keep running it
Save the file, open Claude Code in the folder where the job lives, and type a slash and the folder name:
/your-skill-name
It will stop at your first stop. Answer, and it carries on. When something goes wrong, do not fix the output by hand and move on. Fix the output, then write the line in the mistakes section, so the next run does not need you for that. Budget ten runs before you judge the skill. Judge the tenth run, not the first.
The full template
The four steps above, assembled into one file. Save it as SKILL.md inside a folder under ~/.claude/skills/, name the folder after the job, and replace everything in angle brackets.
--- name: weekly-video description: Produce one short explainer video and its companion article end to end. Use whenever I ask for "a new video", "this week's video", or invoke /weekly-video. --- # Weekly video, start to finish One video, one article. Four phases with THREE HARD STOPS where I decide. Never cross a stop on your own. ## Phase 1 - Find the topic -> STOP 1. Look at what is working right now in our niche (last 10-14 days, not all time). 2. For the best candidate, write down what it says beat by beat and what it leaves out. 3. Check our list of past topics and keywords. Never repeat a topic or reuse a keyword. 4. Present ONE recommendation and two runners-up with honest reasons. Ask me which to run. Do not write anything until I answer. ## Phase 2 - Make the video -> STOP - Script: about 130 words, eight beats (hook, proof, 3-4 beats of mechanism, result, twist, call to action). - One idea per video. Written to be spoken. A 15-year-old gets it on first listen. - Every claim gets a row in a fact-check table: the sentence, the verified value, the source. If it cannot be verified, cut it. Never invent a quote, a number, or a product behaviour. - Voice: one generation for the whole script, never sentence by sentence. - Deliver the video with a scene-by-scene summary. Expect changes. Wait for my notes. ## Phase 3 - On approval: publish - Write the article. Every number and every promise in the script must exist in the article. - Title under 51 characters. Description 150-160 characters. One link out, one link in. - Ask me before the first deploy. Confirm the live URL answers before calling it live. ## Phase 4 - The launch bundle - Caption: a fresh first line (not the video's), two or three value lines, the call to action. - No em dashes anywhere in copy. - Never post on my behalf. Hand me the bundle. ## Tools and commands (copied from runs that worked) - Research: <your command> - Voice: <your command>. ONE generation for the whole script. - Word timing: <your command>. Read every beat's words against the script. - Render: <your command>. Probe single frames first. - Publish: <your command>. Verify the live link. ## Traps that have actually cost time (Add one line here every time something goes wrong. This section is the skill.) - The transcriber splits "ChatGPT" into two words, so a cue on "ChatGPT" never fires. - Never point the presenter at text. The hand covers the word.
The same shape for a job that is not a video
To show that the four steps are about the job and not about my reels, here is the skeleton for a weekly client report. Different tools, different stops, same file.
--- name: monday-report description: Build the Monday client report from last week's numbers. Use when I ask for "the Monday report" or invoke /monday-report. --- # Monday report, start to finish Three phases with TWO HARD STOPS. Never cross a stop on your own. ## Phase 1 - Gather -> STOP - Pull last week's numbers with: <your export command> - List anything that moved more than 15% either way, with the likely reason. - Show me the list and ask which items to lead with. Do not draft until I answer. ## Phase 2 - Draft - One page. Lead with the three items I picked. Numbers in a table, words under it. - Every number traces to the export. If it is not in the export, it is not in the report. - Written to be read in two minutes by someone who did not see last week's. ## Phase 3 - Send -> STOP - Show me the draft. Never send on my behalf. ## Traps that have actually cost time (Add one line every time a run goes wrong.) - The export uses the client's time zone, so "last week" starts on Sunday, not Monday.
My pipeline, as the worked example
For the curious, this is what the skill that made the video actually does, phase by phase. It is here to show the four steps in a real file, not as something to copy.
Phase 1, find the topic. One command scrapes the competitor accounts, scores every reel against that account’s usual numbers, transcribes the recent leaders with Whisper, and writes a report. The angle is almost always what the viral video left out. It checks a registry of every past keyword, then stops and asks.
Phase 2, make the reel. An eight-beat script with a source next to every claim. The voice in one ElevenLabs generation. Whisper again for a timestamp on every word. Eight scenes written as React components in Remotion, each acting out its sentence and landing on a spoken word. Single frames probed and read before the full render. Then it hands over the MP4 and stops.
Phase 3, publish. The article, with the video’s first beat as an animated figure so you recognise it. A search checklist. A promise audit: every deliverable the video names has to exist on the page. Ask before deploying, then check the live address actually answers.
Phase 4, the bundle. The DM automation, the caption, the cover frame, all emailed to the inbox. Posting stays a human’s finger.
The file that does this is 214 lines, and it leans on a second skill with three reference files for the video craft. Most of what is in them is not the procedure. It is the traps section.
Two related memos. If you are going to install skills other people wrote instead of writing your own, read scan any AI skill before you install it first, because a skill can run commands. And a long Claude Code session eats your usage limit fast; six habits that cut your Claude token usage is the memo for that.
Questions people actually ask
Do I need to be able to code to write a skill?
No. A skill is a markdown text file written in plain English. You need to be comfortable opening a terminal, pasting a command, and saving a file in a folder. Claude Code writes whatever code the job needs when it runs; the skill only tells it what the job is, in what order, where to stop, and what went wrong last time.
What is a skill, in one sentence?
A folder with a file called SKILL.md in it, holding instructions Claude Code reads before it starts a task. Save it under ~/.claude/skills/ and you run it by typing a slash and the folder name.
Does it have to be about videos?
No. The four steps on this page work for any job you repeat: a weekly report, a newsletter, a podcast edit, a monthly bookkeeping pass. Videos are the worked example because that is what our skill does. The second template near the bottom is for a weekly report, to show the same shape on a different job.
Which tools do I need for the video version?
Claude Code, a voice API (we use ElevenLabs), a transcriber that gives word timestamps (we use faster-whisper, a fast version of OpenAI's Whisper), a way to make video from code (we use Remotion), and somewhere to publish. Your own list can be different. What matters is that every tool is named in the file with the exact command that runs it.
Was the video that sent me here really made this way?
Yes. The topic research, the script, the voice, the word timings, the animated scenes, the render, this article, and the DM that sent you the link all came out of one Claude Code session running the skill described here. A human chose the topic, watched the video, and pressed deploy. Those three stops are written into the file.
How long until my skill produces something good?
Your first version will be short and the output will be fine and forgettable. It gets good when the mistakes section is longer than the instructions, and the only way to get there is to run it, notice what went wrong, and add one line each time. Budget ten runs before you judge it.
Is it safe to install skills other people wrote?
Treat a skill like software. It can tell Claude to run commands and read files. Read the whole thing before installing it, and scan it. We wrote a separate memo on scanning skills before you install them, linked at the bottom of this page. Writing your own avoids the problem entirely.
Sources
- Claude Code docs — Use Skills in Claude Code (read 22 September 2026)
- Claude Platform docs — Agent Skills overview
- ElevenLabs — Text to Speech API reference
- SYSTRAN/faster-whisper — Whisper reimplementation with word-level timestamps
- openai/whisper — the speech recognition model
- Remotion — Make videos programmatically
- Vercel — Pricing (Hobby plan)
- OpenReply — the comment-to-DM tool we built
Want this built for you?
We write these memos because we build this stuff every day. If you want it working in your business instead of sitting on your reading list, that is literally our job.