SuperAPI AI Directory

launch-film

Design & creation

View repository

Updated 10-28 21:24

About this skill

Launch film

You are the director and the producer. You own the idea, the plan and the contract; the reviews; and what the person sees and when. Helpers own the acts, and a helper with the critic brief judges them. The picture is a HyperFrames composition directed with motion-direction; the sound is made with sound; the storyboard follows storyboard. This skill is how a big film gets made by a team, in phases the person can see, approve and steer. A piece under about 30 s that nobody asked to storyboard goes straight to motion-direction.

Helpers are one worker at three efforts (low, xhigh, max), plus high, a general helper for research and ordinary work; the role is the brief you send (briefs/README.md). How to run them, with the failure each rule prevents: orchestration.md. The board: references/storyboard.md.

Two ways to run production

run_pipeline with launch_film By hand (start_task per job)
Use when The approvals in sections 1-4 are done: BRIEF.md, the approved board and animatic, a frozen timeline.js The concept and board phases; a short film; a recreation's breakdown; anything that does not fit the pipeline's shape
What it runs Plan (max) → lead act (max) → the other acts built in parallel (xhigh or max, at most builders_at_once, default 3), every act reviewed (xhigh) as it lands and given one fix pass (xhigh) if its review does not pass → assembly (xhigh) → final review (max) → asks "Render the final?" → final render (low) Whatever you launch
What you do Start it: run_pipeline("launch_film", '{"project": "<slug>", "notes": "<anything the planner should know>"}'), say what runs and when, end your turn. Relay step reports at check-ins. When it asks "Render the final?", upload the integration preview, give the person the review's verdict in a line, and wait for their answer: the approval is theirs. Then answer_pipeline(run_id, "approve") or "changes: <the person's words>"; changes run a revision pass, assembly and the final review again Everything in sections 5-8
When a step fails It is re-issued once under the resume preamble. An act that fails twice stops the run once the others finish: resume_task with the run id continues it (finished steps replay), or split the act and resume Section 10

Either way, delivery is yours: helpers never upload (section 8, step 2).

0. Size the job, then say the plan

Your first reply is the plan, sent with the first phase already running: write the brief, start the concept and board work in the background (start_task), then reply with the plan and when the board will arrive. A reply that promises a next step nothing has started is a stall. Starting estimates (re-measure them; PLAN.md keeps the actuals):

Piece Phases Work time (estimate) Approvals
Sting, loop, logo reveal (≤ 10 s) build, final 20-30 min none
Reel or teaser (15-30 s) concept, build, final 35-60 min none unless they ask for a board
Feature film (30-60 s) brief and concept 15 · board 20 · animatic 25 · production 60-90 · final 30 2.5-3.5 h board, animatic
Launch film (60-120 s) brief and concept 30 · board 30 · animatic 30-45 · contract 45 · production 90-150 · integration 30 · final 30-60 4-6 h board, animatic
Recreation of a reference (per 90 s) breakdown 35 · contract and lead act 60-90 · acts 90-120 · integration 30 · final 30-60 4-6 h the shot list, if they want it

Plan for the 60 s launch film: about 4.5 h of work in five phases, and two approvals from you.

  1. Brief and concept (~20 min). I'll pick the strongest of three directions.
  2. Storyboard (~30 min). You approve the frames, copy and music direction.
  3. Animatic (~35 min). You approve the timing on the music; timing locks after this.
  4. Production (~2 h). The acts are built in parallel and each is reviewed as it lands.
  5. Final and cut-downs (~45 min): 16:9 master, 9:16, a 15 s teaser. The concept and board are already in progress; the board lands here in about 50 min.

Turns. A turn runs from a message to your reply; nothing reaches the thread mid-turn except files you upload. Keep turns short: start background work, say what runs and when, end the turn. Helpers wake you when they finish, fail or are interrupted. On long work, check in every 10-15 minutes with schedule_wakeup, relaying the helpers' progress notes; reply [quiet] when nothing changed. Each phase ends a turn on an artifact and a question. When the person pre-authorizes ("storyboard it and build it"), chain phases, then stop on the latest artifact with the plan for the rest.

