The AWP Video Editing Skill: Turn Raw Footage Into a Finished Cut With Claude Code

An open-source Claude Code Skill that runs an 8-step pipeline over one video: Gemini analysis, timed narration, Fish Audio voiceover, jump-cut trimming, adaptive subtitles, and a finished cut. Here is how it works and where it fits.

AI video editing pipeline diagram showing 8-step automation workflow for Claude Code

Editing is where video content dies. Not shooting, not scripting: editing. You have footage that already contains the story, and the job is to find it, tighten it, write narration, voice that narration, align subtitles, and drop in music. This guide is about handing all of that to an AI video editing pipeline you run from inside Claude Code — so the only work left is your judgment: which shots to keep and how to tell them.

Each of those steps is mechanical, each one takes real time, and none of them is where your judgment actually matters. That is the split this Skill is built around: automate the labor, keep the taste.

The awp-video-editing-skill is an attempt to delete the labor and keep the judgment. It is an open-source Claude Code Skill: you point Claude Code at a single video file, pick a style, and it runs an eight-step pipeline that returns final.mp4 with narration, voiceover, and burned-in subtitles, plus a run report. No timeline. No keyframes. No scrubbing back and forth to find the cut point.

This is a walkthrough of what the Skill does, how it is built, how to install and run it, and — more usefully — where its edges are. It is not a pitch. The Skill has real constraints: it calls two paid cloud APIs, it edits one video at a time, and its defaults are tuned for Chinese-language commentary with English available as an explicit option. Knowing those constraints up front is the difference between using it well and being surprised by it.

If you write video regularly and you are already living inside Claude Code or Codex, this is worth your afternoon. If you are looking for a drag-and-drop consumer app, it is not that, and this guide will make that clear early enough to save you the install.

The problem: manual editing does not scale with your ambition

Every recommendation feed rewards volume. More videos, more consistent cadence, more surface area for the algorithm to test. The economics are simple and they point in one direction: publish more.

The bottleneck is equally simple. Cutting even a two-minute clip means opening a non-linear editor (NLE), scrubbing a timeline to find the moments worth keeping, writing a script that matches what is on screen, recording or generating a voiceover, and then aligning subtitles line by line so they land on the right frame. A competent editor does this in an hour or two for a short piece. Do it five times a week and editing has quietly become a part-time job that produces nothing you would call creative.

The usual responses do not fix the core issue. Hiring an editor moves the cost from your time to your wallet and adds a coordination loop. Learning a faster NLE lowers the per-cut time but keeps you on the timeline. Template-based mobile apps produce the same look everyone else's templates produce, which is the opposite of what a channel needs. None of these attack the actual problem, which is that the sequence of edit → script → voice → subtitle is a fixed pipeline that a human is executing by hand, one step at a time.

A fixed pipeline executed by hand is exactly the kind of work that should be automated. The steps are deterministic. The order never changes. The only genuinely creative decisions — what style, how many shots, which moments to emphasize — can be expressed as a handful of parameters. Everything downstream of those parameters is mechanical execution that a machine does faster and more consistently than a person who is on their fifth video of the week.

The awp-video-editing-skill takes that whole sequence and collapses it into one command. That is the entire value proposition, and it is worth stating plainly because it is narrow and it is real: it does not make your videos better, it makes the boring 80% of producing them disappear so you can spend your time on the 20% that is actually yours.

Why a Claude Code Skill, and not a prompt or an app

There are two obvious alternatives to a Skill, and both fail for instructive reasons.

The first is a bare prompt. Modern models can already watch a video, describe its shots, write a script, and hand you narration text. You could, in principle, do all of this by pasting a video into a chat and asking.

The problem is that a prompt is not a pipeline. It produces text, not a rendered file. It has no memory of the exact timestamps it chose, no way to split the source video on those timestamps, no voiceover generation, no subtitle burning, no music mixing, and no guarantee that the next run produces anything like the last one. A prompt gives you the creative half and leaves you to hand-execute the mechanical half, which is precisely the half you were trying to eliminate.

The second alternative is a traditional application: a desktop editor with AI features bolted on, or a web app that promises automated editing. These render files, but they lock you into their model of the work. You configure through their UI, you accept their defaults, you cannot fork their behavior, and when you want a signature look for a specific channel you are limited to whatever knobs they exposed. You are renting someone else's pipeline.

A Skill sits in the gap between these two. The Skill's own documentation puts it directly: "A Skill is a workflow, not a prompt." It packages the deterministic pipeline — the file operations, the API calls, the FFmpeg composition — as scripts, and it hands the creative decisions to the model at run time. Because Claude Code and Codex can run shell and Python directly, the Skill can do the things a chat cannot: write intermediate files, resume from a checkpoint, run FFmpeg locally, and produce the same quality every run.

Three properties fall out of this design, and each one matters more than it first appears.

