Video Creation

---
name: video-creation
description: Direct a video project from a conversational brief through a reproducible production. Use when creating a new video, deciding the production approach, turning uploaded assets into a video, scripting or storyboarding, or revising an existing video.
---

# Direct video creation

Treat the conversation as the creative brief. Do not force the user through a formal plan or expose implementation details unless asked -- with one exception, below: a production that spends the user's money on generated footage has checkpoints, and holding them is not the same as making someone fill in a form.

## Work inside the project

- Treat `uploads/` as immutable user-owned source material.
- **Working directly in chat:** use `work/` for scripts, manifests, generated shots, audio, frames, and temporary files; put final playable videos in `outputs/`. A project can hold more than one production, so give each its own folder — `work/productions/<slug>/` — and keep that production's character specs and reference images together in `work/productions/<slug>/characters/<name>.md` and `.png`. Record those exact paths in `production.json`; the panel that shows a character is told where it is rather than guessing.
- **Running as a workflow stage:** write only inside your own step folder under `runs/<iteration>/<group>/execution/<stage>/`. `work/` and `outputs/` are not yours, are normally empty, and are not where a stage's output lives — treating them as the source of truth after a stage runs reports that nothing was produced when the artifacts exist.
- Keep reusable source files and commands so this same resumed session can revise the video later.
- Never publish, share, or upload a result.

## Understand the request

Infer as much as possible from the chat and uploaded assets. Establish only the details that materially affect the result:

- intended audience and outcome;
- platform, aspect ratio, resolution, and approximate duration;
- core message, tone, visual references, and call to action;
- narration, presenter, music, captions, and brand assets;
- whether to edit supplied footage, generate new shots, or combine both.

Ask one concise question only when a missing choice would substantially change the result or cost. Otherwise make a reasonable choice and state it briefly.

**This changes when the production will generate footage.** The guidance above is calibrated for uploaded assets and deterministic composition, where a wrong guess costs a free re-render. Paid generation is different in kind: a wrong character or a misjudged scope is money already spent, and no amount of later editing recovers it. For any production that will call `fal-ai` or `google-ai`, work through the checkpoints below instead of inferring your way to a finished video.

## Checkpoints for a generated production

Direct chat has no stage gates -- the `longform` and `shortform` workflows
do, and running in chat does not mean skipping what those gates are for. It
means you hold them yourself. Stop at each checkpoint and let the user
answer before spending:

1. **Before the first paid call, choose characters first.** Resolve whether
   any character, presenter, or product must recur across shots. If so, write
   its visual spec, then present at most three live-verified character-model
   choices from `video-model-selection`. State the exact provider/model,
   why it fits the subject, relevant controls, and current billing evidence.
   Recommend one but do not choose silently: wait for the user to name a
   model and approve the stated reference-pack spend. That model/provider is
   then committed to the subject's whole arc unless the user explicitly
   changes it. In the same compact question resolve which provider keys
   actually exist, the cost ceiling or maximum paid calls, and the retry
   allowance. If no subject recurs, record that characters are not applicable
   rather than inventing one.
2. **Show the plan before building it.** When the script and shot list
   exist, call `show_document` for each so the user reads what they are
   paying for. A shot list is cheap to change and expensive to regret.
3. **Show every recurring character before generating a single shot of it.**
   Once its spec and reference image exist (see `video-cinematography`),
   call `show_character` and wait. This is the highest-value checkpoint in
   the whole product: every later shot is conditioned on that reference, so
   an unapproved face propagates through the entire piece and can only be
   fixed by regenerating all of it.
4. **Generate one shot, then stop.** The first shot of a new character,
   scene, or model choice is a sample, not a commitment. Generate it alone,
   show it with `show_video` as a Preview (omit `qa_report_path` until the
   final quality pass), and wait
   for the user's reaction before generating anything else. If the batch
   has several unrelated shots, one representative sample is enough --
   commit the whole direction on one unapproved guess only when the user
   has explicitly said not to check in.
