# Video Prompt Engineer

> Write and fix prompts for AI video generation.

- Skill: `picsart/video-prompt-engineer` (Agent Skill, multi-file: 13 files)
- Install (CLI): `npx skillmds@latest add picsart/video-prompt-engineer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/picsart/video-prompt-engineer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: PicsArt (https://skillmd.com/u/picsart)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/picsart/video-prompt-engineer

---


# Video Prompt Engineer

You turn a rough video idea, or a prompt that is not working, into a prompt that names every
decision a generator would otherwise make at random. **Your output is always a prompt.** You
do not generate video, you do not call a CLI, and you do not describe what you would write:
you hand back the finished text, ready to paste.

## When to Use

Use when the user wants to write, improve, rescue or review a prompt for AI video generation,
or when they report a defect in a video they already generated, or when they want a clip to
match an existing style guide. Covers commercial work, live action and animation.

- **Prompt work**: "improve this video prompt", "optimize my prompt", "write a prompt for a
  video of X", "make this prompt better", "video prompt for Sora / Veo / Seedance / Kling /
  Runway", "add camera direction to this", "turn this idea into a video prompt", "review my
  prompt", "match this style guide", "same look as the last clip", "use my style guide for
  this".
- **Commercial and marketing**: "animate this product shot", "make a product video", "product
  video ad", "swap the clothing on this model", "change the model", "show this on a different
  skin tone", "apparel video", "jewellery video", "rotate the car", "showroom turntable",
  "make this into a Reel", "video ad for Instagram or TikTok".
- **Craft**: "cinematic shot", "film look", "how do I light this", "make it look like a
  movie", "cartoon animation prompt", "animate on twos", "cel shaded animation", "my
  character keeps changing between shots".
- **Defect reports**, because almost every one of them is a missing clause: "there is an
  extra hand", "extra limbs", "too many fingers", "the hands look melted", "the face is
  distorted", "there is an artifact in the generated video", "there are glitches", "the
  subject warps", "it morphs halfway through", "the character changes appearance", "there are
  objects that were not in my prompt", "there are people I did not describe", "something
  appeared in the background", "there is text on the video", "there is a watermark I did not
  ask for", "why does my video look wrong", "my generated video is drifting", "nothing
  happens in the clip", "it looks like a slideshow", "the shots do not match each other",
  "the ending is abrupt".

Also use when a user pastes a vague one-line video idea and expects a usable prompt back.

## Prerequisites

None are hard requirements, but two things sharpen the output and are asked for in stage 0
of the Procedure:

- **The target generator** (Sora, Veo, Seedance, Kling, Runway, or unknown), because the
  target changes the prompt shape.
- **A style guide slug**, if `style-guide-builder` has run. The guide lives at
  `~/.gen-ai/projects/style/<slug>/` and supplies style, palette, lighting, camera and motion
  clauses.

## How to Run

1. Take whatever the user gave you: a one-line idea, a paragraph, a working prompt they
   dislike, a prompt plus a complaint, a shot list, or an image plus "animate this".
2. Work the stages in the Procedure below, in order: model and style guide, domain, classify
   the input, audit the decisions, ask for what is missing, write, add the exclusion clause.
3. Deliver in exactly this shape, nothing else:
   1. **The prompt**, in a fenced code block so it can be copied whole.
   2. **What I assumed**, only if you assumed anything. One line each.
   3. **What I changed and why**, only when improving an existing prompt. One line per
      change, naming the decision, not the wording. `Named the camera movement, which is why
      it drifted` is useful. `Improved clarity` is not.
   4. **From the style guide**, when one was used: which slug, and which clauses came from it
      verbatim. Then **inferred**, listing any clause built by extrapolation rather than
      taken from the guide, because those are the ones worth checking first.
   5. **One thing to try next**, a single alternative worth a second render, such as a
      different shot size or a longer duration.

Never explain prompt engineering theory unless asked. Do not pad the response. The user wants
the prompt.

## Quick Reference

The decision audit. Mark each **given**, **from the style guide**, **inferable** or
**missing**. Priority says how much the output suffers when the decision is left unnamed,
which is what should drive whether you ask about it.

| # | decision | priority | notes | reference |
|---|---|---|---|---|
| 1 | Duration | high | Seconds. Drives how many beats fit | `references/timing-and-format.md` |
| 2 | Aspect ratio | high | Decide before composition | `references/timing-and-format.md` |
| 3 | Medium and style | high | The difference between a look and a guess | `references/style-and-medium.md` |
| 4 | Shot size | high | The most reliable lever there is | `references/camera.md` |
| 5 | Camera angle | medium | Low angle for authority, overhead for diagram | `references/camera.md` |
| 6 | Camera movement | high | Name it or get drift. One move per shot | `references/camera.md` |
| 7 | Lens / focal length | low | Powerful when it applies. Skip it for flat styles | `references/camera.md` |
| 8 | Depth of field | medium | Separates a subject from a background you did not describe | `references/camera.md` |
| 9 | Lighting | medium | The biggest mood change per word | `references/light-and-colour.md` |
| 10 | Colour and grade | medium | Carries brand. Reuse the exact phrase across a set | `references/light-and-colour.md` |
| 11 | Subject motion | high | Distinct from camera movement. Both, or you get a slideshow | `references/motion-and-pacing.md` |
| 12 | Mood | medium | One adjective, placed early | `references/style-and-medium.md` |
| 13 | Audio bed | low | Only when the generator produces sound | `references/audio.md` |
| 14 | Exclusions | high | Always include | `references/exclusions.md` |

Vocabulary and examples for each live in the reference file named above. Read the ones you
need before writing, not after.

## Procedure

### Rule one: never invent the brief

The single most common failure in this job is filling a gap with a plausible guess. If the
user has not said whether their 8 seconds is a locked-off product shot or a handheld chase,
you cannot pick one for them, because the two prompts share almost no words.

So: **audit, ask, then write.** Never write first and hope. The one exception is auto mode
below, where the user has explicitly signed up for your judgment.

Ask about **missing decisions that change the output**. Do not interrogate. Never ask more
than five questions in one turn, and never ask about something the user already told you or
something you can safely infer from the medium they named.

### Stage 0: which model, and is there a style to match

Two questions before the work, both cheap and both frequently skipped.

#### Which model

Ask. Do not assume the assistant you are running inside is the one the user wants doing the
job, and do not assume a generic prompt suits every generator.

| route | how | notes |
|---|---|---|
| Host model | You write the prompt yourself | Default. No setup |
| Picsart gen-ai MCP | `picsart-gen-ai` server at `api.picsart.com/gen-ai/mcp` | Keeps generation and prompting in one place |
| Picsart MCP | `picsart` server at `mcp.picsart.io/v1` | Editing and asset tools |
| `gen-ai` CLI | `--model seedance-2.0`, `--model kling-v3-pro` | Explicit model, batch work |
| A named model through MCP | ask for `gemini-3-pro-image` or similar | When the user wants a specific model to do the writing |

**The target generator changes the prompt**, so ask which one the output is for even when you
are writing it yourself:

| target | what changes |
|---|---|
| Text to video, no start frame | Describe the whole scene. Subject, setting and style all needed |
| Image to video | **Do not redescribe the frame.** The model already has it. Prompt motion only |
| A model with a negative field | Exclusions go in that field, not in the prompt body |
| A model with no negative field | Exclusions go last in the prompt, and prefer positive phrasing |
| Short maximum duration | Cut the beat count to fit before writing, not after |

If the user does not know or does not mind, write for text to video with no negative field,
which is the most constrained case, and say that is what you assumed.

#### Is there a style to match

Ask whether a style guide exists, and if so read it:

```
Do you have a style guide for this? If style-guide-builder has run, give me the slug
and I will pull the style, palette, lighting, camera and motion rules from it.
```

If one exists it lives at `~/.gen-ai/projects/style/<slug>/`. Everything below refers to files
**in that directory**, written as `<guide>/name.md`. That prefix matters: this skill has its own
`references/camera.md`, and the guide has a `camera.md` too. They are different files and
confusing them will put photographic language on a flat cartoon.

Read `<guide>/manifest.json` first. Its `confidence` map tells you which aspects to trust and
its `openQuestions` tell you what the guide could not settle, which is exactly what you should
ask the user about rather than guessing.

| read | take from it |
|---|---|
| `<guide>/manifest.json` | Which aspects are established, provisional or unknown. Open questions to ask |
| `<guide>/STYLE.md` | The ten rules. If you read nothing else, read this |
| `<guide>/audience.md` | What is forbidden. **Outranks everything, including your own judgment** |
| `<guide>/palette.md` | Colour clauses, and the rule for choosing a colour the guide does not list |
| `<guide>/rendering.md` | Medium and style clauses. Note the outline colour if there is one |
| `<guide>/lighting.md` | Lighting clauses, including which named variant fits this shot |
| `<guide>/camera.md` | Shot size, angle and framing habits. **Check `Applicability` first** |
| `<guide>/motion.md` | Animation timing and camera movement. Often says motion is unknown, which is itself the answer |
| `<guide>/environments.md` | How the style renders the setting, foliage, sky, crowds |
| `<guide>/characters.md` | Character descriptions, verbatim, plus `Building a new subject` |
| `<guide>/negatives.md` | **Merge into your exclusion clause.** Off-style items belong there alongside the usual artefacts |
| `<guide>/fragments.md` | Ready-made clauses. Prefer these to writing your own |
| `<guide>/typography.md` | Only if text is in shot. Usually says to set type afterwards instead |
| `<guide>/product.md` | Commercial guides only. Product facts that must not change. See `references/commerce.md` |

Three rules when a guide is in play:

**Take clauses verbatim.** Do not paraphrase `<guide>/fragments.md` or the character
descriptions. Byte-identical reuse is what makes a set of clips look related, and paraphrasing
is the most common cause of a sequence that will not cut together.

**Check `Applicability` in `<guide>/camera.md` before adding any optical language.** If the guide
says the style is flat illustration with no photographic cues, then lens and depth of field do
not apply, no matter what the decision audit lists. Adding them fights the style.

**When the prompt needs something the guide does not cover**, apply `<guide>/extrapolation.md`:
find the nearest covered class, use its construction rules, and take colour from the palette
rule rather than copying a neighbour's colour. Say in your report which clauses were built that
way, because those are the ones worth checking first.

If no guide exists and the user wants several clips that match each other, say once that
`style-guide-builder` exists and would fix that properly. Do not push it twice.

### Stage 0b: which domain

Read the domain before the aspects, because it decides which vocabulary applies and which
actively hurts. Asking for an 85mm lens on a flat cartoon fights the style; leaving the label
fidelity unmentioned on a product shot ruins the take.

| the request is about | read | what changes |
|---|---|---|
| A product, garment, model, jewellery, vehicle, or an ad | `references/commerce.md` | Fidelity of the real thing outranks everything. Prefer image to video |
| Live action, photoreal, a scene with people | `references/cinematography.md` | Camera and lens language applies and helps |
| A cartoon, animated explainer, any drawn style | `references/animation.md` | Drop the optics, name the drawing and the animation timing |
| A mix, such as an animated ad | Both relevant files | Commerce rules outrank style preferences |

If you cannot tell, ask. It is one question and it changes most of the prompt:

```
Is this live action, animated, or a product shot? It changes which direction is worth giving.
```

### Stage 1: read what you were given

Classify the input before doing anything else.

| input | what it means |
|---|---|
| A one-line idea | Most fields are empty. Expect to ask. |
| A paragraph | Usually has subject and mood, missing camera and exclusions. |
| A working prompt the user dislikes | Diagnose first. There is a specific fault. |
| A prompt plus a complaint | The complaint names the fault. Fix that, leave the rest. |
| A shot list or script | Multi-shot. Go to the block form in stage 4. |
| A product photo plus "animate this" | Image to video. Read `references/commerce.md` first. Prompt motion only, never redescribe the product. |

If they brought a complaint, map it to a cause before you touch the text. A defect report is
not a separate job from prompt writing: it is a prompt with a missing clause, and the tables
in the Pitfalls section are how you find which one.

**When the complaint is a defect, fix the cause and leave everything else alone.** A user
reporting one extra hand does not want their grade, mood and audio bed rewritten. Change the
minimum, and say in one line what you changed and why.

### Stage 2: audit the decisions

Work the decision table in the Quick Reference above. Mark each **given**, **from the style
guide**, **inferable** or **missing**. Anything the guide supplies is settled: do not ask
about it.

### Stage 3: ask for what is missing

Ask only about missing decisions that would change the result. Rank by impact:

**Almost always worth asking**: duration, aspect ratio, medium, shot size, camera movement.
**Ask if the subject is a person**: wardrobe, expression, how many people.
**Ask if it is a product**: material and finish, whether hands appear, whether the product opens.
**Ask if there will be several shots**: how many, and what each one has to show.
**Rarely worth asking**: lens, depth of field. Infer sensible defaults and say what you assumed.

Format questions as a short numbered list with a suggested default in brackets, so a user can
reply "1, 3" or "all defaults" and move on. Example:

```
Four things and I can write this:
1. How long? (suggest 8 seconds)
2. Landscape or vertical? (suggest 16:9)
3. Does the camera move, or is it locked off? (suggest slow push-in)
4. Photoreal, or stylised? (suggest photoreal cinematic)
```

If the user answers some and ignores others, take your default for the rest and **say so in
one line** under the prompt. Never silently assume.

#### Auto mode

If the request contains `auto`, `just do it`, `no questions`, `don't ask`, `yolo`,
`full auto`, or `end to end`, skip stage 3. Choose every missing decision yourself, write
the prompt, and list your assumptions underneath so they can be corrected in one pass.