It is repeatable. The pipeline runs in a fixed order, writes its state to state/progress.json, and can resume from wherever it stopped. Run it on Monday and Friday and you get the same behavior, not two different improvisations.

It is transparent. Every style is a plain-text YAML file you can read and change. Every parameter is in a JSON config you can inspect. There is no black box; there is a directory of files you own, sitting under ~/.claude/skills/.

It is composable. Because the Skill edits one video through a command-line pipeline, an agent can loop it over a folder, chain it with other tools, and schedule it. The Skill edits one video; your agent orchestrates the rest. That is a different ceiling than an app that only knows how to process what you drag into its window.

This is the honest case for the Skill format. It is not that Skills are magic. It is that a Skill is the right shape for work that is half creative decision and half mechanical execution, which is exactly the shape of video editing.

What is in the repository

The repository is a self-contained Skill: everything it needs to run lives in its own directory, and the only things you bring are two API keys. Here is the real inventory, taken from the repo rather than paraphrased.

Twenty-two built-in styles. These are the creative presets, and they span five verticals: general commentary, film and entertainment, knowledge and documentary, lifestyle and nature, and e-commerce and short video. Each style is a full YAML file with its own director persona, its own calibrated speech rate, its own voice timbre, and its own background music track. The styles are not cosmetic themes; they change how the model analyzes footage and writes narration. More on this in the styles deep dive below.

An eight-step pipeline. This is the mechanical spine. In order: initialize, Gemini analysis, split plus jump-cut, narration word-count check, text-to-speech (TTS) voiceover, speed-adjust plus compose, final compose, and output report. Two of these steps call the cloud; the rest run locally. The pipeline is strictly sequential and it does not skip.

Two cloud dependencies, one local engine. Video understanding and narration generation run on Google Gemini (specifically gemini-2.5-pro via AI Studio). Voiceover runs on Fish Audio. Everything else — splitting, jump-cut detection, subtitle rendering, composition — runs locally on FFmpeg, which is bundled with the Skill through the static-ffmpeg package so you do not need a system install. The dependency list also ships edge-tts as a documented fallback TTS engine.

Adaptive subtitles. Subtitles are generated in ASS format with automatic sentence splitting and line wrapping, and they auto-size for portrait, landscape, square, and 4K. This is the kind of detail that is invisible when it works and infuriating when it does not, and it is handled.

A resumable, checkpointed run. The Skill maintains a progress file and writes each step's output to its own directory inside a timestamped run folder. If a run fails at step five, you do not start over from step one.

The output is deliberately small: a runs/{name}-{timestamp}/output/ directory containing final.mp4 (the finished cut, with subtitles and voiceover) and report.md (the run report with key parameters and an output manifest). That is the deliverable. Everything else in the run folder is intermediate state you can inspect if you want to understand what happened, or ignore if you do not.

It is worth being explicit about scope. The Skill is single-video mode: one source file per run. It has no sub-agents and no batch splitting; the whole pipeline runs on the main agent plus its scripts. Batch behavior — running the Skill over a folder — is something you orchestrate from outside, which the Skill's own documentation treats as a first-class use case. That is a deliberate design choice, not a missing feature, and you should know it going in.

How the AI Video Editing Skill is built

8-step video editing pipeline from analysis to final export

The Skill is worth understanding at the level of its parts, because the parts explain both what it does well and where it will surprise you.

The SKILL.md contract

Everything starts with SKILL.md, the file that tells Claude Code what this Skill is and when to run it. Its frontmatter declares a name of video-editing, a description, an allowed-tools list of exactly three tools (Read, Write, Bash), and a set of trigger keywords: "video editing", "edit video", "cut this video". When you type one of those phrases, Claude Code loads the Skill and begins the pipeline.

The tight tool allowlist is a design signal. This Skill does not need network tools or a browser; it needs to read files, write files, and run shell commands. Restricting it to three tools keeps its behavior legible and its blast radius small. The Skill's own execution rules reinforce this discipline: read the matching workflow document before running each step, verify each step's output before moving on, never skip a step, and persist progress so a run can resume.

Script organization

The mechanical work lives in scripts/python/, and the file sizes tell you where the complexity is. The largest module is gemini_analyzer.py, which handles the video analysis and narration generation — unsurprising, since that is where the model does its thinking. Next is ffmpeg_processor.py, which splits the source and composes the final cut.

Then subtitle_generator.py for ASS subtitle rendering, tts_calibrator.py for speech-rate calibration, and tts_generator.py for the Fish Audio voiceover calls. Supporting modules handle template rendering (template_engine.py), jump-cut detection (jumpcut_detector.py), narration validation (storyboard_updater.py), original-audio matching (audio_matcher.py), FFmpeg binary discovery (common.py), and credential loading (_cred.py).