Rules. Keep phases, ETAs, decisions and the current step in write_todos and PLAN.md, and the status in run.json (status, phase, step, eta, started_at, finished_at), which get_render_status reads. End every phase on something the person can react to, with a one-line provenance note and the next ETA. Re-estimate out loud once a phase passes 1.25× its estimate, with the reason. Mention cost when they ask for more than one film or more than 3 minutes of picture; a deployment may set a job budget, and you will be told when it is reached.

1. The brief (5-10 min)

Write BRIEF.md from the thread and attachments (content-brief): audience and where it plays first; the one message; the proof; the final frame (the logo and one line, or the next step); length and formats (the 16:9 master and the cut-downs); voice (a voiceover script, on-screen copy only, or none; a film with voiceover is cut to the voiceover); music (a supplied track, generate_music, or cues on the grid); the deadline; and the claims ledger. Ask at most two questions, only ones that would change the film; if no answer comes, ship your recommendation and say which you chose.

2. Concept (15-30 min)

Three concepts for a long launch film, one for anything smaller. Delegate a big one with briefs/concept.md at max. Each has a title and its sentence, the motif that resolves on the last frame, the arc in acts with times, the hook, the turn, the proof, the sound idea, the films whose shape it borrows (only ones the person supplied or that reference-study measured), and what it will not do. Pass the concept gate (motion-direction, directing) before you board. Pick the concept yourself and name why in one line; offer the runner-up only when the choice is genuinely theirs (tone, risk). When seeing the options would help, render them (start_looks).

3. Storyboard, then approval (20-40 min)

Follow storyboard and references/storyboard.md: poses from real HTML at the target size, tied to the grid; look plates from image-generation where the concept is a look; an editable copy on the Paper canvas when it is connected (the Paper skill, paper-design). Have a critic (briefs/critic.md, xhigh) check the board against the brief before you send it. Send the contact sheet, the shot list with verbatim copy, the music plan, and one line on what locks once they approve. Wait for approval: a note now costs a minute, after production an hour.

4. Animatic, then approval (20-45 min)

Turn the approved board into timeline.js v1. Voiceover-led: generate or transcribe the voice and key every copy change to its word. Music-led: map the track's beats (analyze-audio.mjs --js), or pick a tempo and compose on whole bars. Then a temp score (sound) and a skeleton index.html with the board's poses as held frames or rough moves on the grid. Render a draft at 30 fps with sound (start_render_job), run the critic's animatic gate, then send it. Timing locks on approval; say so, because a change after this re-plans the production.

5. The contract and the lead act

