40+ Best Prompts for Claude Video Editing (2026)

Claude cannot watch your video. It has no video input: you hand it images, text, or tools. Every prompt below is built on that one fact, and it is why the prompts that work look nothing like "edit my video, make it good."

What Claude is extremely good at is the part of editing that is really decision-making — which 40 seconds of a 70-minute recording are worth keeping, where the cuts land, what the captions say, which frame is the thumbnail — plus writing and running the commands that execute those decisions. Give it a transcript, a folder of frames, and a shell, and it edits.

The 46 prompts below are grouped by the job they do. Square-bracket tokens like [CLIP] are yours to replace. Most assume Claude Code, because that is the surface where Claude can run ffmpeg against files on your disk; the planning and writing prompts work just as well in the Claude app.

Before you paste anything

Four things decide whether these work:

• Claude reads frames, not footage. Pull stills with ffmpeg first (prompt 25 does this), then attach them. Current Claude models take images; none take an MP4.
• Claude does not transcribe audio. Run Whisper or any ASR tool first and hand Claude the transcript with timestamps. That transcript is the single highest-leverage input in this whole list.
• A 70-minute transcript fits easily. Current Claude models carry a 1M-token context, so paste the whole thing rather than chunking it — the best cuts come from Claude seeing the full arc.
• Say which model you want for the job. claude-opus-5-5 is the sensible default; claude-haiku-5-5 is the cheap one for bulk passes over many transcripts; claude-fable-5-1 is for a long, messy edit you want reasoned about properly.

One safety rule worth setting once, before any of the file-touching prompts: never let Claude overwrite your originals. Several prompts below encode that; prompt 10 makes it a standing rule.

The paper edit: cutting from the transcript

This is where the time is actually saved. Claude reads the transcript, decides the edit, and gives you an EDL you can execute.

1. The first-pass paper edit

Here is a timestamped transcript of a [LENGTH]-minute [TYPE: interview / tutorial / podcast] recording.

Produce a paper edit that cuts it to [TARGET LENGTH] minutes.

Rules:
- Keep the strongest version of each idea; when something is said twice, keep the clearer take and tell me which one you dropped.
- Never cut mid-sentence. Cuts land in the natural pause between sentences.
- Preserve the logical order unless reordering makes the argument stronger — if you reorder, say so and why.
- Output a table: start timecode, end timecode, speaker, first five words, reason for keeping.

At the end, list what you cut that you were least sure about.

Why it works: asking for the uncertain cuts at the end is the whole trick. That list is where the one good line it nearly lost usually shows up, and it takes you thirty seconds to scan.

2. Filler and false-start removal

From this transcript, list every segment to remove: filler words, false starts, repeated words, long pauses, and tangents that go nowhere.

Do not remove: pauses that land after a punchline or a question, verbal tics that are part of how this person talks, or anything that would make the delivery sound robotic.

Output as a cut list of [start, end] timecodes only, sorted ascending, with no overlaps.

Why it works: the "do not remove" block is doing the real work. Without it you get a technically clean edit that sounds like a machine stripped the breathing out of it, because that is exactly what happened.

3. Turn the paper edit into a cutting script

Take the cut list above and write a bash script that cuts [SOURCE FILE] accordingly.

Requirements:
- Frame-accurate cuts, so re-encode rather than stream-copy: libx264, -crf 18, -preset slow, -pix_fmt yuv420p, AAC audio at 192k.
- Each segment to its own file in ./segments, zero-padded names so they sort correctly.
- Then concatenate with the concat demuxer into [OUTPUT FILE].
- Write to a new directory. Never modify or delete the source.
- Echo each command before running it, and stop on the first error.

Why it works: naming the codec settings stops the guessing, and "frame-accurate, so re-encode" pre-empts the classic failure where -c copy snaps every cut to the nearest keyframe and the edit drifts by up to a second.

4. Find the story in a rambling recording

This transcript is a [LENGTH]-minute unstructured recording about [TOPIC].

Before suggesting any cuts, tell me what the actual story is: the single claim this could be about, the three beats that support it, and the ending it already has somewhere in the material.

Then tell me which sections serve that story and which are a different video.

Why it works: it separates the decision from the execution. Ask for cuts first and you get a shorter version of a shapeless recording; ask for the story first and the cuts become obvious.

5. The B-roll plan