This is a clean separation. The model-facing work, the FFmpeg work, the TTS work, and the subtitle work are each their own module with their own responsibility. If you ever need to swap the TTS backend or adjust subtitle styling, you know exactly which file to open.

The three-layer prompt architecture

This is the most interesting idea in the Skill and the one most worth stealing for your own work. When the Skill asks Gemini to analyze a video and write narration, it does not send a single monolithic prompt. It assembles the prompt from three layers.

The creative layer comes from the style YAML's analysis_creative_layer field. This is the director persona: the methodology and voice for that specific style. For the food-documentary style it is a director who has studied A Bite of China frame by frame; for general commentary it is an all-around commentary director. This layer carries the taste.

The parameter layer comes from a shared prompt template and defines the input information and the output specification — what the model receives and the exact JSON schema it must return. This layer carries the structure.

The config layer is runtime substitution: variables like {{storyboard_count}} that get filled in from the run configuration. This layer carries the specifics of this particular run.

Separating taste from structure from specifics is what makes the styles forkable. You can change the creative layer — rewrite the director persona entirely — without touching the parameter layer that guarantees the output is still valid JSON the pipeline can consume. The style author writes prose; the pipeline stays deterministic. That boundary is why 22 wildly different styles can all feed the same downstream machinery.

Gemini analysis and the multi-turn cache

Step two uploads the video to the Gemini File API and runs analysis in a multi-turn conversation. The first turn produces a shot script: a list of scenes, each with source timestamps, a duration, and a first-draft narration. The second turn rewrites that narration for audio-visual sync, and critically, it reuses the video context from the first turn through prompt caching rather than re-uploading and re-analyzing. The model watches the video once and then reasons about it twice.

The output is a storyboard.json that is the spine of the whole run. Each scene records its source_start_time and source_end_time, its duration_seconds, both the draft narration_script and the calibrated narration, a target_word_count, a speed_factor, and a status. The metadata block records the style, the shot count, the narration language, the voice ID, the speech rate, and the model. This single file is why the pipeline is resumable and inspectable: every decision the model made is written down in a form you can read.

Speech-rate calibration: the sync problem, solved with arithmetic

Here is the detail that separates this Skill from "have a model write a script." Narration that does not fit its shot is the single most common failure in automated video: the voice runs long and bleeds into the next scene, or runs short and leaves dead air. The Skill solves this not with hope but with a number.

Every style declares a speech_rate, calibrated in characters per second for Chinese or words per second for English. The rates are specific and they vary by style: general commentary runs at 6.65 characters per second, the documentary-story style at 6.88, the food-documentary style at a slower, more contemplative 4.43, and the English-narration style at 2.63 words per second. Given a shot's duration and the style's speech rate, the pipeline computes a target_word_count, and the narration-rewrite turn is instructed to hit that count precisely. Shot duration is treated as law; the narration is fitted to it, not the other way around.

There is a second correction. After the narration is voiced, step six applies a speed_factor within a bounded range (0.5 to 1.5 by default) to fine-tune the fit between the voiceover audio and the shot. Calibration gets the word count close; the speed factor closes the remaining gap. The result is voice and picture that stay locked together instead of drifting apart over a two-minute cut.

The voiceover: Fish Audio and its fallback

Step five turns the calibrated narration into audio. The production engine is Fish Audio, called over HTTP, using the speech-1.6 model and emitting MP3 at 128 kbps. The generation parameters are conservative — temperature 0.7, top-p 0.7 — which keeps the delivery consistent across shots rather than letting the voice wander in tone from one scene to the next. Consistency matters more than flair in narration; a voice that sounds like a different person every eight seconds reads as broken.

The timbre is where the styles assert themselves again. Each of the 22 styles declares its own voice_id, so a food documentary and a game commentary are voiced by deliberately different narrators, and the Skill fills that ID automatically from the style YAML.

Beyond the per-style timbres, the default config ships three named voice presets — a general male voice (the recommended default), a gentle female voice, and a professional broadcast voice — that you can fall back on if you want to override a style's choice. And the dependency stack carries edge-tts as a documented fallback TTS engine, so the pipeline has a local option if the primary service is unavailable. The design is layered on purpose: a per-style voice by default, named presets to override with, and a fallback engine underneath.

Jump-cut detection with FFmpeg scdet

Raw footage has flicker and dead frames at the edges of shots — the moment before action starts, the black frame after it ends. Step three splits the source into per-shot clips on the storyboard timestamps, then optionally runs FFmpeg's scdet (scene-change detection) filter to trim those edges automatically. The defaults are a threshold of 8 (lower is more sensitive), a scan range of 1.3 seconds at each end, and a minimum retained duration of 2.0 seconds so trimming never eats an entire short shot.

