Hyperframes Production Director

HyperFrames Production Director

Give every substantial HyperFrames project a repeatable production layer before composition authoring. This skill directs the project; it does not replace the official HyperFrames skills or technical contract.

Authority order

Resolve conflicts in this order:

1. The user's explicit instructions for the active project.
2. Supplied source material, brand files, approved copy, and destination rules.
3. Approved project files such as BRIEF.md, frame.md, and MOTION_BOARD.md.
4. This skill's production standards.
5. General creative defaults from the installed HyperFrames skills.

Custom animation, layout, palette, pacing, or source-preservation instructions always override this skill's defaults when technically valid. Record those instructions in the project files so they persist.

Required context

Read the official hyperframes skill before acting. Load its routed workflow and domain skills as required. For design-led work, load hyperframes-creative; for composition authoring, load hyperframes-core; load animation, keyframe, media, audio, registry, or CLI skills only when the active project needs them.

Read these packaged references:

• references/production-standards.md before planning any fresh or structural project.
• references/frame-spec.md before creating or replacing frame.md.
• references/verification.md before approving construction or final output.

Determine project state

Use the first matching state:

Do not re-interview the user on every revision. Project files are the durable memory for that video.

Workflow

1. Inspect before asking

Inventory the current project and inspect what exists:

• Source footage, images, audio, transcript, script, URL, or written brief.
• Existing BRIEF.md, frame.md, design.md, DESIGN.md, MOTION_BOARD.md, STORYBOARD.md, hyperframes.json, composition HTML, and approved assets.
• Source dimensions, duration, frame rate, audio, and intended destination.
• Brand tokens, fonts, logos, approved names, product identity, and claims.

Infer safe facts from the files. Ask only questions whose answers materially change the result and cannot be discovered. Never ask the user to manually fill a template.

2. Lock intent and permissions

Establish and record:

• Audience, outcome, message, duration, aspect ratio, destination, and CTA.
• What may change: picture edit, timing, crop, narration, captions, music, sound, color treatment, and source identity.
• Required custom animation, transitions, layout states, media, or stylistic exclusions supplied by the user.
• Approved and unapproved names, products, logos, assets, statistics, and claims.

Anything not explicitly authorized remains unchanged. Write or update BRIEF.md using the official HyperFrames brief contract when available.

3. Map the usable frame

Inspect representative frames across every source beat. Map:

• Destination safety or supplied platform overlays.
• Caption lane.
• Face, hair, chest, hands, and important body movement.
• Source UI, baked text, logos, products, and important background action.
• The complete paths and overshoot regions of planned animation.

For 1080x1920 portrait work with no authoritative overlay, start from the essential rectangle x 90–990, y 240–1520, then refine it from the footage.

For 16:9 work with no destination-specific rule, a 5% edge margin is a design heuristic, not a platform guarantee. Talking-head layouts may use only the states actually needed from full screen, half screen, and bottom corner / PiP. Define exact geometry before animation.

4. Create the project-specific frame spec

Resolve existing design specifications in this order:

frame.md -> design.md -> DESIGN.md

If an approved frame.md exists, preserve it and amend only decisions affected by the new brief. Otherwise generate frame.md from the inspected project and references/frame-spec.md.

The agent fills the complete spec. The user does not replace placeholders.

The spec must contain exact normative values for palette, typography, canvas, safety, source preservation, components, presenter geometry when relevant, motion character, approved entities, and explicit exclusions. Prose must define the concept, hierarchy, aspect-ratio behavior, captions, transitions, and review criteria.

Do not invent a brand system when approved brand material exists. When no brand or visual direction exists, derive a brand-neutral proposal from the content and offer at most two meaningfully different directions if the choice is material.

5. Create a transcript-backed motion board

Create or update MOTION_BOARD.md before detailed composition authoring.

Use word-level transcript timing when narration exists. Otherwise use the approved script, soundtrack beats, storyboard, or source edit as the timing authority.

For every beat, record:

Every animation must be able to finish and settle inside its beat. Simplify choreography that cannot resolve in time. Design one clear idea per beat.

6. Approval gate

Present a concise summary of BRIEF.md, frame.md, and MOTION_BOARD.md, plus the highest-risk proof frames. Stop before detailed composition authoring until the user approves or explicitly requests autonomous continuation.

If the user changes animation or design direction, update the project files first. Do not leave important decisions only in chat history.

7. Direct construction

After approval:

1. Route through the official HyperFrames workflow.
2. Build the static hero frames for the highest-risk beats first.
3. Inspect hierarchy, scale, safety, presenter/source treatment, and design adherence.
4. Add deterministic, seekable motion only after the layouts work.
5. Keep critical state on registered composition timelines; avoid wall-clock behavior, uncontrolled live embeds, and unseeded randomness.
6. Keep motion hierarchy clear: hero move, support move, restrained background.
7. Preserve user-requested custom animations and document material deviations.

8. Verify proportionally

Use references/verification.md and the installed HyperFrames CLI workflow.

At minimum:

1. Run the relevant lint and project checks.
2. Smoke render a representative section.
3. Capture hook, complex beat, presenter transition, payoff, and final-hold frames, plus any risky entrance or exit.
4. Inspect the actual images at destination size.
5. Fix every structural or design-spec failure.
6. Render the full output only after the frame review passes.
7. Watch the encoded result with and without audio before calling it complete.

Reset early when the layout model fights the source, scale is wrong across multiple beats, or patch-on-patch fixes are accumulating.

Outputs

For a fresh project, the production handoff is:

• BRIEF.md
• frame.md
• MOTION_BOARD.md
• Local approved assets and transcript references
• Proof-frame timestamps
• A verified HyperFrames composition after approval

Keep paths project-relative and portable. Do not write private machine paths, credentials, or unrelated workspace identity into shareable project files.

Boundaries

• Do not replace the official HyperFrames technical contract.
• Do not impose one house style, palette, font family, or animation vocabulary across projects.
• Do not add claims, brands, scenes, narration, music, captions, or identity the user did not provide or approve.
• Do not rerun the full workflow for render-only tasks or small approved edits.
• Do not treat lint or a successful render command as visual approval.