beachyphotoandfilm-arch/video-skills

YouTube conductor

One command instead of several skills to remember. You shot footage; this walks it all the way to published assets, stopping for a yes at each gate.

Setup: fill these in

placeholder	what it is
<YOUR_FOOTAGE_DRIVE>	Where raw footage lives, e.g. /Volumes/<drive name>
<YOUR_VIDEO_LIBRARY>	Where finished files are kept, e.g. ~/Videos/Finished
<YOUR_LUT>	The LUT applied to every clip, e.g. MyCamera_Log_to_Rec709.cube (or none if you shoot a standard profile)
<YOUR_TIMEZONE>, <YOUR_POST_TIME>	Default scheduling slot (see schedule-social)

Never run two stages without approval in between. Every stage needs the creator's taste, and a wrong stage 1 poisons everything after it.

State

One file per video: drafts/videos/<slug>.json.

{"slug":"my-video","title":"my video title",
 "footage":"<YOUR_FOOTAGE_DRIVE>/my video footage",
 "work":"/tmp/.../paperedit",
 "project":"My Video - Paper Edit",
 "stages":{"paper-edit":{"status":"approved","at":"YYYY-MM-DD","note":"v2, 10:16"},
           "punch-ins":{"status":"approved","at":"YYYY-MM-DD"},
           "reels":{"status":"approved","at":"YYYY-MM-DD"},
           "covers":{"status":"todo"},
           "schedule-reels":{"status":"todo"},
           "overlays":{"status":"pending"},
           "thumbnail":{"status":"todo"},
           "schedule-youtube":{"status":"todo"}}}

Statuses: todo → running → review (waiting on the creator) → approved | skipped.

On "continue the video": read the state file, report where it stands in one line, and resume at the first stage that is not approved or skipped. On a new video: create the state file first, then start at stage 1.

Keep the work dir stable across stages. Transcripts, segments-v2.json and cuts.json are reused by every later stage, so don't scatter them.

The stages

#	stage	skill	creator approves	output
1	Paper edit	paper-edit	the cut list, then the timeline	Paper Edit v1 + v2 (tight) in a new Resolve project
2	Punch-ins	paper-edit step 9	the framing plan	Paper Edit v3 (punch-ins)
3	Reels	video-reels	the hook for each reel	vertical timelines, finished: footage V1, hook card V2, captions V3
3b	Reel covers	reel-covers	the grid proof, every headline	one unique 1080x1920 cover per reel in your cover style, proofed in grid view with the reel icon
4	Schedule reels	schedule-social	every caption and time	IG + TikTok + Shorts on the Metricool calendar, daily from tomorrow, each post carrying its cover
5	Overlays	video-overlays	the clip list before rendering	transparent .mov clips + FCPXML
6	Thumbnail + title	video-thumbnails	which variant	1920x1080 PNGs + a phone-size proof + titles
7	Schedule YouTube	schedule-social	the title, thumbnail and description	the long-form video on the Metricool calendar

Reels come before overlays on purpose. They don't need the animations, and they need the creator's hands (trim, render) before they can post. Getting them out early means they're going out while the overlays are still rendering. Overlays are the slowest stage and the one least waited on.

Live-event or separate-audio shoots (a lapel or recorder in an audio/ folder next to the clips): run lapel-sync before paper-edit or reels. It makes the lapel the clip audio every later stage reads.

Load the stage's skill before running it. This file is the running order and the gates; each skill holds the actual how.

Gates: what to show, and what to ask

1. Paper edit. Show raw length, v1, v2, cut count, and the notable cuts with reasons. Ask: "Anything here you want to keep?" After the creator scrubs: "Is the cut locked?" Nothing downstream can start until it is, because overlays and reels are anchored to word timings.
2. Punch-ins. Build v3 from the creator's trimmed v2 (segments-locked.json), then copy the v2 grade onto v3 without being asked (paper-edit step 9). If the video talks about a real project, ask if there are photos, and put them on V2 as white-backdrop cards (paper-edit step 11). Show the change count, roughly one every 20-40s, and the list of lines that get a close punch. Ask: "Do these land on the right moments?"
3. Reels. If the video has a comment-keyword CTA, film a separate reel CTA clip ("Comment KEYWORD below and I'll send you..."). If the state file has reel_cta, end every reel from that video with that clip (in/out points in the linked cta.json, taken from silencedetect because whisper can drift up to 2s on short clips). The comment keyword goes in the caption too. Show each reel as hook line + what follows, plus the text-hook card wording. Ask: "Do these hooks stop the scroll?" Fewer and better beats more. Then hand off: the creator trims and renders. Captions and hook cards are already on the timeline. Start the overlays while that happens. Nobody needs to be idle. 3b. Reel covers. Don't skip this stage by default. As soon as the reel hooks are approved, say "Next up: covers for these reels" and start reel-covers. It doesn't need the renders, only the hooks and transcript, so do it during the trim. Show _grid-phone.png (with the reel icon drawn in) plus each headline. Ask: "Do these covers stop the scroll?" Iterate until approved, then log them. If the creator says skip, mark it skipped and say that reels will go out on an auto frame.
4. Schedule reels. Triggered by "schedule the reels" once renders are done. Show every caption and every slot, each next to its approved cover. Ask: "Good to schedule these?" If covers isn't approved or skipped, stop and run stage 3b first.
5. Overlays. Default house style is in-scene type beside or behind the speaker's head, never over the face (see video-overlays). Show the proposed clip list with timecodes and cues before rendering (rendering is ~10s of wall clock per second of overlay). Ask: "Any of these you'd cut, and any moment I missed?"
6. Thumbnail + title. Show the phone-size proof sheet, not the full-size renders, plus 4-6 titles with character counts. Ask: "Which one, and do you want different words?"
7. Schedule YouTube. After the overlays are on the timeline and the final video is exported. Show the title, the chosen thumbnail and the full description. Ask: "Good to schedule this?"