Read this transcript and mark every place where the audio would be better with something else on screen.

For each one give me:
- The timecode range
- What is being said
- What should be on screen instead, described concretely enough to film or to search a stock library for
- Whether it needs to be literal (showing the thing) or atmospheric (covering a talking head)

Flag any claim that needs an on-screen citation, chart or screen recording to be believable.

Why it works: the literal-versus-atmospheric distinction is what separates a usable list from "add relevant B-roll here" forty times.

6. Chapter markers that match how people watch

From this transcript, write YouTube chapters for a [LENGTH]-minute video.

Rules:
- First chapter starts at 00:00.
- Minimum 10 seconds apart, between 5 and 9 chapters total.
- Title each chapter by what the viewer gets, not by what happens: "Why the first cut is wrong", not "Introduction".
- No chapter title over 40 characters.

Output exactly as YouTube expects: timecode, space, title, one per line.

7. Pull a cold open

Find the best 8-15 seconds in this transcript to use as a cold open before the title card.

It must: work with no setup, make a specific claim or ask a specific question, and end on a beat that justifies the cut.

Give me three candidates ranked, with timecodes, and say what each one promises the viewer — because the video has to then deliver it.

Why it works: "say what each one promises" catches the hook that is exciting but writes a cheque the video never pays, which is the main cause of a strong open and a terrible retention graph.

8. Two-speaker interview cleanup

This is a two-speaker interview transcript. [HOST] is the interviewer.

Cut it so the guest does 80% of the talking. Compress the host's questions to their shortest clear form, keep any question that genuinely changes direction, and remove agreement noises entirely.

Mark every place where the host's question could be replaced by an on-screen text card instead, with the exact words for the card.

Cutting and assembly

9. The silence cut (jump-cut pass)

Using ffmpeg's silencedetect on [SOURCE FILE], find every silence longer than [0.6] seconds below [-32] dB.

Then build a cut list that removes them but leaves [120] milliseconds of room tone at each end of every cut, so the result does not sound clipped.

Show me the detected silences and the total time saved before you cut anything.

Why it works: the retained room tone is the difference between a jump-cut edit and an edit that sounds like a bad phone call. Ask for the summary first and you catch a bad threshold before it has mangled a 40-minute file.

10. The standing safety rule

For everything we do in this project:
- Treat ./source as read-only. Never write, move, rename or delete anything inside it.
- All output goes to ./out, which you may create.
- Before any destructive or long-running command, show it to me and wait.
- Never run a command that would take more than [10] minutes without telling me first and estimating the time.

Why it works: put this in CLAUDE.md rather than a chat message and it applies to every session in the folder, which is the only version of this rule that survives a long day.

11. Trim without re-encoding

Trim [SOURCE FILE] from [IN] to [OUT] without re-encoding, using stream copy.

Tell me where the nearest keyframes actually are first. If the requested in-point is more than [0.5] seconds from a keyframe, say so and ask whether I want the fast copy or a frame-accurate re-encode.

12. Batch the same edit over a folder

Apply the same treatment to every .mp4 in [FOLDER]: [DESCRIBE: trim first 3s, normalise audio, export 1080p].

Process them one at a time, print a progress line per file, and write a summary table at the end with input name, output name, duration before, duration after, and file size.

If one file fails, keep going and list the failures at the end.

13. Transitions, only where they earn it

Here is my cut list. Propose transitions.

Default to a hard cut. Only suggest something else where there is a real reason: a time jump, a location change, or a change of subject. For each non-cut transition, give me the ffmpeg xfade type, the duration in frames, and one line on why a hard cut is worse there.

I expect most of these to stay hard cuts.

Why it works: the last line sets the prior. Without it you get a dissolve between every clip, because "propose transitions" reads as "propose many transitions."

14. Speed-ramp the boring parts

In this screen recording, find every stretch where nothing meaningful changes for more than [4] seconds — waiting on a load, typing a long command, scrolling.

For each, give me the timecode range and a suggested speed multiplier (2x-8x) based on how much actually happens in it. Then write the ffmpeg filter chain that applies them, keeping audio in sync and dropping audio entirely on anything above 3x.

15. Stitch a multi-cam recording

I have [N] camera angles of the same [LENGTH] recording: [FILES]. They start at different times.

Use the audio tracks to work out the offset between them, tell me the offsets you found and how confident you are, and then write the commands that align them to a common timeline.

