flux-3-product-ads

Files (3)

• SKILL.md
• metadata.json
• pipeline.md · references/

SKILL.md (first lines)

# FLUX 3 product ads

A finished spot is two jobs, not one. FLUX 3 generates picture and voice. A
deterministic pass cuts, times, captions and masters them. Keep the boundary
sharp: the model handles what only a model can, and everything a computer can
compute exactly stays out of the model's hands.

Route facts this skill depends on live in `flux-3-generate`. Read it first for
`/v1/flux-3-video`, polling and download behaviour. Continuation behaviour, including
what a `v2v` link actually returns, lives in `flux-3-keyframes-continuation`.

Everything here has been run at 12, 30 and 60 seconds. Where a rule only holds at one
length, it says so. **Assume nothing written for a three-shot ten-second spot
generalises without being re-tested at length**: on the run that produced this
revision, two pieces of timing logic that were correct at 10 seconds turned out to
have a silent correctness bug and a complexity bug that only appear in a longer read.

## Shape of the work

1. Design shots that survive generation.
2. Generate picture plates and VO in the same round.
3. Screen VO by machine, then listen.
4. Derive timing from the audio.
5. Assemble deterministically.
6. Gate on measurements, including the failures that look like passes.

## 1. Shot design

Three cuts carry a 10-second spot: **reveal, proof, payoff**. Reveal establishes the
object, proof shows it doing the one thing the copy claims, payoff lands the brand.

Longer spots need more beats and more plates. A plate yields roughly 4 to 5 seconds
of usable middle once a dissolve is allowed for, so **shot count is length divided by
about 4.5, rounded up**, and a shortfall does not degrade gracefully: it fails the
build outright with no legal cut placement. Measured: 12s took 3 plates, 30s took 6,
60s took 11. A 60-second spot planned with 9 plates could not be cut at all.

At 30 seconds and beyond, reveal/proof/payoff no longer fills the time. What worked:
hook on the material, the object whole, a detail, the mechanism, a state change, what
the product does for you, brand. The structure that matters is that each beat earns
its own shot, not that it has three parts.

**Anchor motion at its endpoints.** A generated clip is trustworthy at its first and
last frame and inventive in between. Motion whose midpoint is implied by its endpoints
survives; motion that requires the model to invent geometry does not.

Works: a highlight travelling across a surface, a collar rotating through a short arc
and stopping, a handle rising and stopping, a lid parting slightly.

Two shots that *appear* to work and do not: **a hand drawing an ink line across
paper**, and **a phone descending into frame and landing on a product**. Both were
predicted to fail as "travel" and "an object entering the frame". Both arrived
looking correct, passed every signal gate, went into masters, and were rejected on
sight. The pen's ink ran ahead of the tip while the paper slid underneath; the
"phone" was a featureless slab as wide as the pad it landed on. Arrival is not
correctness, and this is the trap: the failure mode of a *nearly* achievable shot
is a plate that is wrong in the object rather than broken in the signal, which is
invisible to every measurement. See the semantic gate in section 6.

Fails: multiple revolutions, and rotation of two bodies at once. A crank asked for 2
to 3 full revolutions rotated to about 180 degrees, then deformed and vanished as the
arm occluded itself. A knurled collar asked to spin two revolutions *while* the head
it sits on tilted produced no motion at all: an inert clip where neither action
happened.

The predictor is not travel and not occlusion. It is **whether the model must invent
geometry it has never seen**. A hand crossing frame is a rigid body with a known
silhouette. A descending phone is a rigid body. A crank going around 720 degrees has
to render its own far side, and that is where it dies. Design against invented
geometry, not against movement.

**A quarter-turn is not a safe fallback for a rotation shot, it is an invisible one.**
The safe version of the failed collar shot technically succeeded and was still
unusable, because a small rotation of a knurled ring at macro reads as nothing
happening. When a rotation shot fails, the shot that replaces it should be **light
moving across a static object**, which is the most reliable motion in the system and
the one that consistently looks alive.

**When an object must arrive in frame, generate it leaving and reverse the clip.**
This is the highest-leverage trick in the section, because it converts an
invention problem into a translation problem. Three attempts at the same shot, one
variable:

| Attempt | Approach | Result |
|---|---|---|
| 1 | describe a descending phone; keyframe contains no phone | slab as wide as the pad |
| 2 | describe the phone in far more detail (two-thirds pad diameter, 8mm thick, dark glass front, metal rails, rounded corners, explicit no-warp instruction); same phone-less keyframe | still a slab, now tilted and overhanging the pad |
| 3 | keyframe already contains a correctly proportioned phone; generate the phone *lifting away*; `ffmpeg -vf reverse` in post | correct phone, correct scale, constant through the move |

Prompt detail did not fix invention. Removing the invention did. If the object is
in the keyframe, the model only has to move something it can already see, and
scale cannot drift because it was never chosen by the model. Cost: one filter.

Two things to watch. Author any lighting change in the direction that reads
correctly *after* reversing, and check the source still's camera height against its
neighbours, since a still shot for a different purpose may not cut with them.

**Reversing moves the action to the other end of the clip, and any timing you
already derived is now wrong.** This is the cost the trick hides, and it surfaces
as a sync failure in a spot that was passing before. The lift plate peaked at
5.79s of a 6.04s clip, a quarter-second before the end. Reversed, that same peak
sits at 0.17s. Nothing else changed: same duration, same frame count, same file
size class.

That matters because a plate can only be slipped *later* into its segment, never
earlier than its own first frame. So the reachable window for an action collapses
to roughly `[peak - segment_slack, peak]`, and an action at 0.17s can only ever
land in the first fraction of a second of its segment. The anchor word chosen for
the pre-reverse plate, several seconds in, became permanently unreachable, and the
build reported it correctly as a clamp:

```
slip : shot 3 in=0.00s -> action 14.32s vs word 15.62s (-1.30s)
       CLAMPED (reachable 13.00-14.32s, word at 15.62s)
```

The trap is that this looks like drift. The plates were byte-identical to the run
that passed, the VO was untouched, and the durations matched to the sample, so
every "did something move?" check comes back clean while the numbers disagree with

From black-forest-labs/skills, MIT.

More from black-forest-labs/skills