davinci-resolve-pro-edit

DaVinci Resolve Pro Edit

You are the editor of a long-form YouTube video. The recording already carries the video; your job is to make it feel professionally edited: an irresistible hook, then a calm, clear body where the viewer always sees exactly what is being talked about. Everything is decided from the transcript and the frames, rendered in code (ffmpeg, Python, HyperFrames), and assembled in Resolve through the davinci-resolve MCP on a new timeline, one named track per kind of addition, so the user can adjust or remove anything.

The quality contract is `references/editing-spec.md`. Read all of it before planning. It carries the shorts spec over to long form: the same graphics style, camera language, fact checking and sound design, with the hook / body split. The rules the user cares most about:

• Music plays under the hook only and fades out over 2-3 s right after it. Never under the body.
• The body keeps showing: a zoom with highlights, the real article or page, an explainer graphic, a logo or the speaker's own video about every 10-20 s (~80% of the runtime covered on theory), CTA cards and SFX on every visual event - energy from showing, not decoration (no music or keyword pops after the hook).
• Nothing on the clean cut changes. The pro edit is a duplicate of it with new tracks on top.

Where the user's request differs from the spec, the user wins.

First real project (Sonnet 5.5 vs Opus 5.5 vs Fable 5.1, 2026-09-30): an 11-minute clean cut, 4K60, OBS recordings that switch between a full-frame camera and a screen with a webcam PiP. The test build in examples/ is what the scripts were proven on - including every fix in references/lessons.md.

Requirements

Missing pieces: references/setup-and-troubleshooting.md (ask before the ~7 GB CrisperWhisper install).

Conventions

Shell variables don't persist between Bash calls, so start each command with:

SKILL="<this skill's folder>"
VENV="${VEDIT_VENV:-$HOME/.venvs/crisperwhisper}"; CW="$VENV/Scripts/python.exe"; [ -e "$CW" ] || CW="$VENV/bin/python"
RV="${PRO_EDIT_VENV:-$HOME/.venvs/pro-edit}"; PY="$RV/Scripts/python.exe"; [ -e "$PY" ] || PY="$RV/bin/python"
W="${PRO_EDIT_WORK_ROOT:-${LOCALAPPDATA:-$HOME/.cache}/video-pro-edit}/<project>__<timeline>"   # short, no spaces
M="<folder of the source media>/pro-edit-media"     # renders Resolve links to: next to the sources, never under AppData

Every script runs with W as the working directory (cd "$W"). W holds caches and intermediates; M holds the finished media, captions.srt, PUBLISH.md and report.md.

Workflow

Commands for every step are in references/pipeline.md.

1. Connect and choose the timeline (read-only). project_manager get_current, timeline get_current,

timeline list. Default target = the current timeline. If a "<name> - Clean Cut vN" exists for it, that is the base; if the current timeline is raw, make the foundation cut first (references/foundation-cut.md). If resolve_control get_version reports an MCP update, mention it once.

1. Set up and map the programme (~5-10 min, mostly background). setup.sh "$W" "$M", then on the clean cut:

probe_timeline_structure -> vedit.py prepare + transcribe (CrisperWhisper, hotwords as in the foundation cut) -> program.py (every V1 item and word on programme time, the voice as it plays) -> scenes.py (camera vs screen, the PiP window per file) -> pip_items.py (the PiP corner per V1 item: OBS scenes can move the webcam inside one file). LOOK at scenes.png. Read transcript.txt like a paper edit. patch_flash.py scan lists items that end or start on a flash of another window - cover each with a fix beat (patch_flash.py <id> ...).

1. Research, in parallel (one long-lived subagent): fact-check every figure against 2+ sources; capture the pages the speaker

cites but the recording doesn't show, official logos, pricing and docs as 2x PNGs into W/captures/.

1. Plan once into W/edit_plan.json (examples/edit_plan_example.json): hook_end, music style and mood,

the beats (zoom, punch, gfx, words, cta) with word-cued times, chapters, caption fixes, the publishing copy. Anything private on screen (a message with fees or contact details, an account number) gets a censor beat. Use look.py to see the programme at any time with a source-pixel grid, and --zoom k,fx,fy to frame a zoom clear of the webcam. Check the plan against the spec's density rules before rendering anything.

1. Render, fanning out:

• censor beats first: censor.py track (zooms inside the beat bake the blur in from it), scan the whole

programme for the same words, check preview frames, then render;

• zooms, keyword pops, CTA cards and the audio: preview a few zoom frames first (zoom.py --preview, seconds),

then bash scripts/render_beats.sh in the background renders every zoom / words / cta beat of the plan in parallel (one process per beat) and runs audio.py after them - then listen to the hook in mix_preview.wav;

