davinci-resolve-mcp: Skill for Claude Code

Resolve Tighten Recording

Turns one long raw take into a tightened variant timeline. The variant is the deliverable; the original timeline is never touched.

Everything below was measured live against Resolve Studio 21.0.1.11 / MCP v2.80.1 on 2026-08-06, on a real 28.5-minute 30fps screen recording, unless a different date is given.

The deliverable contract

Deliver a tightened variant timeline, plan → review → confirm. Do not grade, caption, or add anything; a tighten is pure subtraction. The variant runs generous on purpose — recovering over-cut material is slow and invisible, trimming further is fast and visible.

Two things always go back to the editor with the variant:

• The largest lifts. A lift is only silence to the microphone. Measured on real material (2026-07-31): a 29s lift was 70% silent on-screen demonstration — real content, cut because nobody spoke over it. Anything over ~15s deserves a human look before the variant is trusted.
• What silence-driven tightening cannot hear — see the last section.

Workflow

1. Lift the analysis caps for long media — media_analysis set_caps_preset {preset: "unlimited"}. The standard preset carries a 90-second wall clock; multi-hour material dies on it. Restore standard when done (step 7).

2. Transcribe — media_analysis start_batch_job with {clip_id, vision: false, transcription: {enabled: true, ...}}, then run_batch_job_slice {job_id}. Two traps in one call pair:

   • Batch jobs do not advance themselves. start_batch_job returns a durable job in queued and nothing runs until a slice call drives it.
   • run_batch_job_slice blocks until the slice completes — budget roughly 4-7x realtime for local whisper (measured: 28.5min of Chinese speech in 5m14s via mlx_whisper) and run it from a background process, not the main conversation.

   Copy clip_id from media_pool probe_media_pool output. Never type it from memory: one transposed hex pair (measured 2026-06: b9ab → 9bab) fails every downstream call in ways that look like engine bugs.

3. Plan — edit_engine plan_tighten {timeline_name}. Dry run; nothing moves. min_pause_seconds raises the bar when the default cuts too fine-grained. The plan persists on disk — planning and executing in different sessions is fine.

4. Review with the editor: lift count, estimated removed seconds, and the largest lifts (sorted by duration). This is the approval gate the whole tool sequence exists for — do not skip it because the numbers look reasonable.

5. Execute — edit_engine execute_tighten {plan_id} returns a confirm_token (TTL 300s); re-call with the token. Both calls in the same MCP session is verified; a token across a server restart is not — don't bet on it.

6. Verify, in this order:

   • timeline detect_gaps_overlaps on the variant → must be 0 / 0.
   • readback.after.clip_count in the execute response ≈ 2× the video keep-range count when audio is mirrored (113 video + 113 audio = 226 measured). If it equals the video count alone, the variant is silent — stop and say so.
   • Spot-check placement with timeline clip_where {track_type, track_index} against the plan's keep ranges (coordinate rules below). clip_where reads the current timeline only — set_current to the variant first; it takes no timeline_name argument.
   • Total duration ≈ original − estimated_removed_seconds.

7. Clean up — restore set_caps_preset {preset: "standard"}, project_manager save, and list timelines: execute_tighten archives the source timeline once (_versioning.archived: true, by design), so a *_archived_vNN appears. Surface it; deleting is the editor's call.