Automate Video Editing With OpenClaw Without Losing the Final Cut

A file named final.mp4 is a poor definition of successful video automation. It says nothing about whether the strongest take survived, whether a caption drifted after a cut, or whether the agent quietly made an editorial choice nobody approved. The useful version of this workflow keeps those decisions inspectable while automating the mechanical work around them.

The current video-use project can run through OpenClaw because it is packaged as a skill for shell-capable agents. Its pipeline is built around transcripts, an edit decision list, ffmpeg rendering, and visual checks of the rendered result. That makes it a credible first-cut system for speech-led material. It does not make it an autonomous replacement for an editor, and the repository's own hard rules do not claim that.

The practical decision is narrower: use OpenClaw with video-use when words and pauses can define most of the edit, when a human can approve the proposed strategy, and when the intermediate artifacts matter as much as the exported file. Keep a timeline editor in the loop when shot rhythm, music, performance, or frame-specific visual continuity carries the story.

The boundary worth automating

Video-use treats the transcript as the main reading surface. It asks a transcription service for word-level timing, packs the result into a compact document, and calls its visual timeline helper only at decision points. This is not the same as asking a model to “watch everything.” The agent reasons over a smaller representation, then drills into frames where a pause, retake, or boundary is ambiguous.

That design has a real advantage: every proposed segment can point back to a source file and time range. It also has an obvious limit. A transcript can expose filler words, false starts, repeated explanations, and speaker handoffs. It cannot tell you that a reaction shot is emotionally better, that a gesture should land on a musical beat, or that a wide shot needs two extra seconds of air. Those are visual and rhythmic judgments, not transcription problems.

This is why I would automate the first assembly, not surrender the final cut. Let the agent inventory media, cache transcripts, propose an outline, create an EDL, render a preview, and collect verification frames. Keep the editorial intent, disputed cuts, and release decision with a person. That division is faster to review and easier to reverse than a prompt that jumps directly from a folder of footage to an opaque export.

Installation is three separate jobs

There are three separate dependencies: video-use itself, an OpenClaw skill location, and the local media toolchain. Missing any one of them produces a confusing half-install.

Clone a reviewed revision of the repository into a stable directory. Do not paste its setup prompt into an agent and assume that counts as supply-chain review; a skill can invoke shell commands and external services. Read install.md, SKILL.md, and the helper scripts first. Pinning a commit also gives you a useful answer when a later run behaves differently.

git clone https://github.com/browser-use/video-use.git /opt/video-use
cd /opt/video-use
git checkout 92c2b34e44c205cbc2acae7f6ca7c1c219d5dd66
uv sync
ffmpeg -version
ffprobe -version

The fixed /opt path is only an example. Choose a directory writable by the operator who maintains the skill. The important detail is stability: footage and outputs belong in project folders; the installed skill should not become a dumping ground for renders.

OpenClaw discovers workspace skills as directories containing SKILL.md. Install or link the entire video-use directory under your agent workspace's skills/ tree, because SKILL.md refers to sibling helpers. Copying only the markdown file leaves the instructions pointing at code that is no longer beside it. After changing skill discovery, start a fresh agent turn and confirm that video-use appears in the loaded skill list before supplying media.

Transcription is the only required hosted service in the current video-use contract. Keep its API key in the skill environment, not in the editing prompt, transcript, or project notes. ffmpeg and ffprobe are hard runtime requirements. Animation engines and download tools are optional; installing all of them pre-emptively expands both the failure surface and the code you must trust.

Give the agent an editing contract

“Make this look good” forces an agent to invent the acceptance criteria. A better request names what may change, what must survive, and what requires approval. For a product walkthrough, that might look like this:

Inventory the files in /srv/video/demo-july.
Do not alter or delete source media.

Goal: a 90–120 second 16:9 product walkthrough.
Keep: the login warning, the failed first attempt, and the final result.
Cut candidates: repeated explanations, verbal fillers, and silence over 700 ms.
Captions: sentence case; keep them clear of the product UI.
No generated overlays in the first pass.

First return only:
1. source inventory and durations,
2. proposed story shape,
3. risky or ambiguous cuts,
4. expected output duration.

Wait for approval before writing the EDL or rendering.

The final sentence is not ceremonial. Strategy confirmation is one of video-use's documented hard rules. It is the cleanest moment to catch a missing take or a bad narrative assumption, before transcription decisions become rendered segments.