The design here is defensive in a way worth noting. Jump-cut detection is explicitly optional. If it fails twice in a row, the pipeline stops retrying, logs the error, and falls back to the untrimmed clip. A failure in an optional cleanup step does not take down the run. That is the kind of decision that separates a demo from a tool.

FFmpeg composition and the local-first stance

Steps six and seven do the assembly: speed-adjust each shot, lay the voiceover over it, mix in background music at a low volume (the default is 0.15 against a voiceover at 1.0), burn the subtitles, and concatenate everything into the final cut. The FFmpeg settings are pedestrian and correct: fast preset, CRF 20, AAC audio at 128k. Composition runs locally with the bundled static FFmpeg binary.

The local-first stance is a real feature, not a footnote. Only two steps leave your machine: the Gemini analysis and the Fish Audio voiceover. Your footage is not uploaded to a general editing service; it is uploaded to Gemini for analysis and otherwise stays on your disk. For anyone editing footage they would rather not hand to a third-party platform wholesale, that boundary matters.

Adaptive subtitles

Subtitles are the step most tools get lazily wrong, and it is the step that most visibly marks a cut as amateur. The Skill renders them in ASS format — the subtitle format that supports precise positioning and styling — with automatic sentence splitting and line wrapping, so a long narration line breaks sensibly instead of running off the frame. The rendering also auto-sizes for the aspect ratio of the source: portrait, landscape, square, and 4K each get subtitle dimensions that fit. A vertical short and a horizontal explainer do not share the same subtitle geometry, and the Skill knows that.

Subtitles are on by default and can be disabled in custom mode, but the default is the right one: burned-in, correctly sized, split on sensible boundaries.

The run directory, state, and resumability

Every run creates a self-contained folder under the skill's runs/ directory, named for the source video and a timestamp. Inside it, each pipeline step writes to its own subdirectory — step01-init/, step02-analyze/, step03-split/, and so on through step08-report/ — plus a state/ folder and the final output/. Nothing is scattered; a run is one directory you can archive, inspect, or delete as a unit.

The state/progress.json file is what makes a run resumable. It records the current step and the status of every step, from completed to pending, and it is updated after each step finishes. If a run dies at step five because a network call timed out, the progress file knows steps one through four are done and their outputs are on disk.

Restarting picks up from the checkpoint rather than re-uploading the video to Gemini and paying for the analysis again. For a pipeline whose two most expensive steps are cloud calls, checkpointing is not a convenience feature — it is cost control.

The run configuration is captured in a config.json written at initialization, which freezes every parameter the run will use: the mode, the input path, the style ID, the resolved voice ID and music path, the shot count, the original-audio count, the subtitle and jump-cut toggles, the concurrency, and the Gemini settings. Because the config is written down before the pipeline runs, a run is reproducible: hand someone the config and the source, and they get the same behavior. This is the quiet discipline that separates a Skill built to a specification from a script that happens to work once.

Getting started: install, configure, run

Terminal showing Claude Code Skill installation and first run

The Skill targets Python 3.10 or newer and runs locally. Installation is two commands after you have the repository; configuration is two API keys.

Install

Clone the repository, copy it into your Claude Code skills directory under the name video-editing, and run the setup script from the skill root:

git clone https://github.com/aiworkflowpro/awp-video-editing-skill.git
cp -r awp-video-editing-skill ~/.claude/skills/video-editing
cd ~/.claude/skills/video-editing
bash scripts/setup.sh

The setup script handles the whole environment in one pass: it checks for Python, installs uv, creates a virtual environment, installs the dependencies, detects FFmpeg, and validates your credentials. If you prefer to do it by hand, the manual path is a uv venv followed by uv pip install --python .venv/bin/python -r scripts/python/requirements.txt. The virtual environment lives at the skill root and every script shares it.

FFmpeg deserves a specific note because it is the usual source of install pain and it is handled here. You do not install FFmpeg yourself. The static-ffmpeg package is declared as a dependency, and installing dependencies fetches the platform-matching static binary automatically. You can verify it resolved by importing the binary helpers from the common module and printing the paths.

Configure your keys

The Skill needs two credentials, both required.

cp credentials/google-gemini.example.json credentials/google-gemini.json
cp credentials/fish-audio.example.json    credentials/fish-audio.json
# edit each file and set "auth": { "token": "<your key>" }

Your Gemini key comes from Google AI Studio; your Fish Audio key from fish.audio. If you prefer environment variables, the Skill also reads GOOGLE_GEMINI_API_KEY and FISH_AUDIO_API_KEY.

Both are paid services, and this is the right moment to say so plainly: running this Skill costs money per video, because Gemini charges for the analysis and Fish Audio charges for the voiceover. The FFmpeg work is free and local; the intelligence is not. Budget accordingly, and start with short clips while you learn the behavior.

Trigger the Skill

With the Skill installed and keys configured, you start a run by telling Claude Code what you want in plain language:

