client_video_deliverables v1.0.0

name: "client_video_deliverables" description: "Deliver finished video work to clients without the usual pain: set up revision rounds in the contract, turn vague client feedback into actionable notes, hand over files in the right specs, and archive the project properly. Triggers when a client video project is wrapping up or when setting up the delivery side of a video contract."

Purpose

Getting the edit right is only half the job. This skill covers the other half: the contract terms that keep revisions bounded, the feedback process that turns client reactions into notes you can actually act on, the file specs that mean the handoff just works, and the archive practice that protects you when the client comes back in two years.

Workflow

1. Lock the revision terms before editing starts

Put revision terms in the contract, not in a handshake. The defaults that work in practice:

• Cap included rounds at 2-3. Split them by phase if you want tighter control, e.g. 2 rounds on the script/storyboard, 2 rounds on the cut, 1 on the final grade. More phases with more rounds means more surface for scope creep.
• Price the extra rounds in writing. Either hourly (a common figure is around $200/hour for editing work) or a flat fee per round (20% of the project rate is a common benchmark). The number matters less than it being agreed up front.
• Put a deadline on feedback. A 24-48 hour review window per round is standard; add a "deemed approved" clause so silence after the window counts as approval. Without this, projects stall.
• Define what counts as a revision. Tweaking timing, swapping a shot, adjusting a grade: revision. New script, new shoot day, changed story: out of scope, needs a change order. Write the distinction down.
• Route extra work through a change order. Any scope change gets a written change request (use assets/change-order-form.md) with the cost attached before you start it. No verbal "quick changes."

Use assets/revision-clause.md as the clause starting point. These are benchmarks from industry practice, not legal advice; for high-value projects get a media attorney to review the actual contract.

2. Make client feedback actionable

Client feedback fails when it arrives as "make it pop" in a phone call. Run it like this:

1. Send a review link, not a file. Use frame-accurate commenting (Frame.io, Vimeo Review, or the free equivalent) so every note lands on a timecode.
2. Batch into rounds. Feedback arrives in one consolidated batch per round, from one contact person on the client side, by the contract deadline. Drip-feed notes from five people is how revisions multiply.
3. Translate before you act. For each note, write down what you will actually change: "Client says the intro is slow" becomes "Trim cold open from 12s to 7s, cut the second drone shot." If you cannot translate a note into an edit, ask the client to clarify before spending the round.
4. Confirm the batch. Reply with your translation list and the round number ("Round 2 of 2, three edits"). This locks what the round covers and leaves a paper trail if more rounds get requested.

3. Hand over files to spec

Build the delivery package as: master, deliverables, and a spec sheet.

• Master. ProRes 422 HQ (or DNxHR HQX) at the native frame rate, progressive, square pixels, with 24-bit 48kHz PCM audio. Broadcast-style spots: -24 LKFS full mix, true peak under -2 dB. Deliver a dirty (full graphics/text), a dirty-without-subtitles, and a clean (no overlays, identical duration and timecode) version where the client needs them.
• Deliverables. H.264 (High profile) MP4 for web/social, H.265 or AV1 where the platform supports it. Keep the mezzanine at 10-bit 4:2:2 and let the delivery leg be the only place 8-bit 4:2:0 appears.
• Names. No "final", "newest", "v2_REAL" in filenames. Use <project>_<title>_<raster>p<fps>_<codec>_<cut>_<v01>, e.g. acme_brand_1080p24_prores_dirty_v02.mov. Version numbers go up; nothing else changes in the name.
• Spec sheet. Fill in assets/delivery-spec-sheet.md for every handoff: what each file is, codec, raster, frame rate, audio, loudness, who approved which round, and where the archive lives. Platform-specific notes go in references/platform-delivery-notes.md.

4. Archive the project

Do this within a week of delivery, while you still remember what everything is. The 3-2-1 rule is the floor: three copies, two different media types, one offsite.

• Always keep: camera originals (the source of truth), LUTs and transforms, project/timeline files, fonts and graphics, final exports, the signed spec sheet.
• Rebuildable, keep only if cheap: proxies and render caches. Keep the path and naming logic that reconnects them instead of the files.
• Structure it: 01_camera-originals/, 02_project-files/, 03_graphics-audio/, 04_luts/, 05_exports/, 06_delivery-spec/. Same folders on every project.
• Log it: one line per project in your archive ledger: project name, client, delivery date, where the three copies live. If you cannot say where a copy is, it does not exist.
• Test it. Open an old project from archive once in a while and confirm the media, LUTs, fonts, and exports still relink. A backup you have never restored is a hope, not a backup.

Output Contract

When this skill runs a delivery, it produces:

1. A contract-ready revision clause (filled from assets/revision-clause.md) or a marked-up draft of the client's contract.
2. A feedback translation: the client's notes rewritten as concrete edit instructions, numbered by revision round.
3. A delivery package: master + deliverable files named to convention, plus a filled assets/delivery-spec-sheet.md.
4. An archive log entry and confirmation the 3-2-1 copies exist.

Operating Rules

1. No confident unverified claims: every factual statement about platform specs, broadcast standards, or legal norms must come from a checked source. Unverifiable becomes a recommendation, not a fact.
2. This skill is not a lawyer. Contract language is a starting point; say so explicitly before handing it over.
3. Never ship a deliverable you have not watched through at full length at the delivery raster. Spot-checking is how bad frames reach clients.
4. File naming is law. One bad "final_FINAL" breaks the whole archive's trust.
5. If the client's delivery specs exist, theirs win over the defaults in this skill. Ask for them before building the package.
6. Revision rounds are a finite resource. When the client is on their last included round, say so in writing before the work starts, not after.