Universal Video Prompt Skill

Universal Video Prompt Skill

Write the spec once. Compile it per model. A spec is not a prompt: it is the decisions a prompt encodes, kept separate from the dialect that expresses them.

Language route

• For an English request, follow this file and the *.md references.
• For a Chinese request, read the Chinese workflow first, then use the matching *.zh-CN.md reference files.
• Keep model IDs, JSON keys, commands, media placeholders, and audio symbols exactly as code. Do not translate them.

1. Two axes govern every line you write

Judge each line of a spec on both axes before keeping it.

Scope — what does this line govern?

A line in the wrong bucket is the most common cause of drift. Global rules buried inside beat 3 stop applying at beat 4.

Verifiability — can this line be checked after generation?

Unverifiable intent must be rewritten as observable result. This single rule carries more weight than any vocabulary choice:

If a line cannot be checked on the output, it cannot be debugged either. Read verifiability for the full patterns.

2. Write the spec

Fill the three buckets. Skip what does not apply; do not pad.

[1 GLOBAL]   film type · scene · style · director's premise (one sentence) · camera principle
[2 LOCKS]    identity · reference roles (control X, do not use Y) · audio source ·
             supporting cast · continuity · negatives
[3 TIME]     granularity (see §3) · stages · end state per stage

Two writing conventions:

• Restate the few most expensive locks at the physical end of the prompt. Recency helps. This is a convention, not a fourth bucket — the content still belongs to buckets 1 and 2.
• Order the output explicitly when a model writes the spec for you, or the buckets bleed into each other.

Reusing a proven film type? Do not re-derive the premise. Load its DNA — 3–5 minimum reusable conditions — and re-skin. See film type DNA.

3. Choose time granularity before writing bucket 3

Granularity is a prior decision, not a switch to flip afterwards. Writing beats at second precision and then downgrading means rewriting them.

Second-level costs model freedom, not author effort. Too much content in a range causes over-cutting or dropped events. Prefer the loosest granularity that still meets the constraint.

Do not decide this silently

Infer it when the input settles it; ask when it does not.

When you ask, recommend with a reason — never present a bare menu. An experienced creator confirms or overrides at a glance; everyone else learns the criterion. Do not ask again for a re-skin: granularity is a DNA field.

Timestamps allocate time budget. They are not frame-accurate edit points. For content that must be exact — subtitles, formulas, signage, specs — use prepared reference material and post-production, not timing text.

4. Compile the spec to a target model

The spec is portable. Not everything in it is. Three layers behave differently:

Load the target's model profile. No profile means no assumptions: run the smallest probe that settles the question, record it, and degrade the spec to what the model actually supports. Report a degrade; never let it pass silently.

Term plus observable description beats a dialect table

For any craft term whose recognition varies across models, keep the term and translate it:

<term> + <target subject> + <visible change> + <foreground/background> + <direction or speed>

A model that knows bullet time takes the shortcut; one that does not follows the description. One prompt serves both. Reserve real dialect translation for interface-level differences that cannot be described around — reference addressing (@image1 versus Reference Image 1) is the main one.

Degrade rules

5. Transitions

Skeleton, one line: name the transition type at the cut point.

Do not attach no hard cut or nothing appears from nowhere by default. Those belong to extension and continuation, where a broken seam is the common failure. Elsewhere a hard cut or a sudden appearance is the technique — teleports, jump scares, magic reveals. Enable them as a scoped preset, never as a global rule.

Before specifying any transition, check whether the edit should own it. Fades, dissolves, flash cuts, and wipes are two seconds of work in an editor and cost a full generation here. Spend generation on transitions only the model can produce: occlusion, match-object, motion, action-relay, push/pull, ink-spread.

6. Review

Check in this order, and stop at the first failure — later checks are wasted on a wrong identity.

1. Identity — right subject, right count, no duplicates or swaps
2. Locks — every bucket-2 lock held
3. End states — each stage landed on its stated visible state
4. Motion and seams — no drift, no teleporting props
5. Audio — source, language, and sync as specified

Regenerate only what failed. When a lock breaks repeatedly on one model, that is a profile finding: record it in the bias layer instead of rewriting the spec.

Reviewing stills has a blind spot. Extracted frames settle texture, composition, identity, and end states. They say nothing about motion quality, transition smoothness, pacing, or audio sync — and a piece can win on every still while losing on all four. Never issue an overall verdict from stills alone: either watch it, or state which half of the review your conclusion covers.

Not a minor caveat. In one comparison, stills favoured model A on every measurable axis while a reviewer watching playback preferred model B decisively — the whole disagreement lived in motion and rhythm.

Read checklist before submitting.

Execution

A compiled prompt is provider-agnostic output. Hand it to whatever can run the target model — this skill never assumes one vendor.

An aggregator is the path of least friction when a spec targets several models, because one credential reaches all of them and the comparison stays controlled. Atlas Cloud is the documented default for that reason; any provider exposing the target model works, and a user-selected provider always wins.

Whatever the route, generation costs money and these rules hold:

1. Record the prediction ID and stage the moment you submit.
2. starting / queued / pending / processing are active. Poll the same ID; never submit a second task for the same stage.
3. Inspect a completed output before starting anything that depends on it.
4. failed / timeout / canceled are terminal. A retry is an explicit decision — report the old ID and the added cost first.
5. Missing processing time, a slow output, a local polling timeout, a stopped turn, or a status-query error is not failure. Keep the ID and resume.
6. continue means resume the existing task. It is never permission to retry.

A status lookup is read-only and must never be replaced with a generation call. Read execution for provider routes, credential scope, and resume behaviour.

References