edit this video: /path/to/clip.mp4

The Skill prints its opening line and then asks you a short set of questions. It uses plain-text question-and-answer, not a graphical form, and you can answer with a number, a keyword, or a direct value.

Auto mode versus custom mode

The Skill offers three interaction modes, and the choice determines how much it asks you.

Auto mode is one round of three questions: the video path, how many original-audio shots to keep, and a confirmation of auto mode. Then it proceeds with sensible defaults — general commentary, eight shots, the style's default music, subtitles on — and produces the cut directly. This is the mode to start with.

Manual and advanced modes add a second round of six more questions, where you choose the style from the full list of 22, set the shot count, pick or disable background music, provide an optional creative outline, and toggle subtitles and jump-cut detection. This is the mode for when you know what you want.

One detail is deliberately hidden from you: the voiceover timbre. Each style declares its own voice_id in its YAML, and the Skill fills it automatically rather than asking. A style's voice is part of the style, not a separate decision. You can override it with an explicit voice ID if you insist, but the default respects the idea that a food documentary and a game commentary should not sound like the same narrator.

A few parameters are worth knowing because they shape the output. The default shot count in auto mode is eight; in custom mode you choose between concise (6), standard (8), and detailed (16). Original-audio shots let you preserve the source audio on some scenes instead of overlaying voiceover, and Gemini only picks these starting from shot six — the first five shots are always AI voiceover, which keeps the opening tight. Concurrency defaults to three scenes processed at once. Subtitles and jump-cut detection are both on by default.

When the run finishes, you collect output/final.mp4 and output/report.md from the timestamped run folder. That is the whole loop: two install commands, two keys, one sentence, one finished video.

Reading a run: the storyboard is the source of truth

The single most useful thing you can do to understand this Skill is to open the storyboard.json from a completed run. It is the file that turns the pipeline from a black box into something you can audit, and it is where you will learn whether the Skill's judgment matches yours.

The storyboard is a list of scenes, and each scene is a small, complete record of a decision. A scene carries the source video it came from, its source_start_time and source_end_time as timestamps, the duration_seconds between them, and two versions of the narration: the narration_script (the first-draft text the analysis turn produced) and the narration (the calibrated, precisely-timed final text). It also records the target_word_count the pipeline computed for that shot, the speed_factor applied to fit the audio, whether the scene uses original audio, and its status. Reading these back to back, you can see exactly which moments the model chose to keep, how long it gave each one, and what it decided to say over it.

The metadata block at the top of the storyboard is equally revealing. It names the style, the shot count, the narration language, the voice ID, the calibrated speech rate, the timestamp of the analysis, and the model used. If a cut feels off — too fast, too dense, mistimed — the storyboard tells you why in numbers, not vibes. Maybe the speech rate is wrong for your footage. Maybe a shot's duration is longer than its content deserves. You can see the decision and, because the styles are plain YAML, you can change the parameter that drove it.

Alongside the storyboard sit the intermediate step folders. step03-split/ holds the per-shot clips and a jumpcut_results.json that records, scene by scene, how much was trimmed from each end and the resulting duration — the exact numbers the narration check uses downstream. step05-tts/ holds the voiceover audio. Each folder is a stage of the pipeline made inspectable. You rarely need to open them, but when something surprises you, the answer is always sitting on disk in a readable file.

The report.md is the human-facing summary: the key parameters of the run and a manifest of what was produced. It is the file to skim after a batch run to confirm each video came out with the shot count and duration you expected. Between the report and the storyboard, a run leaves a complete paper trail — which is precisely what you want from a tool you intend to run unattended and trust with your channel's output.

The styles, up close

22 video editing style presets with different visual moods

The 22 styles are the part of the Skill you will actually spend time with, because they are where your channel's identity lives. Understanding a few representative ones — and the YAML underneath them — tells you how to bend the Skill to your own look.

The anatomy of a style

Every style is a single YAML file under reference/styles/, and they all share the same shape. There is an id, a name, and a description. There are two prompt layers: analysis_creative_layer, the director persona that guides how the model reads footage and drafts narration, and audio_sync_creative_layer, the specialist that rewrites narration to match the footage precisely. And there is a config block with the operational settings:

config:
  channel_name: General Commentary
  duration_range:
    min: 8
    max: 16
  speech_rate: 6.65
  voice_id: 3746013d295a49279bf5fe612370722c
  bgm: style-1000-bgm.mp3

That is the entire contract. The creative layers carry the taste, the config carries the numbers, and both feed the same pipeline. To make a new style you copy an existing YAML, rewrite the creative layers, adjust the config, and save it under a new ID. Nothing else in the Skill needs to change.

General Commentary (1000): the workhorse