Scheduling rules, both stages 4 and 7:

Default slotting rule: start the day after today, one post per day at <YOUR_POST_TIME> <YOUR_TIMEZONE>, and skip any day that already has content (drafts count). Pull getScheduledPosts before choosing slots; never double-book a day.

Captions ship clean. Finished copy every time, no "TEST DRAFT" text. Mark tests with draft: true + autoPublish: false and hand over the planner link instead.

Running order rules

• Cut before graphics, always. Overlay timings are anchored to the spoken words; any re-trim shifts all of them. If the cut changes after stage 5, regenerate the FCPXML (seconds) but don't re-render the clips.
• Reels come from the raw footage, never from the overlaid cut. The animations are made for YouTube, and that is why reels can run before overlays.
• Two handoffs, and they overlap. After stage 3 the creator is trimming reels; after stage 6 they are laying overlays on the timeline and exporting. Both are slow for them and free for you, so queue the next stage's work rather than waiting.
• The LUT goes on everything (<YOUR_LUT>). If the camera shoots a log profile, ungraded frames look grey, including thumbnail stills.
• Anything that touches Resolve: run bash .claude/skills/paper-edit/scripts/ensure_resolve.sh first. It opens Resolve if it's closed and waits for the API, so don't ask the user to open it. It still needs External scripting: Local, and a new project so existing work is never at risk. Name it <Video> - YYYY-MM-DD so the newest is obvious; two same-named projects cause confusion about which is current.
• Finished files go to <YOUR_VIDEO_LIBRARY>/<Video> YYYY-MM-DD/, working files stay in ~/Movies/<video>-*. Two renders of each video: a delivery pass and a 60 Mbps archive master, plus the .drt/.drp timelines. See schedule-social for the layout. The creator should never have to go digging in ~/Movies for something postable, and nothing is ever written loose on the Desktop.
• The 4K long-form export (optional): duplicate YouTube Final as YouTube Final 4K, set that copy's timeline to 3840x2160 (useCustomSettings 1 + timelineResolutionWidth/Height), and render H.264 at VideoQuality 40000 into <Video>/YouTube/. Zoom and punch-ins survive the resolution change, and the 1080 overlay clips scale up cleanly. Start the render and return; never wait inside execute_resolve_code. A 6:30 video can take about an hour at 4K with in-scene overlays, and the MCP call dies after 30 minutes, which also blocks every later call until the render ends. Watch for the file from bash instead: the MP4 only becomes readable (ffprobe succeeds) once Resolve finishes. One project renders at a time, so start the next video's render after the previous file lands. About 1.9GB per 6.5 minutes.
• Publishing is the one irreversible stage. Everything before it can be rebuilt in minutes; a post that goes out cannot be unpublished from here. Treat the gates on stages 4 and 7 as the strict ones.

Time and cost

stage	wall clock	notes
Paper edit	~2 min transcribe + reading time	the only stage with real thinking cost, ~5k tokens
Punch-ins	seconds
Reels	~1 min	captions included
Overlays	~10 min clean-cut render, then ~15-20s per 1s of overlay	in-scene style mattes every frame: ~48 clips can take ~1 hr; needs the footage drive mounted; run it during the reel trim
Thumbnail	~1 min	4-6 variants
Schedule	~2 min	upload hop + Metricool writes

Related

• paper-edit, lapel-sync, video-overlays, video-reels, reel-covers, video-thumbnails, schedule-social
• Optional: a titles reference (length and CTR rules) and a video topic plan, if you keep them