Style Skill Driven Video Editing Agent

Style Skill Driven Video Editing Agent

What it does

Accepts natural-language editing intent, applies reusable Style Skills (pacing, transitions, B-roll patterns), plans edits with LLM reasoning, and hands off to human review before execution.

When to use

• User describes edits in plain language ("make it punchier", "add B-roll over narration")
• Need to reuse editing styles across projects
• Human-in-the-loop review before final cut

Inputs

• Source footage metadata (clips, durations, transcripts optional)
• Editing intent (natural language)
• Style Skill definition (optional; use default if absent)

Outputs

• Edit plan (ordered EDL-style decisions)
• Style Skill application notes
• Human review checkpoint list

Style Skill template

• name — fast-montage
• pacing — 1.5–3s per cut
• transitions — hard cut, occasional whip
• b_roll — overlay on keywords
• audio — duck music under dialogue

Steps

1. Parse editing intent and load Style Skill.
2. Inventory source clips and transcript segments (if available).
3. Generate edit plan: in/out points, transitions, B-roll inserts.
4. Flag ambiguous decisions for human review.
5. Output EDL-style plan; do NOT execute without approval.

Quality checklist

• Every cut has in/out rationale
  
• Style Skill rules applied consistently
  
• Ambiguous segments flagged for review
  
• Total runtime within target range
  

What we found running it

Four tasks, each run with the skill installed and again with skills disabled, same task text. Both arms returned a cut plan with in/out points and per-cut reasoning every time. The difference is what survives the job.

Only task 1 supplied a style definition (fast-montage). In the other three the brief was a mood — warm and welcoming, something we can send to family, emphasise the steps with card transitions — and in all three the skill arm wrote the style down as a reusable file before cutting to it: warm_welcome_style_skill.yaml (2,025 B) pinning 7–14 s cuts, hard cuts between people and dissolves between empty frames, music ducking, a warm grade; style_skill_求婚纪实剪辑.yaml (1,515 B) encoding the judgment calls it made about redundant takes and technical flaws; style_skill.yaml (1,411 B). The control arm produced a plan in every run and a style definition in none. If you are cutting one video, that file is overhead. If this is episode one of forty, it is the point of the skill.

The skill arm also attached a manual-review checklist to all four plans, naming the specific assumptions it could not check without the footage — six items in task 1, five in task 3, including which second the focus actually drifts. The control arm did the same in three of four.

Task 1 is the honest counterweight, and it goes the other way. With the style already supplied, the control arm's plan was the larger and arguably the more considered: 11,327 B plus a 4,177 B EDL covering 35 cuts, against 8,126 B plus 2,984 B and 18 cuts, and it opened by stating a craft rule the skill arm never articulated — that a cutaway means the picture leaves and the dialogue keeps running, not that you cut the sound too. It also cost more to get there ($0.46 against $0.41).

Cost across the four: $0.41 / $0.36 / $0.38 / $0.27 with the skill, $0.46 / $0.24 / $0.29 / $0.30 without.

What we did not test: no footage existed. Every task described its clips in a text list, so both arms were reasoning about material neither of them could see — no in-point here has been checked against a frame, and the skill arm says so itself in each review checklist. We also never re-applied a generated style file to a second video, which is the only way to find out whether these YAMLs are actually reusable or just a record of one job.

Reference repos

• FireRed-OpenStoryline, StoryToolkitAI