video-gen

Video generation

Choose each shot's source independently: existing media, a model-generated clip, or graphics in an editable Remotion project. Name the executable tool at each handoff. The video model comes from pi-video-gen.defaultModel; image generation uses pi-image-gen's active model. <outputDir> is the configured pi-video-gen.outputDir, defaulting to <cwd>/.video-gen; /video-gen doctor reports its resolved path.

Route the task

Honor the user's specified method and existing usable material. Read only the relevant assembly guide:

For a product film, demonstration, capability showcase or authored explainer, read film direction before designing scenes. An explicitly supplied edit, single clip or straightforward assembly follows its supplied instructions without that planning stage. For continuous UI/graphic handoffs, film direction routes to the motion-authoring guide. Read shot planning and frame preparation only when recurring identities, narrative continuity or missing reference frames require it.

Execution rules

• Preserve scope. Reuse suitable assets; generate or replace images when needed or explicitly requested. Use image_generate for those images and read the installed image-gen skill before using it. If it is unavailable, disclose the gap and continue only with suitable existing material or an agreed alternative. Any user restriction on generation charges also applies to image calls.
• Model preflight. Before preparing new generated-video requests, call video_capabilities and respect the active model's durations, ratios, audio, frame and trusted-asset support. Local-only work needs no video-model credentials or capability call. For Seedance recognizable portraits or provider-managed portrait/material choices, read Seedance assets before selecting inputs or preparing a paid call.
• Paid scope. Before the first paid video call, state the generated shot count and durations, provider/account, model and exact asset choices. Obtain approval unless that exact scope is already authorized; reuse approval for unchanged resumes using the saved job identity. A material scope change needs agreement. A prepared batch uses one initial video_render call per requested version; resume the same spec after interruption. Additional prototypes or versions must serve the requested task.
• Cost. State call counts and durations. If the user requests prices, verify current provider pricing and state the assumptions; if pricing cannot be verified, say so rather than guessing. Do not promise a fixed completion time.
• Immutable jobs. Revised inputs or frozen project source require a NEW job directory. Rerunning the SAME spec resumes completed shots without resubmitting them. Preserve saved clips and remote handles; never delete shot outputs to force a retry. Missing or changed committed artifacts fail integrity checks rather than being silently regenerated.
• Degradation. When a capability or preflight check fails, explain supported alternatives and obtain agreement for a materially changed result. Omit unsupported native-audio cues; if requested audio would be lost, resolve that gap before generation. Narration uploads and silent-subtitle fallbacks follow the Timeline guide's disclosure and agreement rules.
• Cancellation. Stopping local polling/rendering may leave a remote task running and billable; Ark remote cancellation is unverified. Report that limitation.