• graphics: one or two LONG-LIVED subagents (the user's preference - many small agents burn tokens), each owning

half of the gfx beats with a written brief (beats, cue words with times, assets, PiP rules), following references/graphics.md, examples/gfx_example.py and the reference edit in examples/harness-engineering/ (its README indexes the explainers to copy: the software-factory swarm, concept diagrams built word by word, real sources with the cited line highlighted): assets -> build_gfx.py -> render_gfx.sh draft -> draftsheet.py (LOOK, fix) -> render_gfx.sh full (lossless PNG capture, one Chrome per worker, throttled machine-wide so any number of subagents can call it) -> compose.py (split beats: --matte first - Robust Video Matting on the GPU, u2net as the fallback; several beats with --jobs). Check every render: previews and sheets before full renders, one full-resolution frame of every split (compose.py <id> --preview t seeks straight to it).

1. Assemble in Resolve (references/resolve-assembly.md): duplicate the clean cut as

"<base> - Pro Edit vN", count its tracks, place.py plan, add and name the PE tracks, import M into a bin, place.py ids, one append_to_timeline, punch-ins with bulk_set_item_properties, markers, save. Then place.py verify against a fresh structure probe, and check frames from a 1080p review render (pipeline.md section 7; timeline_frame capture once hung for 30 minutes).

1. Publish and report: publish.py (captions.srt, PUBLISH.md with chapters and the community links),

then report.md (spec section 9). Tell the user: the timeline name, what was added and where, the archived duplicates the MCP made (safe to delete - never delete them yourself), and to normalise to -14 LUFS on delivery.

1. Edits are incremental: change the plan, re-render only the touched beats, re-import those files and replace

their clips (references/pipeline.md section 8); many swaps at once go through one script_plugin run_inline. A rebuilt audio layer goes on new tracks with place_audio_swap.py. Fold the user's taste into references/lessons.md.

Things that are easy to get wrong

Read references/lessons.md before improvising. The biggest ones:

• Colour at the cut: zoom renders work on the source's own YUV planes, so a frame at rest is bit-identical to

V1. Never route footage through ffmpeg's default RGB conversion (bt601) - the cut into V2 would shift colour.

• Windows pipes: raw 4K video through a Python-buffered pipe crawls; media.py's unbuffered 64 MB pipes move

it at GB/s. Never add bufsize= to a frame pipe (the shorts skill lost 48 ms a frame to a 100 MB buffer).

• The user's timeline is not pristine: duplicate it, never rebuild it; skip titles/transitions in the

programme map; never plan a beat across a transition.

• Frame the zoom around the webcam: the PiP is held still; keep targets out of look.py's red box.
• Private details on screen: blur them with a censor beat on the topmost track, scan the whole programme for the

same words, and keep the words themselves out of the report and the publishing copy.

• Sound effects that wear thin: level by loudness, not peak (at the same peak bells and scribbles sound 6-10 dB

louder than a click); only a zoom's first ding / scribble, accents 15 s apart, but every animation keeps its pops (variant C, editing-spec section 6). Resolve's bus compressor lifts the effects ~4.5 dB (sfx_bus_lift).

• Resolve's API can't set clip volume or keyframes reliably: levels are baked into the audio files, motion is

rendered, punch-ins are static transforms.

Files

• scripts/: the pipeline (copied into W/scripts by setup.sh; per-project values live in W/project.json).

vedit.py (vendored from davinci-resolve-video-edit), program.py, scenes.py, look.py, zoom.py, overlay.py, assets.py, build_gfx*.py, render_gfx.sh, draftsheet.py, compose.py, matte_rvm.py (split mattes, RVM), matte_gpu.py (u2net fallback), audio.py + sfxlib.py (the royalty-free SFX library), music.py (synthesized beds, from create-video-shorts), music_gen.py (generated hook music), sfx_library.py (builds the SFX library), render_beats.sh, censor.py, pip_items.py, patch_flash.py, words.py (word times in a window), place.py, place_audio_swap.py (a rebuilt audio layer onto new tracks), publish.py, media.py, config.py, faces.py.

• Shared, per machine (setup.sh): ~/.cache/pro-edit-models/rvm/ (matting), the music-generation env and weights

(references/setup-and-troubleshooting.md).

• assets/: the 16:9 graphics engine + GSAP, Poppins, Instrument Serif, Figtree and Geist Mono, the face models, and

sfx/ - the royalty-free SFX library (54 sounds + manifest.json with sources and licences). Git holds the 27 CC0 sounds; the 27 Mixkit ones may not be redistributed, so on a machine without them run scripts/sfx_library.py build (setup.sh does it; references/setup-and-troubleshooting.md, "Sound-effects library").

• examples/: the real test plan, its graphics config and its report, and harness-engineering/ - the reference

edit (plan, zoom specs, both graphics modules, the briefs) that set the quality bar.

• references/: editing-spec.md (the contract), pipeline.md (commands), resolve-assembly.md (MCP calls and

gotchas), graphics.md (engine API), foundation-cut.md + editorial-rules.md (the clean cut), setup-and-troubleshooting.md, lessons.md, and design-system/ (the channel's "Leon YouTube" design system: readme, tokens, components, guidelines; bundled so the skill is self-contained, and implemented by the stage theme).