HyperFrames Motion Director

Use this skill to turn a vague video request into a reviewable HyperFrames production. First produce a concise brief/design proposal. Continue to assets, composition, snapshots, render, and review only after the user confirms the direction.

HyperFrames handles rendering. This skill handles direction, assets, layout, motion planning, and delivery checks.

When the film promotes a concrete product, tool, skill, CLI, app, API, workflow, template library, or creative system, treat the work as a premium product promo, not only a cinematic metaphor short. The video must show product proof: commands, cards, screenshots, output previews, modules, numbers, chips, icons, marks, or workflow states that make the claim visible.

Core Principle

Work from the final viewing experience backward:

1. What should the viewer remember?
2. What metaphor carries the point?
3. Which image stage gives the frame depth, context, or tension?
4. Which frame proves the visual direction is strong?
5. Which movement makes the viewer keep watching?
6. Which beat carries the hook, reveal, proof, and CTA?
7. Which motion choices guide attention through those beats?
8. Which visual objects compress meaning better than more words?
9. Which validation proves the video will render deterministically?

Start with legible still frames and timing. Write animation code only after the frame plan works.

A strong still frame is a gate. The finished video should lose meaning when reduced to screenshots; otherwise the motion is only presentation polish.

House Style

Default to one strict style unless the user explicitly overrides it:

• Deep black background #050505.
• Minimal cinematic lighting, high contrast, large negative space, low brightness.
• White, gray, and warm gold only. Keep warm gold as a restrained accent.
• Magazine-cover composition: one dominant symbol or phrase, no explanatory clusters.
• Subtle paper grain, shallow depth of field, volume haze, thin rim light, local metallic highlights.
• Text, image, composition, and color must express one point together.
• Default to a generated or supplied background image stage for new videos. It must create depth, metaphor, or product context.

Forbidden by default:

• Ordinary illustration, ecommerce banner composition, icon piles, generic tech dashboards, neon cyberpunk, multicolor palettes, gradient clutter, decorative particles, explain-the-concept diagrams, and busy collage.
• Literal article-surface drawings when a metaphor would be clearer.
• PPT-like sequencing: static title cards, repeated fade-up scenes, identical centered layouts, empty black fades, or text pasted over wallpaper.

Premium Product Promo Rule

For product, tool, CLI, SaaS, API, skill, template, workflow, or system promos, black cinematic style is only the base layer. It is not enough.

Visual components are mandatory for premium product promos. Do not proceed to implementation with only a background image, big titles, scan lines, and one symbol. That produces a single-note film. A premium promo needs a reusable component library that makes the product feel real.

A product promo with no visual components is blocked. A "visual component" is a visible, reusable product-specific surface with content slots, style rules, state, motion interaction, and a snapshot proof. Generic text boxes, isolated labels, decorative borders, floating lines, background gradients, and unanchored icons do not count.

The film must build a product proof ecosystem:

• Product proof artifacts: commands, UI surfaces, output cards, screenshots, generated examples, module labels, theme stacks, provider chips, numbers, validations, reports, or before/after states.
• Component library: command card, output/draft card, stat block, module chip group, provider chip group, proof card, product frame, anchored route/signal, theme/output stack, CTA badge, or equivalent product-specific surfaces.
• Icon and decorative system: marks, chips, rails, brackets, glows, fragments, panels, shadows, and texture must be named, reusable, and tied to meaning.
• Motion interactions: each major component must reveal a product state change, not only enter the scene.
• Copy ladder: pain -> mechanism -> proof -> confidence -> CTA. If a line could fit any product, rewrite it.

Content-derived product visual component coverage:

• Derive the component count from source phrases, product mechanisms, proof claims, and actions. Do not target a fixed number such as 4, 6, or 12.
• Include a concrete product surface when the claim depends on a real or faithful product state.
• Include taxonomy components only when the source contains modules, providers, features, themes, modes, or statuses.
• Include a final action component when the film has a CTA.
• Show the important mechanism or proof components early enough that the first half is not only titles and atmosphere.
• Every product component defines role, source, content slots, visual state, motion interaction, snapshot timestamp, and deletion test.
• Every visible product component must perform an action: type, route, fan, assemble, reveal, scan, validate, transform, count, lock, export, publish, save, collapse, or hand off. Static placement alone does not count.
• For premium vertical generated-image work, generate at least one source-driven visual component sheet. Its inventory size comes from the content, not a preset quota. Every sheet must contain product-specific components with clean isolation boundaries, consistent style, named roles, target scenes, crop boxes, motion purpose, and deletion tests. Crop every accepted component into an independent transparent local asset before implementation.
• Generate a hero object separately when a crowded sheet would not provide enough usable resolution or isolation space, but treat separate hero generation as a supplement rather than a replacement for the component sheet.
• Keep text-rich commands, screenshots, UI, and proof states faithful by using official assets or code-native reconstruction. That fidelity requirement does not waive the source-driven component sheet; use it for the bitmap objects, material pieces, proof-safe shells, symbols, stamps, transition objects, and product-specific foreground elements that benefit from Image Gen.