Style 1000 is the default and the one to understand first. Its director persona is an all-around commentary director whose first rule is fidelity to the source: watch the whole video, identify the aspects it covers in sequence, and narrate in that order. The persona is explicit that a movie recap, a product review, and a documentary each have their own natural structure, and the narration should follow the footage's own logic rather than imposing a template. Its speech rate is 6.65 characters per second — brisk, information-dense, the pace of a channel that respects the viewer's time.

If you are unsure which style to use, this is the correct default, and its creative layer is the best one to read first if you want to understand how the Skill thinks about narration.

Food Documentary (1016): taste as constraint

Style 1016 is the most illuminating style in the repository because it shows how much a creative layer can shape output. Its persona is a director who has studied A Bite of China, and the whole prompt is a study in restraint. The rules are almost adversarial to the usual AI-narration failure modes: the first word of every narration line must be a noun or verb visible on screen; never open with pure lyricism or a bare time word; do not describe tastes or chemistry or the inside of an ingredient, only what the eye can see; do not manufacture suspense; let scenes breathe.

The speech rate drops to 4.43 characters per second — this style "is not fast-talking; it is negative space and breathing." It is a study in using a prompt to encode a specific aesthetic discipline, and it is worth reading in full even if you never edit a food video.

Product Review (1002) and TikTok Product Promotion (1003): two takes on commerce

These two styles sit near each other in the e-commerce vertical and diverge in tone in a way that maps to how they are used. Product Review (1002) runs at 5.65 characters per second with a rational, objective posture — gadget and appliance reviews where credibility is the currency. Product Promotion (1003) runs slightly faster at 5.81 with a warm, infectious tone built for the e-commerce showcase where enthusiasm converts. Same footage of the same product, two different narrators, two different intents. Choosing between them is a positioning decision, not a cosmetic one.

Game Commentary (1007): energy on purpose

Style 1007 runs at 6.49 characters per second with a passionate, energetic register tuned for game guides and playthroughs. It is a reminder that the speech rate is doing double duty: it sets both the word budget and, indirectly, the felt pace of the piece. A game commentary and a soothing-scenery style (1017, at a languid 4.20) are not just different voices, they are different metabolisms.

English Narration (1020): the path to English output

This is the style to know if you are publishing in English, because it exposes something important about the Skill's defaults. The pipeline's default narration language is Chinese (zh-CN); the Skill was clearly built first for the Chinese commentary market. English is a first-class option, not an afterthought, but it is an option you select.

Style 1020 is the English Narration style, calibrated at 2.63 words per second and carrying narration_language: en-US in its parameters. There is also a top-level narration_language parameter you can set to en-US in custom mode.

The practical takeaway: to get an English cut, either pick the English Narration style, or set the narration language to English explicitly. The AI-workflow scenarios in the repository lean into this — one of the showcased use cases is producing an English-narrated cut of foreign-language footage in the food-documentary style, keeping the original ambient audio low under the voiceover. The Skill is bilingual by design; you just have to tell it which language you want, because it will not guess English for you.

The full range

The remaining styles fill out the five verticals. Film and entertainment covers funny mashups (1005), variety-show recap (1006), savage film reviews (1013), cinematic recap (1014), deep shot-by-shot film analysis (1015), and a cold crime-and-gangster register (1019). Knowledge and documentary covers talk and interview (1008), documentary story (1009), and history documentary (1010). Lifestyle and nature covers cute nature (1011), kids animation (1012), soothing scenery (1017), copy-over-visuals (1018), and a low, poetic animal-world style (1021). E-commerce and short video covers short-video remakes (1001) and long-video highlight cuts (1004). Across all 22, the shot duration is uniformly 8 to 16 seconds, each style has its own dedicated voice timbre, and each has its own background music track named style-{id}-bgm.mp3. Two styles carry special parameters: the short-video remake (1001) and crime-and-gangster (1019) styles support an original-audio scene count, and the English narration style carries its language flag.

Advanced usage: where the Skill becomes a system

The Skill edits one video. That sentence is a limit and an invitation at the same time. Because the editing is a command-line pipeline invoked by an agent, everything past a single video is orchestration, and orchestration is where the leverage is.

Fork a style for a signature look

The first advanced move is the one the Skill is designed for: making your own style. Copy a style YAML to a new ID, rewrite its creative layers to encode your channel's voice, tune its speech rate and pick its music, and you have a preset that produces your look on demand.

cp reference/styles/style-1000.yaml reference/styles/style-2001.yaml
# edit reference/styles/style-2001.yaml

This is more powerful than it looks. The creative layer is prose — you are writing a director persona in plain language, with rules and boundaries and examples. The food-documentary style shows how far you can push this: a set of hard rules that reliably bends the model toward one specific aesthetic. Your custom style can be just as opinionated.

This is the difference between a channel that looks like everyone else's templates and one that has a recognizable hand behind it. The signature look is the highest tier of using the Skill, and it costs you one YAML file.

