Scenario Ad Variants

Scenario Ad Variants

Overview

One supplied source becomes an ordered set of independently specified edits. Preserve what the brief does not change, and keep every output traceable to the same source. A new storyboard from a product still belongs to scenario-video-ads; single-clip utilities to scenario-video-editing. Connection, discovery, submission and recovery follow scenario. If a sibling skill named here is missing from your available skills, ask the user to install it (npx skills add scenario-labs/skills --skill <name>); unattended, proceed from tool schemas and flag the gap.

Resolve only missing decisions: source, requested variants, exact copy, destination, runtime, audio policy and spend ceiling. Reuse answers already supplied. Distinguish a controlled comparison, where only the agreed variable changes, from creative exploration. Never multiply options into a Cartesian batch unless requested.

Quick reference

Use deterministic operations when they satisfy the brief. In gameplay capture, replacing a background generatively can also change geometry, UI or mechanic behavior. Do not silently treat such output as faithful gameplay. If preserving those pixels is mandatory and the available route cannot isolate the edit, report the limitation before spending. A generative preservation prompt is a request to verify, not a guarantee.

Source and variant records

Read asset_get for source dimensions, duration and frame rate; inspect the footage, its existing text, cuts and audio. Reference images have explicit roles: identity, product, style or replacement. Assign each variant a stable label and record its source asset, intended delta, invariants, exact copy, output specification and audio policy. Every independent variant starts from the source, never the last generated variant. A requested revision starts from the chosen variant when that is the user's intent.

Keep a compact local record of each variant's state: blocked, planned, submitted, pending, failed or verified; submitted job id; output ids; measured properties; QA outcome. Save the actual submitted payload, not just a prose prompt. A rendered output awaiting review is not verified. Retain completed variants and wait on pending jobs after interruption; a transport failure is reconciled through scenario before any resubmission. Retry only the affected failed variant within the remaining ceiling, keeping its original label. Changing the intended delta creates a revision, not an invisible retry.

For a generative edit, construct the prompt from the requested change, named reference roles, preserved identities/text/actions and the source timing. Use recommend with the need in the user's own words, then model_schema_get to establish supported video inputs, references, durations and audio controls. Never import another provider's duration or prompt-length limits. If the requested precision or media is unsupported, offer the nearest feasible route without promising equivalence.

Worked example: three hook variants from gameplay

The brief supplies a 15-second gameplay clip with audio and requests exactly three 9:16 exports. The hook copy occupies seconds 0 to 2: "Hold the line", "One hit left", and "Can you survive?". The gameplay, audio, runtime and final end card must not change. The source already has a clear hook area.

1. asset_get the source, then inspect it. Check that its measured shape, runtime and hook area support the brief. If existing hook text must be removed from flattened footage, ask for a clean source or agree a covering panel. Unattended, use a panel only if already authorized and it preserves all required visible content; otherwise mark affected variants blocked on a clean source and continue any independent feasible variants. Do not spend on blocked variants or generate new gameplay to erase text.
2. Record variants A, B and C with the same source and invariants. Render three exact text cards through scenario-text-overlay, with matching geometry and styling so copy is the only changed variable. Upload the rendered cards through scenario.
3. Follow scenario-video-assembly: model_schema_get on model_scenario-compose-video, Scenario's single deterministic compositor. Each payload uses the same source video layer and its audio, plus its own card as an image layer at the agreed time. Set canvasMode: "custom" with numeric canvasWidth/canvasHeight, and durationMode: "custom" with duration: 15. Give the source layer string width/height matching the canvas and fit: "contain" to preserve the whole picture without stretching; different source ratios leave bars, and cropping requires authorization. Set the card's string width/height, explicit placement and fit: "contain". Set fps from the measured source rate within the schema's whole-number range; disclose any required rounding. This compositor uses seconds in 0.1 increments; do not promise frame-exact timing beyond that contract.
4. Price each exact payload with model_run and dry_run: true. Fit submissions and any planned repairs inside the authorized ceiling. A quote is not payload or visual validation. Submit with wait: false, save each job id and use jobs_wait; pending jobs keep their ids.
5. Inspect every exported variant at the hook boundaries, throughout the gameplay and on the end card. Check the frames immediately before, at and after the requested endpoint: a timeline field does not establish whether the rendered endpoint is inclusive. Compare measured runtime and shape with the source. Check that audio stays synchronized and that the tail is intact. A succeeded job with a missing overlay fails. Report an endpoint mismatch instead of silently shortening the hook to hide it.
6. Deliver A, B and C in the requested order via asset_display and asset_download. Include the variant map and measured properties. Preserve the payloads and source references for revisions; these are a reconstruction recipe, not a native editable-editor project.