Kandinsky 6.0 Pro Text-to-Video Prompt Recipes for Developers

Why Prompt Structure Beats Prompt Length

Long prompts feel productive. You describe the lighting, the mood, the background, the model of the car, the color of the sky—and then you get a clip that ignores half of it or, worse, blends everything into a muddy compromise. Text-to-video models like kandinsky-6.0-pro/text-to-video don't reward verbosity; they reward structure.

A structured prompt does three things a free-form paragraph doesn't:

• It separates concerns. Shot type, subject action, and camera behavior are independent variables. When they're tangled in one sentence, you can't tell which part caused a bad output.
• It makes comparisons possible. If every prompt in a batch follows the same skeleton, differences in output are attributable to the parts you actually changed.
• It's templatable. A prompt with fixed slots can be parameterized and generated programmatically—essential once you move from manual testing into a pipeline.

Throughout this article we use a three-part recipe:

[SHOT] + [SUBJECT & ACTION] + [CAMERA]

Short, ordered, and repeatable. The goal isn't to write less for its own sake—it's to write predictably, so that the same recipe with one slot swapped gives you a meaningful comparison instead of a different movie. Everything that follows builds on this skeleton: copy-paste templates, camera phrasing, an iteration loop, and finally wiring the whole thing into an API call.

The Anatomy of a Text-to-Video Prompt Recipe

Before writing recipes, understand what each block is doing.

Shot

The shot block sets framing and duration intent: close-up, medium shot, wide establishing shot, overhead, low angle. This is the single highest-leverage line in the prompt because it anchors composition. If the shot is wrong, nothing downstream can rescue the clip.

Keep it to one phrase. Wide establishing shot beats a shot that shows the whole scene from far away so you can see everything in the environment.

Subject and action

This block describes what moves and how. Be concrete about the subject and use one primary action per clip. Two competing actions in one prompt usually produce a subject that does neither cleanly.

• Good: a cyclist rides left to right across frame
• Risky: a cyclist rides while waving and the camera zooms and the crowd cheers

If you need a second action, ask whether it belongs in a separate clip.

Camera

Camera phrasing tells the model how the viewpoint behaves: static, pan, tilt, dolly in, orbit. It's the block developers most often skip—and the one that most affects whether a batch of clips feels coherent. Short, imperative phrasing works best; see the dedicated section below.

What to leave out

Recipes intentionally omit long adjective chains, emotional narration, and negative instructions phrased as prose. If a detail doesn't map to shot, subject, or camera, it's usually noise at this stage. Add it back only after the core recipe produces a stable result.

A useful mental model: each block feeds the same output frame from a different direction—composition, motion, and viewpoint. When one block is vague, the model fills the gap with its own priors, and that's where inconsistency creeps in.

Copy-Paste Recipes for Common Shots

Each template follows [SHOT] + [SUBJECT & ACTION] + [CAMERA]. Swap the bracketed values; keep the structure intact.

Product hero shot

Close-up product shot of a [PRODUCT] rotating slowly on a seamless surface, soft studio light, camera locked off, shallow depth of field

Use for e-commerce loops and app hero clips. Keep the rotation the only motion.

Establishing environment

Wide establishing shot of [ENVIRONMENT] at [TIME OF DAY], light haze in the air, slow forward dolly

Good for intros and section transitions. The dolly adds depth without stealing focus.

Character or figure motion

Medium shot of [PERSON OR FIGURE] [PRIMARY ACTION], natural pace, camera static at eye level

One action only. If the figure needs to enter and then act, split into two clips.

Abstract or background loop

Full-frame abstract shot of [SHAPE OR PATTERN] drifting slowly, [COLOR PALETTE], gentle camera drift

Designed for seamless looping backgrounds. Avoid strong directional motion so the loop point is less visible.

UI or screen-style footage

Straight-on shot of [DEVICE OR SURFACE] displaying [CONTENT], subtle parallax, camera locked, no rotation

The locked camera keeps text and interface elements stable—critical if you'll composite real UI on top.

Nature and texture detail

Close-up shot of [NATURAL ELEMENT] moving gently in [CONDITION], macro framing, slow lateral drift

Use sparingly in batches; texture clips are where model variance shows up most, so keep the camera motion identical across a set when you compare.

Camera and Motion Phrasing That Reads Clearly

Camera language is where prompts quietly break. Models respond better to short, conventional phrasing than to descriptive prose, and consistency across a batch matters more than eloquence.

Use a small vocabulary

Pick a fixed set of camera terms and reuse them everywhere. A workable starter set:

• camera static / camera locked off
• slow forward dolly / slow backward dolly
• pan left / pan right
• tilt up / tilt down
• orbit around subject
• handheld drift

Resist inventing compound moves like "dolly-zoom with a slight arc" unless you've verified the model handles them. Every unusual phrase is an untested variable.

Keep subject motion separate from camera motion