Do not cut between angles yet — I want the aligned files first.

16. The rough cut, start to finish

You have: [SOURCE FILE], its transcript at [PATH], and a folder of B-roll at [PATH].

Build me a rough cut of [TARGET LENGTH]:
1. Propose the paper edit and wait for my approval.
2. Cut the A-roll to the approved list.
3. Lay B-roll over the ranges we agreed, cutting on sentence boundaries.
4. Normalise the audio and export 1080p H.264.

Stop after step 1 and show me your work.

Why it works: the numbered plan plus an explicit stop point. Long agentic edits fail when Claude runs all four steps on a paper edit you would have rejected.

Captions and subtitles

17. Clean up the ASR output

This SRT came out of [Whisper / your ASR tool]. Fix it without changing what anyone said:
- Correct proper nouns, product names and technical terms. Here is the vocabulary it keeps getting wrong: [LIST].
- Fix punctuation and capitalisation.
- Never alter a timecode.
- Never merge or split a cue.

List every word you changed, so I can check it.

Why it works: ASR errors cluster in exactly the words that matter — names, products, jargon. Giving Claude the vocabulary list up front fixes more than any amount of "be accurate."

18. Re-time captions for reading, not for speech

Re-cue this SRT for readability:
- Maximum [42] characters per line, maximum 2 lines per cue.
- Minimum 1 second and maximum 6 seconds on screen.
- Break lines at grammatical boundaries — never between an article and its noun, never splitting a name.
- Keep each cue inside the speech it belongs to.

Output valid SRT only.

19. Burn in styled captions

Burn [SUBTITLE FILE] into [VIDEO] using the subtitles filter.

Style: [FONT] at a size that reads on a phone, white with a [2]px black outline, no box, positioned [15]% up from the bottom so platform UI does not cover it.

Show me a single burned-in frame at [TIMECODE] before processing the whole file.

Why it works: the one-frame preview. Caption styling is a thing you get wrong twice and then right, and each wrong attempt otherwise costs a full encode.

20. Word-level captions for short form

From this word-level timestamped transcript, generate an ASS subtitle file with one or two words on screen at a time, each word appearing exactly when it is spoken.

Highlight the single most important word in each sentence in [COLOUR]. Choose it by meaning, not by length.

Keep the text inside the middle [60]% of a 9:16 frame.

21. Translate subtitles that still fit

Translate this SRT into [LANGUAGE].

Constraints:
- Timecodes stay exactly as they are.
- Each cue must be readable in the time it is on screen — if the natural translation is too long, shorten the phrasing rather than the meaning.
- Keep [PRODUCT NAMES / technical terms] untranslated.
- Match the register of the original: [casual / formal].

Where you had to compress a line, mark it with a comment so I can review it.

22. The caption QC pass

Check this subtitle file against the video's transcript and report only problems:
- Cues that overlap or run out of order
- Cues shorter than [1] second or longer than [6]
- Lines over [42] characters
- Text that does not match what is said
- Any cue that spans a hard cut

Output a table of issues with timecodes. If there are none, say so in one line.

Why it works: "report only problems" and the explicit "if there are none, say so in one line" stop the model from restating your whole file back to you.

The look: frames, colour and framing

23. Grade from a reference frame

Attached: a frame from my footage, and a reference frame from [SOURCE] with the look I want.

Describe the difference in terms I can apply: exposure, contrast curve, white balance, saturation by colour range, and where the shadows and highlights sit.

Then give me an ffmpeg filter chain that moves my frame toward the reference. Conservative first pass — I would rather go twice than overshoot.

Why it works: it uses vision for what vision is genuinely good at — comparing two images — instead of asking it to imagine a look from a description.

24. The continuity and consistency check

Attached are frames taken every [30] seconds through the finished edit.

Find the inconsistencies: shots where exposure or white balance jumps, framing that drifts, a light that changes, anything on screen that appears or disappears between adjacent shots.

List them by frame number with what changed. Ignore intentional cuts between locations.

25. Extract frames to look at

From [VIDEO], extract one frame every [5] seconds into ./frames as JPEGs named by timecode.

Then build contact sheets of [25] frames each, with the timecode printed on every frame, so I can attach them to you in batches.

Why it works: the printed timecode is the point. Without it, Claude can tell you something is wrong in frame 14 and you cannot find frame 14 in the timeline.