There is another useful constraint hidden in the prompt: no overlays in the first pass. Motion graphics add tools, dependencies, creative choices, and compositing failure modes. Prove the cut and captions first. Add overlays only when they explain something the footage cannot, and review each generated asset as a separate deliverable.

Read the EDL as the change request

Once the strategy is approved, the edit decision list becomes the reviewable change. Each range should name a source, start time, end time, editorial beat, quote or content description, and reason for inclusion. A reviewer should be able to challenge a segment without reopening the entire project.

Inspect five things before rendering:

• Source identity: every referenced file exists and still has the fingerprint or modification time recorded during inventory.
• Cut legality: speech cuts land on word boundaries with modest padding rather than slicing phonemes.
• Runtime math: segment durations add up to the claimed output length.
• Narrative coverage: every must-keep moment appears, and no excluded material slips back in through another take.
• Effect scope: grades, captions, and overlays are explicit rather than implied by a style adjective.

The current render helper extracts each selected segment, applies color and short audio fades, concatenates the prepared clips, then composes optional overlays and subtitles. That order matters. In particular, subtitles need the output timeline rather than the original source timestamps; otherwise every removed interval pushes later captions out of sync.

Keep the EDL, packed transcript, and render command beside the preview. If feedback arrives two days later—“restore the second explanation but keep the new captions”—those files turn the revision into a bounded change instead of a new conversation from memory.

The preview is not evidence until you inspect it

A successful process exit proves that ffmpeg created a file. It does not prove that the edit is good. Video-use's verification model samples the rendered output around cut boundaries, not merely the sources. That distinction catches failures introduced by the render itself: a flash between clips, an audio pop, an overlay that hides a caption, or a timing shift after concatenation.

Ask the agent to return a small review packet rather than “done”:

• output duration, dimensions, frame rate, audio stream, and file checksum;
• the EDL and total duration calculation;
• inspection frames for the first and last two seconds and every cut window;
• caption checks at the beginning, middle, and end;
• issues found, changes made, and the number of verification passes;
• the unresolved items that still need a human judgment.

The repository caps its self-evaluation loop rather than retrying forever. That is healthy behavior. A repeated failure at the same boundary usually needs a different cut, a repaired source, or an operator decision—not a fourth identical render.

Where the transcript-first approach breaks down

Speech-led tutorials, interviews, product demos, and talking-head material are the natural fit. Their structure is visible in language, and many undesirable moments appear as false starts, repeated phrases, or long pauses. The agent can remove mechanical review work while leaving a clear audit trail.

Music videos, cinematic montage, dance, sports, and reaction-heavy interviews are different. The decisive information lives in motion, gaze, rhythm, and continuity. A transcript can still help with dialogue, but it should not drive the assembly. The honest automation target there is narrower: inventory, proxies, transcription, caption preparation, shot metadata, or delivery checks around a human-built timeline.

Mixed screen recordings expose another edge case. Cutting on a word boundary can remove the cursor movement or loading state that proves what happened. For tutorial footage, require a visual check before and after every cut that crosses an interaction. A pause may look removable in text while being essential on screen.

Remote triggering adds operational risk as well. An always-on OpenClaw agent may have access to large media, API keys, and a writable filesystem. Constrain its working directories, keep source media read-only where practical, require approval before destructive cleanup, and never let a chat message choose an arbitrary shell path. Video editing is resource-heavy enough without turning the footage folder into a command-injection surface.

What I would ship

For a recurring speech-led series, I would keep one project directory per episode and version the editing contract. OpenClaw would inventory new takes, transcribe only changed files, produce a proposed story shape, and stop. After approval it would write an EDL and preview, run bounded verification, and deliver the review packet. A person would watch the preview at normal speed and release the final render.

I would not promise a fixed time saving. Transcription latency, source codecs, resolution, hardware, animation work, and the number of disputed cuts all change the result. I would measure four things instead: minutes of footage ingested, percentage of the proposed EDL changed by the reviewer, number of verification failures, and elapsed time from strategy approval to accepted preview. Those numbers tell you whether the automation is learning the shape of your work or simply moving review effort downstream.

The useful claim is modest and testable. OpenClaw plus video-use can make a transcript-led first cut reproducible and reviewable. It earns more autonomy only when the EDL survives scrutiny, the rendered evidence stays clean, and the operator remains able to say exactly what changed.

The record behind the decision

• video-use README at the reviewed revision
• video-use operational skill contract
• video-use render helper
• OpenClaw skills documentation

For adjacent operational patterns, see how OpenClaw skills are structured and where automated motion graphics add a separate review surface.