Commentary Driven Video Editing

Give it a timestamped transcript and the constraints you actually care about — platform, target length, tone — and it returns a narration script broken into beats, each one carrying a timecode that points at real footage you already have.

What it is

Editing a narrated video usually fails in one of two ways. You watch the footage, write the script from memory, and then discover that three of your lines have no matching picture — so you invent timecodes and hope. Or you write the script first and then scrub the source frame by frame looking for the shots, which is slow and quietly wrong: you end up giving the same screen time to the one demo that sells the product and to the filler around it.

This skill puts the mapping first. It reads the transcript, decides which moments carry the argument, writes the narration to that spine, and then points every line back at an in/out point that exists. What comes out is a timeline table, not a video — a script and an edit decision list that a voice artist and an editor can both work from without asking you what you meant.

It is methodology, not machinery. Two files, no scripts, no API keys, nothing to install beyond copying a folder. It does not transcribe for you and it does not render. You bring the transcript; it gives you the plan.

How it works

Five steps, then a checklist it holds the result against.

1. Analyze — read the source, pull out the moments that carry information.
2. Write the commentary — write narration against those beats, each beat timestamped.
3. Map back to footage — every beat gets an in/out point in the original material.
4. Generate the edit plan — an edit decision list with narration sync markers.
5. Export — hand off to TTS and assembly.

The checklist is where it earns its keep, because these are the four things people get wrong by feel:

• The script's pacing fits the target length — not "roughly", it is checked against the number.
• Every narration beat has footage behind it. No orphan lines.
• There is a hook inside the first three seconds.
• No dead air, no segments that don't match anything.

None of this is tied to a vendor. Swap the transcription service or the voice model and the judgement — find the moments, write to beats, map back, check the pacing — still holds.

What's in it

• SKILL.md — 1.3 KB. The methodology: five steps and the acceptance checklist. Prompt-level guidance, no API calls.
• examples/output-commentary-edit-plan.json — 1.5 KB. One worked output, a public-safety short, showing the shape it produces: commentary segments with hook markers and source in/out points, an edit-decision timeline, and a target_duration_s.

Both files are methodology. There is no execution shell here — nothing that would need rewriting if you changed providers.

What to know going in

It plans, it does not cut. The output is a script plus an edit decision list. Rendering is still your job, or your editor's.

You supply the transcript. It works from a timestamped transcript, or from a semantic shot list when no timecodes exist. It will not produce one for you.

Nothing runs, so nothing costs. No keys, no dependencies, no per-use billing. That also means there is no code enforcing the checklist — the discipline lives in the prompt.

It is small. Two files. What you are installing is a way of thinking about the cut, not a tool.

What we found running it

Three tasks, each run with the skill and with skills disabled, same task text. Both arms completed all three and the file counts came out near-identical (8 against 9). The consistent difference is that the skill arm always emits the edit decision list as its own artifact — edit_decision_list.md (3,969 B), 02_剪辑决策表_EDL.md (3,550 B), edl.csv (1,818 B) — separate from the narration script. In task 3 that meant a machine-readable CSV with in/out points in discrete columns, importable into Premiere or Resolve; the control arm returned the same decisions as a markdown table only.

The control arm compensates by going wider rather than deeper. In task 1 it shipped five files against the skill arm's three, adding cut_video.sh (1,703 B) and a separate Xiaohongshu caption — useful, but neither was asked for. Beat segmentation differed slightly and defensibly: eight beats under the skill against nine without, working from the same script in task 3.

The clearest limitation is the one stated above: neither arm cuts video. Both produce plans. In task 1 the source recording was not present in the sandbox, and the control arm said so explicitly before writing its execution package. That means we never verified a single timecode against real footage — the in/out points in every artifact here are proposals derived from the transcript we supplied, and their accuracy against actual frames is untested.

Three tasks is a thin sample, and all three handed over a clean timestamped transcript or shot list. We have no evidence about what happens when the transcript is noisy, unsegmented, or missing.

Installing

Create .claude/skills in your project, then copy the folder into it as commentary-driven-video-editing. Two files, nothing to build.

Once it is in place, asking for a narrated cut — "turn this screen recording into a 90-second explainer", "write me the voiceover and find the shots" — triggers it.