26. Pick the thumbnail

Here are [N] candidate frames.

Rank them as a thumbnail for a video titled "[TITLE]". Judge: does the face read at 120px wide, is there empty space for text, is the subject separated from the background, would it be legible on a phone in a bright room.

Give me the top three, the reason each works, and where the text should sit on each one.

27. Reframe to vertical without decapitating anyone

I need [CLIP] as 9:16 from a 16:9 source.

Look at the attached frames first and tell me where the subject actually sits in each shot. Then give me a crop plan: a static crop where the subject holds still, and an animated crop where they move.

Flag any shot where a 9:16 crop loses something essential — a second person, on-screen text, a chart — because those need a different treatment.

28. Check text against platform UI

Attached: frames from my [vertical / horizontal] edit with on-screen text.

Mark anything that will be covered by platform UI on [TikTok / Reels / Shorts]: the caption block, the action rail on the right, and the progress bar.

For each problem, tell me how far to move it in percent of frame height or width.

29. Clean up a screen recording

This is a screen recording at [RESOLUTION]. Make it watchable at 1080p:
- Crop to the region that actually matters: [DESCRIBE or "look at the attached frame and decide"].
- Scale with a sharp scaler, since text must stay legible.
- Tell me if the source resolution means the text will be soft no matter what, before processing.

Short form: clips, hooks and verticals

30. Find the clippable moments

From this [LENGTH]-minute transcript, find the [8] best standalone clips of 20-60 seconds.

Each must: make sense with zero context, contain one complete idea, and start on a strong first line rather than building up to one.

For each give me: timecodes, the opening line verbatim, what makes it work, and a one-line judgement of whether it is genuinely strong or merely acceptable. I would rather have 3 strong ones than 8 average ones — tell me honestly which is which.

Why it works: asking for an honest split stops the model padding to the number you asked for, which it will otherwise do every time.

31. Rewrite the first three seconds

Here is the opening line of a clip: "[LINE]".

Write [5] alternative openings that could be said by the same person in the same voice, each under [12] words. Rules: no "in this video", no questions that invite "no", no hype adjectives.

Mark which ones change the meaning of what was actually said — I can only use the ones that do not.

32. Match each clip to a platform

Here are [N] clips with their transcripts and durations.

For each, tell me which of [TikTok / Reels / Shorts / LinkedIn / X] it fits best and why, based on the content and pacing rather than the format. Say which ones should not be posted anywhere as they are, and what they need first.

33. On-screen text for a silent viewer

Write the on-screen text for this [DURATION]-second clip so it works with the sound off.

Rules:
- Maximum [6] words per card.
- A new card only when the point changes, never on a timer.
- The text carries the argument — it does not repeat the caption word for word.

Output as timecode, duration, text.

34. Assemble a vertical clip end to end

Take [SOURCE] from [IN] to [OUT] and produce a 1080x1920 clip:
- Crop to [the subject / centre], do not stretch.
- Burn in captions from [FILE] styled for phone viewing.
- Normalise loudness to -14 LUFS.
- Fade audio in and out over [200]ms so it does not start with a click.
- Export H.264, yuv420p, under [100]MB.

Show me the command before running it.

35. Turn one recording into a series

This transcript covers [TOPIC] in [LENGTH] minutes.

Plan a series of [5] short videos from it. Each needs its own complete idea, not a chunk of the whole. For each: the timecodes, a title, the hook line, and what it leaves the viewer wanting from the next one.

Tell me if the material does not actually support five — four good ones beats five with filler.

36. The retention edit

Here is the transcript of a clip and its retention graph data: [PASTE or describe where viewers drop].

Tell me what is happening in the video at each drop-off point and what specifically to change — a cut, a reorder, a missing visual, or a promise the opening made and this section does not keep.

Do not suggest "add more energy."

Audio

37. Normalise loudness properly

Normalise the audio of [FILE] to [-14] LUFS integrated with a true peak ceiling of -1 dBTP, using ffmpeg's two-pass loudnorm.

Report the measured values before and after. If the source is more than [6] LU away from target, tell me first — that usually means something is wrong with the recording rather than the level.

Why it works: two-pass is the part people skip, and the before-and-after numbers are what let you catch a recording that is quiet because it was clipped and then turned down.

38. Diagnose the room before fixing it