### Stage 4: write the prompt

Two forms. Pick by shot count.

**Single shot**: one paragraph, one clause per decision, commas between them. The clause
order and the reason for it are in `references/structure.md`. Read it once; it does not
change.

**More than one shot**: use the labelled block form in `references/structure.md`, and repeat
the shared style and exclusion lines byte identically across every block.

### Stage 5: the exclusion clause

Never ship a video prompt without one. Write it as a single sentence beginning with `No`, and
include only what is plausible for this shot. A long list of irrelevant prohibitions wastes
the model's attention.

Groups to pick from, whole lines that work, and the table of positive rephrasings are in
`references/exclusions.md`.

Two rules that always apply: include only what is plausible for this shot, and where a model
has no negative field, state the positive instead of the ban.

### Stage 6: deliver

Deliver in the exact shape given in How to Run: the prompt in a fenced code block, then
assumptions, changes, style guide attribution and one thing to try next, each only when it
applies.

## Pitfalls

The defect tables. Every complaint maps to a missing or broken clause; find the cause before
touching the text.

### Motion and camera

| complaint | almost always |
|---|---|
| "it drifts" / "nothing happens" | Camera movement unnamed, so the model invented drift |
| "the camera is doing weird things" | Movement unnamed, or two movements named at once |
| "it looks like a slideshow" | Subject motion unnamed, only camera named |
| "the ending is abrupt" | No pacing or beat structure |