These are two different instructions and should live in different slots. A cyclist rides left to right describes the subject; pan right describes the camera. Writing the camera follows the cyclist merges them and makes it unclear which one the model should prioritize.

Specify pace

One word—slow, steady, brisk—is usually enough. Pace words anchor how much of the clip's duration the motion consumes, which matters when you need clips of a fixed length to cut together.

Keep phrasing constant within a batch

If you're generating ten variants to compare, keep the camera line byte-for-byte identical. Changing both the subject and the camera between runs means you can't attribute a difference to either. This is the single most common mistake in ad-hoc prompt testing.

Prefer positive, observable instructions

Describe what the camera does, not what it avoids. Camera static is a clear instruction; camera doesn't shake asks the model to reason about a negative. Positive phrasing also makes your prompt library easier to search later.

Tuning a Recipe Without Breaking It

A recipe is a starting point, not a fixed asset. The discipline is in how you change it.

Change one slot per run

Pick a base recipe, generate a baseline, then modify exactly one block—shot, subject, or camera—and regenerate. If you change the shot and the subject together, you learn nothing about which adjustment helped. This constraint feels slow at first and saves significant time once your library grows.

Log everything

For every run, record:

• the full prompt string, unmodified
• which slot was changed and to what
• a short verdict (keep / reject / revisit)
• any obvious artifact or deviation from the recipe

A plain text file or a spreadsheet column works. The point is that a prompt you liked three weeks ago is reproducible, not reconstructed from memory.

Version your recipes

Treat prompt templates like code. Give them identifiers (product_hero_v1, establishing_city_v2) and keep a changelog line for each version. When a downstream clip looks wrong, you can check out the exact recipe that produced it.

Know when a recipe is done

A recipe is stable when three consecutive runs with the same parameters produce outputs you'd accept. At that point, freeze it, tag it, and move to the next shot type. Continuing to tweak a working recipe trades stability for marginal gains.

Prune aggressively

Most recipes you write will be discarded. Delete or archive ones that never stabilized—an unmaintained library of half-working templates is worse than a small one you trust.

Putting Recipes Into a Pipeline

Manual iteration is for discovery. Production needs parameterized, versioned prompts sent through a stable endpoint.

Parameterize the template

Store recipes as templates with named slots rather than finished strings:

{
  "id": "product_hero_v1",
  "template": "Close-up product shot of a {{product}} rotating slowly on a seamless surface, soft studio light, camera locked off, shallow depth of field"
}

Rendering is trivial: substitute {{product}} at call time. The template stays fixed; only the slot values vary. This is the same one-variable-at-a-time discipline from manual testing, applied programmatically.

Keep it on one endpoint

Route both experimentation and production traffic through the same model endpoint, kandinsky-6.0-pro/text-to-video. When your test calls and your shipping calls hit the same API, a prompt that worked in exploration behaves identically in production. Switching surfaces between phases is a common source of "it worked yesterday" bugs.

Version and log at the call site

Every generated clip should be traceable to a recipe ID, a rendered prompt, and a timestamp. Log these alongside the output reference. When a clip is flagged, you want to answer "which recipe version and which parameters produced this?" without a forensic exercise.

Batch thoughtfully

When generating variations, vary one slot across the batch and hold everything else constant—including the camera line. This keeps the batch comparable and makes automated review or human spot-checks meaningfully faster.

Fold results back into the library

A recipe that stabilizes in production should be tagged and reused. Over time the library becomes your team's real prompt asset: a set of proven, versioned building blocks rather than a folder of one-off strings.

Once templates are parameterized and versioned, the same recipe powers a manual test and a production batch without modification.

Common Failure Modes and How to Read Them

Weak outputs usually aren't random. Map the symptom to the block most likely responsible and change only that block.

Compositions drift between runs

Likely cause: the shot block. Framing phrases that are vague or compound—a wide shot, somewhat close—give the model room to interpret. Tighten to a single canonical shot term and hold it constant across the batch.

Subject does the wrong thing or does too much

Likely cause: the subject and action block. Multiple actions in one prompt, or actions described with vague verbs. Reduce to one primary action and use observable language.

Excessive or erratic camera motion

Likely cause: camera phrasing, or its absence. With no camera instruction the model invents motion. Add an explicit camera static or a single named move; remove prose that implies movement—the scene sweeps across reads as a camera instruction.

Details appear that you didn't ask for

Likely cause: overlong prompts. Adjective chains and mood language invite the model to fill gaps. Cut the recipe back to the three blocks, confirm the core works, then reintroduce details one at a time.

Consistent but boring output

Likely cause: an over-constrained recipe. If every block is locked and the result is flat, the fix is usually a single controlled change—one new camera move, one new action—not a full rewrite.

Results that won't reproduce

Likely cause: process, not prompt. Unlogged edits, changed camera wording between runs, or testing on a different endpoint than production. The remedy is the versioned library and single-endpoint discipline described above.

Reading failures this way turns each bad generation into a specific, testable hypothesis instead of a reason to rewrite everything.