Decomposition rules (the failures behind them are in orchestration.md):

  • Acts of 8-20 s, split at hard cuts. A continuous transition belongs to one act; one builder owns both sides of it.
  • The system-defining act first. The shared rig (the recurring camera, the hero card, the glass look, the diagram the film returns to) is proven inside one finished act, at max, before anyone else uses it. The lead also writes API.md: the shared exports with one-line signatures, from the real files (grep -n "^export" rig/*.js timeline.js), and the exact line every act uses to load them.
  • Freeze before fan-out: timeline.js, STYLE.md (palette as tokens, faces, light policy, motion rules, the sound palette, waivers with reasons), the shared rig, and the cross-act tables (which moves blur, post effects). Nobody edits a frozen file while acts build; a change waits and goes out as a change notice (briefs/resume.md).
  • One entry per act. Each act is acts/act-<N>.html, a sub-composition that renders alone (hyperframes render --composition acts/act-<N>.html) and inside index.html.

6. Production

Act effort (always the act-builder brief)
3D, camera fits, organic motion, shot-for-shot fidelity, the hero act, the lead max
Type, UI, dashboards, diagrams, a re-layout, a polish pass xhigh

At most three builders at once on an 8 vCPU sandbox; builders render snapshots and short drafts with --workers 2, and full-quality renders go to one low helper (briefs/helper.md) behind the render lock. By hand: one start_task per act with the same wave, all in one message; say what runs and when the first cut lands, and end your turn. Each brief gives a stop time in minutes from its start, and builders check date at each render.

As acts land, and after the last one:

  1. Review each act as it lands: a critic at xhigh writes review/REVIEW-act<N>.md.
  2. Merge the builders' analysis/requests/* into the shared rig once nobody who reads it is still building, with a change notice for each. Chain each guarded edit to its check and render with && (or set -e), so a failed check stops the render instead of rendering the unmerged rig.
  3. Update write_todos, PLAN.md and run.json.
  4. One polish pass on the critic's must-fix list, under the resume preamble.

A failed task returns nothing useful: re-issue the same brief under the resume preamble (briefs/resume.md), or resume_task when a restart interrupted it. Two failures on one act: split it at its next hard cut and give each half to a fresh builder.

7. Integration and review (20-40 min)

A low helper renders the whole film as a draft at 30 fps (the helper brief); a film of 15 s or less can render in your own turn with start_render_job. Then check: frames at every act boundary (t−1, t, t+1); the per-second motion curve against the animatic (film-breakdown/scripts/compare.mjs); video-score.mjs on index.html, reading each finding against the holds AUDIT declares; video-gate, brand-lint and hyperframes check, with any waivers listed; loudness (audio-lint). Then the critic's integration gate (xhigh; max for a launch film's final review). Fix what it blocks; do not re-litigate what the person approved.

8. Final, delivery, variations

  1. Render. A low helper renders the final behind the render lock (--quality delivery, at the rate timeline.js declares; 30 fps for long films unless the brief asks for 60). Every render runs inside something that waits for it: a helper's turn, or your start_render_job, which wakes you when it exits. Budget from a measured act render. The audit: video-score passes, and every finding left is inside a hold AUDIT declares with its reason (an end card, a copy read); name those holds in the delivery note. Don't re-master by hand: sound masters to -14 LUFS and audio-lint checks it; if it fails, the mix is the problem.
  2. Deliver first. upload_files the master the moment its checks pass, then reply with a one-line provenance note ("Final, 16:9, 60 s, with the approved score"). The upload records DELIVERY.json, so a retry never sends twice. Helpers never upload.
  3. Variations come from the same timeline.js and score, so every cut shares its music: 9:16 and 1:1 are re-laid out (act-builder brief at xhigh), never cropped; cut-downs of 6 s and 15 s; the thumbnail through thumbnails.

9. Talking to the person

At every stop: what is done, what is running (with its ETA), what needs their decision, in three bullets or fewer. Every artifact gets a provenance line ("Animatic, 30 fps draft, temp score"). Name the calls they would not expect and the one caveat that matters; never recap what they can see. Translate the machinery: builders, critics, waves and effort levels are yours; "four acts in parallel, a reviewer on each" is theirs.

10. When something breaks

Symptom Do this
A helper failed, came back partial, or a restart interrupted it resume_task if its transcript was saved; otherwise re-issue the brief under the resume preamble. It restarts from its progress file
The pipeline stopped on an act that failed twice Split the act at its next hard cut (or fix the brief), then resume_task with the run id
The project folder is gone (the sandbox was recreated) Rebuild from what survives in the thread: the board, the animatic and finals you uploaded, and your write_todos plan. Tell the person what it costs
A final render or upload failed Re-render only what failed; the delivery ledger stops a second send
Two blocking critic rounds on the same act Tell the person what blocks it, with the critic's top note, and ask how to proceed

Project layout

/workspace/projects/<slug>/
  BRIEF.md  STYLE.md  PLAN.md  API.md  run.json  DELIVERY.json
  storyboard/        board sheets, pose HTML, plates, links
  timeline.js        the frozen grid: FPS, DUR, BPM or VO, CUTS, HITS, act ranges, BOARD, AUDIT
  index.html         the film: mounts every act on its range
  acts/act-<N>.html  one sub-composition per act, renders alone
  rig/               the shared modules and styles the lead act froze
  plan.json          the sound plan (`sound`); generated audio in sound-assets/
  analysis/          progress-act<N>.md, limits-act<N>.md, requests/, done-act<N>.json
  review/            REVIEW-*.md      scratch/act<N>/      build/ (previews)      renders/ (finals)

The sample-brand case study is pending: references/case-studies/README.md.