Block product promo delivery when the component library is only prose, when components are not visible in snapshots, when all components are generic cards with different labels, when components merely sit on screen without action, or when motion does not show product state change.

Use references/premium-product-promo.md before proposing, storyboarding, implementing, or reviewing a product promo, especially when the user provides a premium reference or complains about missing icon libraries, decorative elements, image resources, animation interaction, or top-tier design quality.

The brief must derive its asset inventory from the product. Include the product/brand lockup, concrete surfaces, proof artifacts, taxonomy, and recurring motion objects only when the source and story require them. If the visual inventory cannot prove the product mechanism, inspect the project, use existing assets, generate product-safe mockups, capture screenshots, or state that the result will be a concept film rather than a premium product promo.

Source-Driven Visual System Rule

Visual richness is not the same as visual quality. More assets, icons, cards, or generated props still fail when they are generic, mismatched to the copy, or interchangeable with another project.

Before proposing visual components, extract a source-driven visual system from the user's text, project, article, README, product surface, or confirmed copy:

• Source phrases: the exact lines, claims, nouns, verbs, numbers, and emotional tensions that deserve visual form.
• Concrete nouns/entities: product surfaces, files, folders, commands, screenshots, documents, people, modules, metrics, platforms, or states.
• Process verbs: write, route, collect, check, publish, save, export, compare, collapse, recover, grow, hand off, or equivalent action language.
• Visual motif: one core metaphor and three to five component families that can repeat across scenes.
• Text-to-component map: every major visual component names the source phrase it translates.
• Big-text-box replacement plan: long text blocks become objects, chips, diagrams, proof surfaces, kinetic words, or short captions.
• Generic rejection list: props and icons that could fit any unrelated product are forbidden unless the text makes them literal.

Do not count a big text box, paragraph card, or generic office prop as a premium visual component. A title can be the hero, but it cannot be the whole visual system unless the user explicitly asked for a typography-only film.

For article-to-video and knowledge/workflow promos, the source text is the asset brief. If a visual element cannot point back to a source phrase, claim, noun, verb, or number, remove it or redesign it. If still frames cannot reveal what the source material was about without reading a paragraph, the visual system is too generic.

Generated component sheets must be source-driven. Each accepted item needs a source phrase, component family, crop/isolation plan, target scene, motion action, and deletion test. Reject sheets that are only attractive icon sets, generic stationery, random UI cards, or mixed-style decorations.

Block delivery when:

• Most hero frames are dominated by large text boxes with weak product or source-specific visual translation.
• Visual assets are ordinary office, desk, paper, dashboard, AI, or productivity imagery that could serve a different video.
• The component library is rich in quantity but lacks one coherent motif, style lock, and source phrase mapping.
• Components repeat as same-shaped cards with different labels instead of distinct roles and actions.
• The review report passes "asset floor" while failing source-text recognition, motif cohesion, or big-text replacement.

Reference Fidelity And Narrative Boundary Rule

When the user supplies a style prompt, image, repository, local path, or named reference, inspect that exact source before describing or generating the visual system. A style label such as Riso, editorial collage, or premium tech is not evidence that the source was understood.

Record in ASSET_MANIFEST.json:

• Exact source: the attachment, text prompt, repository, path, screenshot, or house-style section actually inspected.
• Observed visual grammar: at least three concrete properties visible in that source, such as palette, material, edge treatment, composition, typography relationship, depth, or transition behavior.
• Narrative boundary: what the reference controls and what it must not replace.
• Forbidden drift: generic substitutions, adjacent styles, or attractive mechanisms that would erase the product story.

Style is a rendering language. Product actions, source claims, characters, objects, and proof states remain the story. Do not turn a product promo into a demonstration of printing, collage, scanning, machinery, or another style mechanism unless that mechanism is itself the product claim.

If the user corrects the reference source or says the style has overtaken the story, return to the brief and asset manifest before generating more assets. Do not patch the mistake only in animation.

Background And Motion Rule

For new video work, plan background imagery by default. Phase 1 defines what is needed; Phase 2 generates or sources the assets after confirmation. Use Codex Image Gen for project-bound bitmap assets unless the user supplied strong assets or the confirmed direction is pure kinetic typography.

Treat each frame as four coordinated layers:

1. Background image as stage: atmosphere, depth, light, metaphor, or product context.
2. Typography as message: readable hierarchy, fixed safe zones, controlled line counts, no accidental overlap with busy image regions.
3. Visual objects as meaning compression: restrained symbols, functional icons, props, frames, marks, or texture pieces that replace explanation, guide attention, or prove the process.
4. Motion as attention direction: one primary motion idea per scene, one optional support motion, and stillness after each important reveal.