Analyse the audio of [FILE] and tell me what is actually wrong with it: noise floor, hum and its frequency, room reflections, plosives, sibilance, clipping.

Rank the problems by how much each one hurts, then fix them one at a time starting with the worst — showing me the command and letting me listen before moving to the next.

Do not stack five filters at once.

39. A music bed that gets out of the way

Add [MUSIC FILE] under [VIDEO] as a bed:
- Sidechain-duck the music against the voice so speech always sits clearly on top.
- Music at roughly [-22] LUFS where there is speech, [-16] where there is none.
- Fade in over [2]s, out over [3]s, and end exactly with the video.

Tell me the resulting integrated loudness of the mix.

40. Swap the audio track

Replace the audio of [VIDEO] with [NEW AUDIO], keeping the video stream untouched by stream-copying it.

Check the durations first and tell me the difference. If they do not match, ask me whether to pad, trim or re-sync rather than guessing.

41. Find the usable takes

This transcript contains [N] takes of the same [script / answer], separated by me saying "[MARKER]".

Compare them: which is clearest, which has the best delivery, where one take has a better first half and another a better second half. If a composite of two takes would be stronger, give me the exact cut point and say whether the audio will match across it.

Titles, graphics and delivery

42. Lower thirds from the transcript

Read this transcript and tell me every place a lower third is needed: a new speaker, a name, a company, a term that needs defining.

For each: the timecode, the exact text (name on line one, role on line two, under [30] characters per line), and how long it should stay up.

Do not add one where the audio already makes it clear.

43. An animated title card, as code

Build a [DURATION]-second animated title card as an HTML page I can record at [1920x1080]:
- Title: "[TITLE]", subtitle: "[SUBTITLE]"
- Brand colours [HEX], [HEX]; background [HEX]
- Animation: [DESCRIBE] — restrained, no bounce
- Everything must be deterministic and seekable, with no random values, so the recording is reproducible.

Then give me the ffmpeg command to capture it to a transparent-background MOV.

Why it works: "deterministic and seekable" is the instruction that makes a recorded animation reproducible rather than slightly different on every take.

44. The export matrix

Export [MASTER FILE] for: [YouTube 1080p, Instagram Reels, LinkedIn, an email-embeddable version under 10MB].

For each, pick the codec, resolution, bitrate, loudness target and container, and tell me what you traded away on the small one. Write all four with one script, print the resulting file sizes, and never re-encode from an already-encoded export — always from the master.

Why it works: "never re-encode from an export" is the rule that keeps generation loss out of the version that ends up on the biggest platform.

45. The metadata pass

From this transcript, write the publishing package for [PLATFORM]:
- [3] title options, under [60] characters, each promising something the video actually delivers
- A description with the real summary in the first two lines
- Chapters
- [10] tags

No clickbait, no emoji, and nothing that is not in the video.

46. The final QC before you publish

Before I publish [FILE], check it and report only what is wrong:
- Duration, resolution, frame rate, codec, bitrate
- Integrated loudness and true peak against [-14] LUFS / -1 dBTP
- Black frames or silence at the start or end
- Audio/video sync drift between the start and the end of the file
- Any frame where burned-in text is cut off

Then show me frames from the first and last [2] seconds so I can see how it opens and closes.

Making these yours

Three edits turn any prompt above into one that fits your work:

• Put the constraint before the task. "Never cut mid-sentence. Now produce a paper edit" beats the same two sentences reversed, because the rule is in place before the work starts.
• Ask for the judgement, not just the output. Every prompt here that asks "which of these is actually strong" or "what were you least sure about" returns something you would not have got otherwise, and it costs one line.
• Make it stop. On any multi-step edit, say where to pause. The approval point after the paper edit is worth more than every other optimisation in this list, because that is the step where a wrong decision gets baked into forty minutes of rendering.

Keep the ones that work in a prompts/ folder next to the project, or in CLAUDE.md if they are rules rather than tasks. A prompt you have tuned twice is worth more than a new one you are about to tune for the first time.

A note on these prompts

These were written for Claude as it works in October 2026: no video input, images and text only, a 1M-token context on current models, and a shell when you run it through Claude Code. If Claude gains direct video input, the transcript-and-frames prompts here become shortcuts rather than requirements — the editorial judgement they ask for stays the same. Encoding settings (CRF values, loudness targets, caption line lengths) are starting points that match current platform norms, not fixed rules.