Product video production

Product Video Production

Run an evidence-led product-video workflow with explicit approval gates. Preserve product truth, keep UI understandable, and validate the exported file rather than relying on an editor preview.

Classify the request

Choose the smallest mode that satisfies the request:

• Plan: Produce a brief, claim ledger, script proposal, storyboard, or production plan. Do not generate media unless asked.
• Review: Inspect existing scripts, frames, audio, drafts, or final exports. Report evidence-backed findings. Do not modify unless asked.
• Produce: Build requested artifacts with ElevenLabs, HyperFrames, and FFmpeg/ffprobe; advance only through approved gates.
• Adapt: Recompose an approved HyperFrames master for another aspect ratio, language, or channel. Do not stretch or mechanically crop the master.

If the request mixes modes, complete the non-mutating work first and state which approval unlocks production.

Enforce the dependency contract

• Allow Plan and non-implementation Review to run without ElevenLabs or HyperFrames.
• Require ElevenLabs for formal narration, voice approval, pronunciation control, and narration timing metadata.
• Require the installed HyperFrames skill and framework for formal composition, animation, preview, rendering, and production-level adaptation.
• Require FFmpeg and ffprobe for final audio processing, media probing, frame extraction, and delivery validation.
• Check required dependencies before entering their stage. If one is missing or inaccessible, stop at the current gate, report the exact dependency, and preserve approved work.
• Do not silently replace ElevenLabs, HyperFrames, FFmpeg, or ffprobe. A provider or framework change alters this workflow and requires explicit user approval plus an updated production plan.

Establish inputs

Discover what is available before asking questions. Resolve or explicitly mark:

• product source: app, website, build, screenshots, recordings, or documentation;
• audience, channel, language, duration, dimensions, and frame rate;
• one-sentence value proposition and desired CTA;
• product version and publication constraints;
• claims that must appear and claims that must not appear;
• available visual proof and capture environment;
• brand assets, captions, narration, music, and SFX requirements;
• output directory and required deliverables.

Ask only for decisions that materially change the result and cannot be discovered. Never invent product behavior to fill missing inputs.

Create the project contract

For a new production, create or update these artifacts from assets/templates/:

• BRIEF.md
• CLAIMS.md
• SCRIPT.md or a clearly marked script proposal
• STORYBOARD.md
• DESIGN.md
• audio_meta.json when audio begins

Keep one source of truth for each decision. Do not duplicate conflicting versions across documents.

Read references/workflow.md when planning or producing more than one stage.

Enforce the gates

Treat these gates as state transitions, not suggestions:

1. Brief gate: Confirm audience, purpose, format, value proposition, truth constraints, and CTA.
2. Script gate: Present narration, translation when useful, narrative role, timing, screen text, shot intent, and claim evidence. Require explicit approval before generating narration, capturing formal media, building formal compositions, or rendering.
3. Evidence gate: Present a contact sheet or equivalent asset inventory. Verify authenticity, language, privacy, completeness, and claim coverage.
4. Visual gate: Present static keyframes and design direction before full animation.
5. Voice gate: Present ElevenLabs voice auditions before generating final line takes.
6. Draft gate: Present the complete timed video with formal narration, music, and SFX.
7. Delivery gate: Export high quality only after timeline approval, then validate the exported file.

When a gate fails, return to the earliest decision that caused the issue. Do not patch downstream symptoms.

Read references/review-and-recovery.md for review passes and rollback rules.

Build the story from evidence

Choose scenes by their ability to prove the product's value, not by feature count or release novelty.

Use this default narrative arc when appropriate:

1. Expose a recognizable problem.
2. Deepen the question or tension.
3. Introduce the product as the answer.
4. Demonstrate the primary value with real UI.
5. Show one or two deeper proofs.
6. Establish trust.
7. End with a truthful CTA.

Give each shot one primary narrative job. Remove claims without reliable visual proof. If a system surface or device state cannot be captured cleanly, revise the script or storyboard and resubmit any semantic change.

Make product UI legible

• Show a complete app screen inside a device frame when establishing context.
• Move from overview to detail before allowing a crop to fill the canvas.
• Keep enough neighboring content for the detail to remain identifiable.
• Use motion, scale, timing, and hierarchy to direct attention; avoid tutorial-style red outlines unless instruction is the goal.
• Ensure narration and visuals advance together. Split long static holds into meaningful overview and detail shots.
• Write value-led titles that interpret the screen; do not label it with generic text such as “Month View,” “Details,” or “Look Closer.”
• Vary composition, information density, entry direction, and rhythm while preserving one design system.

Route specialized work

• Use the hyperframes skill for all formal HyperFrames architecture and implementation. Keep this skill responsible for story, gates, truth, and review.
• Use available media skills for capture, conversion, audio processing, and inspection.
• Use relevant platform design skills when the displayed product requires platform-specific review.
• Use ElevenLabs for formal narration. Read references/elevenlabs-audio.md before voice selection or generation.
• Use FFmpeg/ffprobe for formal media processing and exported-file validation.
• If a production dependency is unavailable, stop that stage and report it. Do not continue with a substitute or a partially validated deliverable.

Review in passes

Review a draft in this order:

1. Truth: Every claim and interface state is supported.
2. Comprehension: The story remains understandable when muted.
3. Rhythm: Visual information changes as narration advances.
4. Design: Hierarchy, safe areas, device frames, crops, and shot variety hold together.
5. Audio: Voice, music, and SFX support rather than compete.
6. Technical delivery: The actual export satisfies its specification.

Do not approve a draft from still frames alone. Watch it continuously.

Validate delivery

Before declaring completion:

• run framework checks in their strictest relevant mode;
• inspect scene midpoints and transition boundaries;
• verify narration-to-action synchronization;
• extract representative frames from the final MP4 and compare them with the approved design;
• verify dimensions, frame rate, duration, codecs, sample rate, and audio streams with a media probe;
• check captions, safe areas, device frames, aspect ratios, blank strips, stretching, and clipped text;
• keep the final CTA readable long enough to understand;
• render to a temporary path and replace the official deliverable only after validation;
• disclose skipped or unavailable checks.

For alternate dimensions, recompose spacing, scale, typography, and safe areas independently.

Required handoff

Report:

• what was produced or reviewed;
• which gate is currently approved;
• which claims or assets were removed and why;
• paths to the source documents, draft, final export, and validation evidence;
• exact checks performed and any remaining uncertainty;
• the next approval or action, if work remains.

Never say “complete” when a gate, required media stage, or validation check was skipped.