/cinematic-shot

name: cinematic-shot
description: Shoot software UI like a film. A sequence of hero shots, each a steep, oblique, extreme close-up of the interface floating in black, with a razor-thin focal plane, a slow motivated camera drift, and UI that acts on its own, hard-cut on the action, ending on one line of copy and a still logo. Use when asked for a launch video, product film, feature trailer, teaser, promo clip, hero shot, or any "cinematic" footage of an app or UI. This skill covers camera, framing, light, and edit. It is stack-agnostic.

Cinematic shot

You are the director and the DP, not the motion designer. The film is a sequence of **hero shots**. Each one looks at a real piece of the product's UI from a steep, low angle, so close that the focal plane covers only a line or two of text and everything else melts into black. The camera drifts slowly toward where the next thing will happen. The UI does the work by itself: things get typed, streamed, selected, and written while we watch. Nothing explains itself with captions.

This skill is about camera, framing, light, and the edit. Build the film with any rendering stack. Whatever you choose, make every frame a pure function of time, so the film renders deterministically and can take motion blur.

Read [references/look.md](references/look.md) for exact camera, depth-of-field, light, reveal, and type recipes. Read [references/shot-list-example.md](references/shot-list-example.md) for a full example of the shot grammar.

For a ~15 second promo video made in code from a landing page (a continuous 3D fly-over of the page ending on a title card with the brand, logo mark, a two-part closing line, and an optional track), follow [references/landing-page-promo.md](references/landing-page-promo.md).

The taste

A black void. The product floats in it like a dark slab, tilted away from the camera, lit by a soft pool that follows whatever matters and lets everything else fall into black. The camera is low and close, looking *along* the UI rather than at it, so lines of text run diagonally across the frame and shrink into the distance. The focal plane is a thin band: one control, one line of typing, one row of a list is sharp, and the rest is soft bokeh. The camera never stops drifting and never moves fast. Shots are long enough to watch something happen. The only colour is the product's own. Restraint everywhere else.

1. Find the story before the shots

Before planning a single camera, write down:

• **The flow**: the 4–7 things that happen on screen, in order. Examples: open a view, select a tab, type a prompt, watch the answer stream in, watch a document write itself, approve.
• **The payoff**: the one moment where the product visibly does something remarkable. The film exists to reach this frame.
• **The demo content**: concrete, believable data inside the UI, such as names, IDs, statuses, code, and short human-sounding text. Real-looking density is what makes a close-up beautiful. A list of twelve plausible issues reads as a product; three grey placeholders read as a mockup.
• **One line of copy**: the product or feature name, then a tagline of five words or fewer.

2. Write the shot list

Post the shot list before building, then keep going:

| # | Cut at | Len | Subject (what is in focus) | Scale | Angle | Move | Action | |---|---|---|---|---|---|---|---|

Rules:

• **Length**: 45–55 s in all, with 8–10 UI shots, then the copy and the logo.
• **Shot length follows the action.** Process shots (typing, streaming, a document writing itself, a long diff) run **5–9 s**. Punctuation shots (a tab, a button, a nav item) run **2–3.5 s**. Alternate the two, so a long watch is followed by a short accent. Median about 5 s.
• **Cut on the action, not on a metronome.** There is no beat grid. Cut in when the subject is already in frame or about to arrive; the action starts within 0.3–0.8 s; hold the result for 0.5–1 s; cut while the camera is still moving.
• **One idea per shot.** A shot can contain a short chain (type → send → the reply starts) only if the camera follows one continuous thread.
• **Vary scale like an editor.** Extreme macros and macros dominate. Medium shots carry the longer process. Hold back the **wide shot** (the whole window, near-frontal) for the payoff, where it lands like a release. Return to a close-up after it.
• **Alternate the diagonal.** If the text in one shot rises to the right, the next shot's text falls to the right, or the plane tilts the other way. Every cut should read as a new camera position.
• **No continuity cursor.** The UI acts on its own (see section 4). The viewer never needs to follow a pointer between shots.
• **Separate surfaces get separate setups.** When the story moves to another surface (a terminal, a phone, another app), give it its own slab in the same black void and hard-cut to it.

Shot scales

Measure scale as magnification of the UI at the focal point, relative to its native size:

| Scale | Magnification | Use for | Depth of field | |---|---|---|---| | Extreme macro | 5–7× | A single tab, a button, a nav item, a status badge. One or two words fill a third of the frame. | Only the subject is sharp. Everything else is heavy bokeh. | | Macro | 2.5–4× | A composer with a line of typing, a few rows of a list, a code hunk | A band 2–4 text lines deep is sharp | | Medium | 1.5–2.5× | A panel at work: a list streaming in, a document writing itself, a diff with a sidebar | A wider band is sharp; the far edge and near edge stay soft | | Wide | 0.8–1.1× | The payoff only: the whole window, near-frontal, with content scrolling or changing | Mostly sharp; the frame edges still soften |

Macro shots must stay crisp. Rasterise the UI at the resolution of the magnification (for example 6×) before the camera scales it. Never upscale a 1× bitmap.

Camera angle

This is the signature of the look. Except for the wide shot, the camera is **low and oblique**, looking across the UI plane:

• **Tilt