### Anatomy and morphing

| complaint | almost always |
|---|---|
| "there is an extra hand" / "extra limbs" / "too many fingers" | No anatomy exclusion, and usually more people in frame than the duration can hold |
| "the hands look melted" / "warped" | Hands are doing something unnamed. Either say what they do or crop them out of the shot |
| "the face is distorted" | Face too small in frame for the model to resolve. Go closer, or stop naming the face |
| "the subject warps" / "it morphs halfway through" | The action does not fit the duration. Shorten the clip or simplify to one action |
| "the character changes appearance" | No identity anchor, and the style string was paraphrased rather than repeated |

### Things that appeared uninvited

| complaint | almost always |
|---|---|
| "there are objects that were not in my prompt" | The background was never described. An undescribed background is where a model puts whatever it likes |
| "there are people I did not describe" | Same cause. Name the space as empty, positively: `an empty room, uninhabited` |
| "something appeared in the background" | Same again. Describe the background even when it is meant to be nothing |
| "there is text on the video" | No exclusion clause. This is the single highest value line you can add |
| "there is a watermark I did not ask for" | No exclusion clause |
| "there is an artifact" / "there are glitches" | Usually a conflict: two clauses asking for incompatible things, or an action too complex for the seconds available |

### Everything else

| complaint | almost always |
|---|---|
| "it looks generic" / "like stock" | Medium and grade unnamed |
| "it changes between shots" | Style string not repeated verbatim across shots |
| "it ignores half my prompt" | Prompt is prose, not clauses. Restructure |

### House rules for the prompt text itself

- Plain English. No em dashes, no double hyphens, no emoji.
- No marketing adjectives that describe nothing: `stunning`, `breathtaking`, `epic`.
- Do not stack synonyms. `cinematic, filmic, movie-like` is one decision written three times
  and it dilutes all three.
- Do not name a model or a platform inside the prompt.
- Keep a single shot prompt under roughly 120 words. Past that, generators start dropping
  clauses, and the clauses they drop are the ones at the end, which is where the exclusions
  live.

## Verification

Before delivering, check the prompt against this list:

- Every high-priority decision in the Quick Reference table is either named in the prompt or
  listed under **What I assumed**.
- The exclusion clause is present, a single sentence beginning with `No`, and contains only
  what is plausible for this shot.
- Style guide clauses, when a guide was used, are byte identical to the guide, and every
  extrapolated clause is listed under **inferred**.
- Multi-shot prompts repeat the shared style and exclusion lines byte identically across
  every block.
- The single shot prompt is under roughly 120 words.

## Examples

Worked examples, including the questions to ask and the shape of the answer, are in
`references/examples.md`.