5. **Never let stitching be the first look.** Do not generate several clips
   and hand the user a combined preview as their first view of any of them
   -- by then every clip in it was made without feedback, and rejecting the
   combination means rejecting all of them at once. Show each new clip on
   its own before it is added to an assembly with anything else.
6. **Then generate the rest**, staying inside the agreed ceiling, and
   report what was spent against it.

Skipping these because the user seemed to be in a hurry is the wrong trade:
they are what makes a paid production correctable while correcting it is
still cheap. A user who genuinely wants no checkpoints will say so, and
that is a decision they get to make explicitly rather than one you make for
them by staying quiet. Generating a whole batch and presenting only the
finished, stitched result is exactly the failure mode this section exists
to prevent -- it is not a shortcut, it is the checkpoint being skipped.

## Inspect before producing

1. List the files in `uploads/` and inspect their type, dimensions, duration, frame rate, audio streams, and orientation with local tools such as `file`, `ffprobe`, and sampled frames.
2. Never infer asset contents from filenames alone.
3. Preserve logos, faces, product appearance, and brand colors from supplied references. Do not invent exact brand claims.
4. Prefer editing existing assets and deterministic composition before paying to regenerate usable material.

## Shape the story

- Give every video one clear job and one primary audience.
- For short-form video, prefer `hook -> value/proof -> action`.
- Keep each shot responsible for one idea. Match the visual change to the spoken beat.
- Put exact wording, logos, UI, prices, and captions into the editing/overlay layer, never into an AI-generated shot.
- For presenter reels, a reliable pattern is host hook, screenshot-worthy value card while narration continues, host close/CTA, then a short end card.
- Begin every fresh video with `longform-cinematic-video`, regardless of runtime, so the cinematic contract, continuity, sound world, and final edit are designed as one film. For a short piece, scale its chapter/sequence artifacts down rather than switching to a less coherent visual grammar.

## Make the work resumable

In direct chat, create or update `work/production.json` before substantial media work. Record:

- target specifications and creative direction;
- source assets and their roles;
- script or beat list;
- shot status and generated filenames;
- for an AI-generated production, every recurring character/subject: the path to its spec and reference image under `characters/`, and which model and provider its arc is committed to (see `video-cinematography`);
- music, caption, and overlay decisions;
- final output versions and QA status.

Use stable, descriptive filenames. Never overwrite an approved output; write `outputs/<slug>-v01.mp4`, then increment the version.

As a workflow stage, the equivalent record is your stage's own artifact (research.md, proposal.md, script.md, scene-plan.md, or the asset/edit/render/QA files) — the next stage reads it as its dependency, so put in it whatever that stage needs to avoid re-deriving your work. Other skills refer to this record as `production.json` for brevity; read that as `work/production.json` in direct chat and as your stage's own artifact when running as a workflow stage. Never write `production.json` or `characters/` outside your step folder as a stage.

## Choose the production path

- Use local editing for trims, crops, concatenation, audio, captions, and supplied footage.
- Use programmatic overlays for exact text, branded cards, product UI, or repeatable templates.
- Use `longform-cinematic-video` as the director for every new production. It coordinates story, cinematography, continuity, provider capabilities, generation when approved, editing, and seam review around one sequence plan.
- Keep every production cinematic. HyperFrames may be used selectively inside it for exact wording, UI, prices, typography, diagrams, camera motion over supplied assets, overlays, transitions, and compositing when the user wants that treatment or the approved shot list calls for it. It is not a separate route and must never replace a photoreal character, performance, location, or continuity-critical generated shot.
- Use the `video-editing` skill for assembly, captions, audio, and exports.
- Use the `video-quality` skill before presenting a version as complete.

Avoid paid multi-variant generation unless the user requests alternatives. Cache every successful generation and never repeat a paid call merely to inspect its response.

## Finish the turn

In direct chat, when work produces a video, report its relative path under `outputs/`, summarize the creative result in plain language, and mention any unverified requirement. Do not include provider or command details unless asked.

As a workflow stage, finish by writing your required artifact and nothing else — the product reports progress to the user from stage state, not from your reply text.