Use references/motion-background-system.md for image counts, text-over-image layout, motion grammar, and review gates.

Content-Derived Image Asset Architecture Rule

Do not choose background or component counts from duration alone. Derive the asset architecture from the confirmed source, storyboard, and motion jobs:

• Visual worlds: group adjacent beats that can truthfully share one spatial stage. Generate one independent vertical background for each genuinely different world. Premium multi-scene work normally needs multiple backgrounds, but the approved analysis decides the count.
• Movable foreground inventory: list every source-specific object that must move independently, prove a claim, or carry a transition. That list decides the transparent component count.
• Sheet strategy: premium vertical generated-image work uses at least one component sheet. Use one when the complete inventory fits with generous isolation space and usable resolution. Split it across multiple sheets, or add separately generated hero objects, when one sheet would crowd or shrink the assets.
• Cutout contract: preserve each source sheet, crop every accepted item into a named transparent PNG, keep fully transparent outer edges, remove matte spill, and review the cutouts on both dark and light contact sheets.
• Manifest: write ASSET_MANIFEST.json after the Phase 1 asset decision and update it with accepted local paths in Phase 2. It is the source of truth for visual worlds, background ownership, component inventory, sheet cells, cutouts, target scenes, motion actions, and proof sheets.

Phase 1 must state why the chosen counts are necessary. A fixed target such as "4 backgrounds and 12 components" without source-driven analysis is a template failure. Phase 2 must not silently rewrite the approved counts; record a revision and reason when the asset analysis changes.

Use references/imagegen-asset-pipeline.md before planning, generating, cutting, validating, or reviewing bitmap assets for premium vertical work.

Motion-Role Asset Coverage Rule

Do not judge a visual asset library by count alone. A large sheet of same-shaped cards is still one visual idea.

For premium multi-scene work, the accepted component inventory must cover three different jobs:

• Narrative anchor: preserves the same subject, article, person, product surface, or hero object across beats.
• Product proof: makes a claim visible as a real state, result, command, screenshot, number, choice, or validation.
• Transition carrier: tears, folds, routes, wipes, stamps, fans, assembles, scans, or otherwise moves story material between scenes.

One component may cover more than one job when the mapping is explicit, but premium multi-scene work needs at least three independent movable components. This is not an inventory target; it is the smallest library that can prove two distinct two-object combinations.

Before implementation, record at least two distinct combination tests for premium multi-scene work. Each test names the component set, scene, choreography, snapshot timestamp, and deletion test. Reusing the same component set with a different label is not a second combination.

Block animation when the library has many files but only one motion job, when all proof surfaces share one silhouette, or when components can only enter independently and cannot hand off, assemble, replace, reveal, or transform together.

Use references/asset-choreography-and-render-qa.md before approving an asset inventory or component sheet.

Pure-Code Exception Rule

Pure-code black stages are an exception, not the default production shortcut. Do not mark a video premium or ready when it is only dark gradients, big text, translucent cards, and thin lines unless the user explicitly requested a typography-only motion study.

For article-to-video, content-system, workflow, product, tutorial, personal knowledge-base, local-folder, or tool-comparison promos, Phase 1 and Phase 2 must include a content-derived visual asset floor:

• Enough independent background stages, product screenshots, workspace/file-tree captures, generated metaphor plates, or supplied images to cover the declared visual worlds.
• Enough scene-specific proof visuals beyond text boxes to cover the declared source phrases, mechanisms, and proof claims.
• A local asset path for every bitmap or screenshot, or an explicit user-approved reason why a custom SVG/3D/vector system is stronger than bitmap assets.
• A screenshot review that proves frames do not reduce to "black background + title + cards".

Block final delivery when:

• assets/images contains only placeholders and the report claims a rich background or visual asset system.
• The same dark background stage carries every beat without a changing subject, scene depth, or concrete proof surface.
• A pure-code exception is justified only by convenience, missing dependencies, or "code-generated" labels.
• Motion is mostly text/card translate and opacity while the subject needs a visual environment, generated image, product screenshot, or artifact library.

Image Gen Asset Discipline

Codex Image Gen is used to create source material for compositing, not finished posters. HyperFrames owns final typography, timing, masks, crops, parallax, focus pulls, and text contrast.

Before generating, write an asset brief for each image:

• Role: stage, symbol, texture, anchor, or transition plate.
• Use in scene: which beat uses it and what it must communicate.
• Aspect ratio and target size: usually vertical 9:16 for new vertical work; use standard ratios for cutaways or panels.
• Layout contract: textRect, subjectRect, quiet text zone, safe bottom boundary, and motion bounds.
• Focal subject: side, center, top, lower field, or background-only.
• Empty space: where text can sit without a card.
• Lighting and palette: dark base, controlled contrast, restrained warm gold only when needed.
• Forbidden content: baked-in text, fake UI, fake logos, labels, explanatory icons, watermarks, decorative clutter, random symbols, and high-frequency detail in text zones.

After generation, inspect the actual image before implementation:

• Keep only assets with a clear role.
• Regenerate or crop when text would fight detail, faces, product edges, bright seams, or platform overlays.
• Move final assets into the project asset folder before referencing them.
• Document the local path and the accepted crop in DESIGN.md or STORYBOARD.md.
• Replace extra images that repeat the same role with one stronger image.

Visual Object Discipline

A strong motion video usually needs more than background plus text. Add objects only when they reduce explanation, direct attention, prove a claim, or create a memory hook.

Before implementation, define a small visual object system:

• Primary object: the one prop, symbol, product surface, frame, or material that the viewer should remember.
• Functional marks: 1-3 small icons, stamps, brackets, ticks, rails, labels, or guide marks that replace explanation, direct attention, or show proof.
• Texture pieces: sparse fragments, dust, paper, grain, light, or depth cues that create atmosphere without becoming confetti.
• Object motion: how the object enters, transforms, hands off, or proves the beat.
• Removal test: what meaning is lost if the object is deleted.

Hard rules:

• Avoid icon piles. One visual language per video is enough.
• Avoid small icons beside every line of text.
• Avoid generic symbols such as rockets, lightning, sparkles, AI chips, and random checkmarks unless the brief makes them literal and necessary.
• Avoid icons as labels for an unclear metaphor. If the object needs a label to make sense, redesign the metaphor.
• Prefer project-specific objects: source paper, film frame, scan rail, confirmation stamp, inspection bracket, product surface, timeline, lens, cursor, map route, seal, or artifact.
• Add at most one primary object system and three functional mark types in a 20s vertical promo.
• The review report must state whether added visual objects are necessary, restrained, and removable without harming the story.

Anchored Connector Rule

Lines, route paths, rails, scan lines, arcs, underlines, brackets, and connector glows are not automatically premium. They are support objects. Use them only when they are anchored to a concrete object, word, component edge, node, cursor, status mark, or CTA.

Before keeping any connector, name:

• Start anchor: the exact object or word it leaves.
• End anchor: the exact object, word, node, or component it reaches.
• Job: reveal, route, compare, focus, validate, hand off, or close.
• Motion: how it changes state rather than floats as decoration.
• Safe zone: where it cannot cross text, CTA, product surfaces, or platform overlays.
• Deletion test: what meaning, proof, or attention direction is lost if it is removed.

Reject or replace connectors when:

• The line floats in empty space without a visible start and end.
• The line is only an elegant divider, flourish, or curve.
• The line competes with the title or product proof.
• The same connection is clearer as a card edge, status dot, node sequence, chip state, frame corner, progress strip, cursor, highlight, or CTA border.
• The viewer would understand the scene equally well without it.

Prefer component-attached signals for premium product promos: card top/bottom highlights, node sequences, status dots, short progress strips, inspection corners, screenshot check marks, and CTA edge lighting. These usually feel more built and less decorative than free-floating arcs.

Support Asset Decision Rule

Do not require decorative assets. Require a support-asset decision. A strong motion video often needs more than a single background, but every extra bitmap, SVG, mark, texture, or shape must have a semantic role, a visual-system relationship, and a motion purpose.

For every new video brief, decide whether the direction needs support assets beyond the background stage:

• Symbol: the central metaphor, product silhouette, number object, or visual anchor.
• Texture: grain, haze, material surface, shadow plate, dust, or light falloff that makes the frame tactile.
• Light / mask / transition plate: sweep, aperture, wipe source, matte, focus layer, or morph source used to reveal or bridge beats.
• Semantic glyph: a minimal meaning-bearing mark that compresses an idea; not an icon set.
• Product / UI fragment: a faithful product, interface, chart, or proof crop used only when the story needs evidence.
• Motion accent: line, glint, trace, path, bracket, rail, or particle-like detail with a defined attention or transition job.

Use Codex Image Gen after confirmation for support bitmap assets when they cannot be made more cleanly in HyperFrames/CSS/SVG. Prefer code-generated lines, masks, simple glyphs, vector marks, and typography whenever they will be sharper, more controllable, or easier to animate than a generated image.

Each support asset must declare: role, source, local path if bitmap-based, visual relationship to the background, safe zones, motion purpose, entrance/exit timing, and deletion trigger. Delete or omit any support asset that does not strengthen meaning, depth, transition continuity, product proof, or readability.

Content-derived support-asset guidance: