Create original image-led narrative videos

Treat a studied video as evidence about general craft, not a prompt, storyboard, or style-transfer reference. Choose runtime, aspect ratio, genre, audience, and visual identity from the new brief, never from an unrelated example.

Evidence and originality boundary

Keep four labels in every analysis and production note:

• Measured: obtained from local media, a tool response, or a reproducible test.
• Transcript-derived: supported by captions or a written script, but not proof of delivery or editing.
• Visual estimate: a human observation from sampled frames, not a model or prompt fact.
• Unknown: not established; do not fill it with a plausible assumption.

A source video may teach general principles such as escalation, shot variety, or the use of recurring visual anchors. It must never become a production kit. Before generation, record the new premise, characters, locations, narrative question, motifs, visual grammar, ending, and rights/provenance ledger. Replace recognizable plot sequences, dialogue, character combinations, specific props, frames, voices, music, branding, and distinctive combinations. Never pass source frames into generation, clone a source voice, or imply that a source-specific model or workflow has been verified.

Gates before production

1. Discover Flow Automator's live tools, supported image models, actual model identifier, reference-image rules, credit costs, output rights, resolution, concurrency, and export options. “Nano Banana 2.1” is a requested label, not an executable model ID. Do not silently switch models.
2. Discover the actual ElevenLabs account's narration and, if available, music capabilities, voice consent, output rights, licensing, prices, character limits, generation duration, formats, and rate limits. Never invent endpoints or voice IDs. No credential belongs in prompts, logs, artifacts, or skill files.
3. Record which capabilities were checked, when, by which tool, and with what result. A documentation page or remembered endpoint is not proof that this account can perform the operation.
4. Stop before any paid generation, upload, publication, or external sharing until the user approves the specific operation and spend limit. A capability check is not approval to spend.

Build the executable preproduction package

1. Define the duration, aspect ratio, delivery destination, and measurable audience promise. Draft a beat sheet with setup, successive changes to the central question, reversals, an earned climax, and a resolution or intentional open end. For every beat specify what the audience knows, what remains uncertain, and what changes. Do not copy a studied video's beat order.
2. Write the narration draft and read it aloud. Time the actual performance, including breaths and purposeful pauses, before allocating shot durations. Do not assign a default words-per-minute value to every narrator.
3. Maintain a continuity bible: stable character silhouettes, clothing and landmarks; location maps; prop state; lighting and time changes; palette; and prohibited image/text artifacts. Plan establishing, action, reaction, insert, and consequence views around story needs. Avoid repetitive full-frame zooms.
4. Create the manifest described below. Run its dry-run validation before any paid generation. A package with missing rights, unapproved spend, unknown model IDs, invalid frame ranges, or incomplete audio coverage is blocked.
5. Keep a provenance ledger for every input, generated asset, voice, music stem, sound effect, font, and reference. Record source, license/permission, model or tool identifier, job ID, cost, hash or path, reviewer, and status. Do not store secrets in the ledger.

Manifest contract

Use UTF-8 JSON. The project manifest must contain one schema_version, project_id, fps, width, height, duration_frames, duration_seconds, audience_promise, approval_cap, approval, originality_review, delivery_spec, narration_intervals, shots, and audio_cues collection. duration_frames is authoritative; duration_seconds must equal duration_frames / fps within the chosen rounding tolerance. approval_cap is a non-negative monetary object { "amount": number, "currency": string }, where currency is an uppercase ISO-4217 code; every committed or projected cost uses the same currency.

Each shot must contain:

• shot_id: unique stable string.
• beat_id: an existing beat identifier.
• start_frame, end_frame: non-negative integers using the half-open interval [start_frame, end_frame).
• fps: equal to the project FPS.
• narration_cue: passage identifier plus optional cue range; it does not replace the audio timeline.
• visual_intent: what the viewer should understand or feel.
• characters, location, state_before, state_after: continuity references.
• prompt, negative_constraints: original generation instructions; never include source-frame paths or credentials.
• model_id: the verified executable identifier, or null while planned; never use a marketing label as an ID.
• asset_path, generation_job_id, cost: nullable until generation; cost is either null or a non-negative { "amount": number, "currency": string } in the approval-cap currency; unknown cost blocks paid work.
• license_status: unknown, pending, cleared, or blocked.
• review_status: planned, generated, reviewed, approved, or rejected.
• layers, motion, sfx_cue: compositor and sound instructions, with layer provenance where applicable.

audio_cues use half-open time intervals [start_seconds, end_seconds). Narration, music, and effects may overlap. A required narration track must have continuous coverage for every interval in narration_intervals; music may intentionally start later, stop early, or duck under narration. Store passage IDs, asset paths, gain or ducking intent, license status, and review status separately for each stem.

narration_intervals is an explicit collection of required spoken ranges. Each item contains a unique interval_id, passage_id, start_seconds, and end_seconds, with finite non-negative values and end_seconds > start_seconds. approval contains status (pending, approved, or blocked), operation_scope, approved_cap, approved_by, approved_at, and expires_at; paid generation, upload, publication, or external sharing requires status == approved, an exact scope entry for that operation, an unexpired approval, and approved_cap equal to or below approval_cap. Allowed scope entries are generate_images, generate_voice, generate_music, upload, publish, and external_share; no wildcard scope is valid. approved_by and approved_at are required when approved, and expires_at is either null or an ISO-8601 UTC timestamp after approved_at. originality_review contains status (pending, cleared, or blocked), reviewer, basis, and timestamp; generation and final render require status == cleared. Its basis must record a human comparison of premise, dialogue, characters, locations, props, visual grammar, voice, music, branding, and recognizable combinations, with unresolved resemblance blocking clearance. These records contain no credentials or payment secrets.

The primary visual shot ranges must tile [0, duration_frames) exactly: the first shot starts at zero, each next start_frame equals the previous end_frame, and the final end_frame equals duration_frames. Do not represent a crossfade by overlapping primary shot ranges; represent it as an explicit transition referencing adjacent shots. This convention prevents off-by-one gaps and makes frame ownership deterministic.

Dry-run validation contract

Implement or run a local validator before generation. It must be deterministic, side-effect-free, and capable of running with synthetic placeholder assets. It must return machine-readable errors and a non-zero result when any blocking condition occurs. At minimum, check:

• required fields, types, unique IDs, valid enums, positive dimensions and FPS;
• duration_frames, duration_seconds, and FPS consistency;
• contiguous, non-overlapping visual ranges covering the complete timeline;
• existing beat and narration references;
• narration coverage for each narration_intervals item, with no gap or invalid audio interval;
• asset existence and hashes for render-ready shots, while allowing explicitly marked placeholders only in dry-run mode;
• verified model IDs and recorded capability evidence before generation;
• license_status == cleared and review_status == approved before final render;
• approval.status == approved with an operation scope and cap covering the requested paid/external operation; originality_review.status == cleared before generation or final render;
• total committed and projected cost within the approved cap, with unknown cost treated as blocked; projected cost includes all planned retries and revisions, and each retry is a separate provenance/cost ledger entry;
• approval is unexpired and its exact scope covers the requested operation; malformed, missing, expired, or ambiguous approval is blocked;
• absence of credentials, source-frame paths, or prohibited source-specific assets;
• a declared delivery specification and a separate loudness measurement record.

The written skill is a contract, not an executable validator. Until a validator produces the result shape below against the actual package, the package remains dry-run-only and must not be treated as authorized to render, spend, upload, publish, or share.

Return exactly one machine-readable result object shaped as { "ok": boolean, "errors": [{ "code": string, "path": string, "message": string }] }. Sort errors deterministically by code, then path, then message; ok is false and the process exits non-zero when any blocking error exists.

Use stable error categories such as E_SCHEMA, E_FRAME_GAP, E_FRAME_OVERLAP, E_AUDIO_GAP, E_MISSING_ASSET, E_UNKNOWN_MODEL, E_RIGHTS_BLOCKED, E_SPEND_BLOCKED, and E_SECRET_FOUND. A dry run may validate structure with placeholders, but it must never silently turn placeholders into paid jobs or a renderable deliverable.

Source measurements versus delivery targets

Never copy a source video's measured audio or edit values into a new project's targets. Store source observations as evidence with their method and sample; store new delivery choices under delivery_spec; store final render measurements under qa_measurements. For example, a source may measure approximately -20.8 LUFS integrated, but that is not a universal target. The new project must choose a distribution-appropriate loudness and true-peak specification, then verify integrated loudness, loudness range, true peak, speech intelligibility, and music-to-voice balance against that specification. Report unmeasured music provenance, voice identity, ducking, mastering, camera motion, or cut details as unknown.

Produce in testable stages

1. Make an original 60–90-second pilot: final script, a few diverse shot scales, a stable continuity bible, temp or properly licensed audio, a valid manifest, and a local render. Do not assume Flow provides video generation; still images can be layered and animated in the compositor.
2. Generate approved original stills shot-by-shot through the verified Flow connector. Store job metadata, prompt, model identifier, costs, and provenance. Retry transient transport failures idempotently; require human review for faces, hands, continuity, lettering, likeness, composition, and story clarity. Never automate purchasing past the approved cap.
3. Render narration in reviewable passages with pronunciation notes and timestamps. If licensed music generation is available and approved, score by narrative function rather than constant intensity; retain stems and licensing records. Align actual audio to frames, then revise shot boundaries and rerun validation.
4. Composite in Remotion or another verified frame-driven editor. For movement, separate clean plates and foreground, subject, and background layers; animate depth and occlusion deliberately; inspect exposed backgrounds and masks. Use FFmpeg for measured technical checks and final transcodes. An image pan alone is not parallax.
5. Watch and listen to the entire local export. Verify story comprehension, timing, cut continuity, captions and safe areas, speech intelligibility, peak and loudness against the chosen delivery spec, rights, resemblance, and exact render settings. Report which checks were measured, which were subjective, and what remains unverified.

Cadence and pacing guidance

Use change density as a review signal, not a quota. A source may contain frequent image changes without accelerating at its climax; escalation can instead come from changing information, decisions, consequences, and withheld answers. For an original pilot, begin with a small set of purposeful visual changes and revise from the performed narration. Reuse a plate through a new crop only when the crop adds meaning; generate a new plate when the audience needs a new location, action, subject knowledge, or consequence. Do not reproduce a studied video's shot count, hold length, image palette, or character staging as a formula.

Delivery and estimates

Deliver the original brief, timed script, beat sheet, manifest, continuity bible, provenance ledger, capability evidence, approved-generation spend record, reproducible render config, local pilot, validator output, and QA results. Estimate separately: (a) human writing, art direction, and review; (b) integration and rendering engineering; and (c) model spend and revision budget. For a supervised pilot, a typical planning estimate is 3–6 engineer-days plus 1–3 creator days. A repeatable runner with job tracking, retries, validation, rendering, and QA commonly adds 8–15 engineer-days. A polished longer film may require 4–9 creator days or more depending on continuity and revision volume. State assumptions and dependencies; a single example video does not establish a universal edit formula or the creator's original tools.