Batch a folder into a consistent series

The second move is batching, and the Skill's documentation treats it as a primary scenario rather than a workaround. You ask your agent — Claude Code or Codex — to run the Skill over every clip in a directory with the same style and shot count, collect each final.mp4 into an output folder named after its source, and write a summary table of duration and shot count per video.

Ten raw clips go in; one consistent series comes out, same look and same pacing on every one. The Skill did not gain a batch feature; your agent supplied the loop. That is the composability argument made concrete.

Schedule it

The third move is scheduling. Wire the batch loop to cron or launchd and new recordings get edited overnight without you present. This is the point where editing stops being a task you do and becomes a process that runs.

The Skill's recommended workflow tiers name this explicitly: starter (one video at a time), batch (a folder into a series with a shell loop or Codex script), scheduled (auto-edit new recordings on a timer), and signature look (your own YAML presets per channel or client). You climb the tiers as your volume demands, not before.

Repurpose one source into many cuts

The fourth move exploits the fact that style is a parameter. From a single interview recording you can ask for three cuts: a film-recap-style highlight reel, a commentary-style sixty-second short, and a straight explainer with English narration. One recording feeds a whole content calendar — long form, short form, and repurposed — because changing the deliverable is changing an argument, not re-editing from scratch.

You can even A/B two styles on the same clip and let the agent watch the first ten seconds of each and judge which opening hook lands faster. That is a use of the Skill that a timeline editor simply cannot match, because the marginal cost of a second version is another pipeline run, not another hour of labor.

The honest ceiling

It is worth naming what the Skill does not do, so the advanced picture is complete. It processes one video per run, so multi-source edits — cutting between two camera angles, assembling a montage from several files — are not in scope. It has no sub-agent fan-out, so a single run is as fast as its sequential steps. Its intelligence is rented from two paid APIs, so cost scales with volume and the quality of the analysis is the quality of Gemini on your footage.

These are not bugs; they are the shape of a deliberately focused tool. Knowing them tells you exactly when to reach for the Skill and when to reach for something else.

The AWP ecosystem

The video-editing Skill is one piece of a set of open-source AI-workflow tools from AI Workflow Pro, each built on the same premise: turn a repeatable AI task into a system you can run rather than a prompt you re-type. If the Skill is useful to you, the sister projects are likely to be as well.

Repository What It Is Article
awp-workflow-agent-spec Specification for production-grade Claude Code Skills Claude Code Skill Development Guide
awesome-rss-feeds-list 8,936+ curated English RSS feeds across 21 categories RSS Feeds Guide
awesome-ai-practices-list AI best practices, auto-curated every 6h by DigestOps AI Practices Guide
awp-agent-occupational-os 98 occupational roles for AI agents Agent OS Guide

The connective tissue is the Skill format itself. The awp-workflow-agent-spec is the specification the video-editing Skill is built against — if you want to write your own production-grade Skill, that is where the rules live. The video-editing Skill is a worked example of that spec: SKILL.md contract, tight tool allowlist, resumable pipeline, plain-text presets you own.

Frequently asked questions

Do I need to know how to use FFmpeg or a video editor to use this Skill?
No. The Skill runs FFmpeg for you through its bundled static binary, and there is no timeline or editor to learn. You interact with it in plain language through Claude Code. Familiarity with the command line helps for install and for the advanced batch and scheduling workflows, but the basic loop is install, add keys, and type one sentence.

What API keys do I need, and are they free?
Two keys, both required: Google Gemini (from AI Studio) for video analysis and narration, and Fish Audio for voiceover. Both are paid, per-use services. FFmpeg composition runs locally and free, but the analysis and voiceover steps cost money per video. Start with short clips while you learn the behavior, and treat cost as scaling with the number and length of videos you process.

Can it produce English videos, or is it Chinese-only?
It produces both, but its default narration language is Chinese. To get English output, choose the English Narration style (ID 1020) or set the narration language parameter to en-US in custom mode. English is a first-class, calibrated option — the English Narration style runs at 2.63 words per second — but it is one you select rather than the default.

How does it keep the narration in sync with the footage?
Two mechanisms. First, every style declares a calibrated speech rate (characters or words per second), and the pipeline computes a precise target word count from each shot's duration, then instructs the model to write narration that hits that count. Shot duration is treated as fixed; narration is fitted to it. Second, after voicing, the pipeline applies a bounded speed factor (0.5 to 1.5) to close any remaining gap between the audio and the shot. Calibration gets it close; the speed factor locks it.

How many styles are there, and can I make my own?
There are 22 built-in styles across five verticals: commentary, film and entertainment, knowledge and documentary, lifestyle and nature, and e-commerce and short video. Each is a plain YAML file you can read and fork. To make your own, copy an existing style, rewrite its two creative layers and its config block, and save it under a new ID. Nothing else in the Skill needs to change.

Can it edit a whole folder of videos at once?
Not in a single run — the Skill is single-video mode by design. But because it is a command-line pipeline invoked by an agent, you orchestrate batching from outside: ask Claude Code or Codex to loop the Skill over every clip in a directory with the same style. The repository treats this as a primary use case and documents workflow tiers from single-video to scheduled overnight batches.

What does it actually output?
A timestamped run folder whose output/ directory contains final.mp4 (the finished cut with burned-in subtitles and voiceover) and report.md (the run report with key parameters and an output manifest). The intermediate step folders are preserved too, so you can inspect exactly what the pipeline did, including the storyboard.json that records every scene, timestamp, and narration line.

Is my footage uploaded somewhere?
Only to Google Gemini, for the analysis step. That is the one point where your video leaves your machine. Everything else — splitting, jump-cut trimming, subtitle rendering, composition — runs locally on the bundled FFmpeg, and the voiceover step sends text (not video) to Fish Audio. Your footage is not handed to a general-purpose editing platform; it stays on your disk except for the Gemini analysis call.

What are the hard limits I should know before I install?
Four. It edits one video per run. It needs two paid API keys. Its defaults are tuned for Chinese with English as an explicit option. And it is a focused single-source tool — a focused first release, not a mature multi-source editor. If you need multi-camera editing or a zero-cost tool, this is not it. If you ship single-source narrated video regularly and live in Claude Code, it fits.

How is this different from a traditional AI video app?
An app renting you its pipeline gives you its UI, its defaults, and its ceiling. This Skill gives you a directory of files you own: readable YAML styles you can fork, a JSON config you can tune, and a pipeline an agent can loop and schedule. The trade is convenience for control. If you want drag-and-drop, an app is easier. If you want a signature look, batching, and scheduling, the Skill's openness is the point.

Who this is for, and who it is not

The clearest way to decide whether to install the Skill is to check yourself against its shape, honestly.

It is for you if you ship narrated, single-source video on a regular cadence: explainers from screen recordings, product cuts from a single take, recaps and commentary over existing footage. It is for you if you already work inside Claude Code or Codex and think in terms of pipelines and parameters rather than timelines and playheads. It is for you if you want a signature look you can encode once and reproduce on demand, and if the idea of forking a plain-text style file to bend the model's voice sounds like control rather than homework. And it is for you if you are comfortable that the intelligence is rented — that a per-video cost buys you Gemini's analysis and Fish Audio's voice, and that the output is only as good as those services are on your material.

It is not for you if your work is multi-source: cutting between camera angles, assembling montages from many clips, or building anything that needs several files reasoned about together. The Skill is single-video by design, and no amount of orchestration changes that a single run sees one file. It is not for you if you need a zero-cost tool, because two of the eight steps are paid API calls and there is no free path around them. It is not for you if you want a graphical, drag-and-drop experience with previews and manual override at every step — that is an application, and this is deliberately not one. And if your footage genuinely cannot be uploaded to any cloud service at all, note that the analysis step does send the video to Gemini; the rest is local, but that one call is unavoidable in the current design.

The honest summary is that the Skill trades breadth for depth. It does not try to be a general editor. It does one narrow job — one video, narrated, voiced, subtitled, composed — and it does that job with real engineering: calibrated sync, resumable state, reproducible config, and forkable styles. If that narrow job is a job you do often, the depth is worth far more than the breadth you are giving up.

The bottom line

The awp-video-editing-skill does one thing and states it without decoration: it takes a single video and returns a finished cut, running an eight-step pipeline that analyzes the footage with Gemini, writes narration timed to each shot, voices it with Fish Audio, trims the flicker, burns adaptive subtitles, and composes the result locally with FFmpeg. Twenty-two forkable styles carry the taste; a three-layer prompt architecture keeps that taste separate from the deterministic machinery; speech-rate calibration keeps voice and picture locked together.

It is not a consumer app and it does not pretend to be. It costs money per video, it edits one file at a time, and its English output is an option you choose rather than a default you inherit. But for the specific person it is built for — someone shipping narrated single-source video on a regular cadence, already working inside Claude Code or Codex — it deletes the mechanical 80% of the job and leaves the creative 20% where it belongs. That is a narrow promise, kept precisely, which is the only kind worth making.

Clone it, point it at a two-minute clip, and read the storyboard.json it produces. That file — every scene, every timestamp, every narration line the model chose — is the fastest way to understand whether this belongs in your workflow. The repository is open under the MIT license; the cost of finding out is one short video.

Successfully subscribed! Check your inbox for confirmation.

Successfully subscribed! Check your inbox for confirmation.

Successfully subscribed! Check your inbox for confirmation.

Successfully subscribed! Check your inbox for confirmation.

Done.

Cancelled.