OpenChatCut Motion Graphic Author

Create Motion Graphics

Use this skill when a OpenChatCut task requires a Motion Graphic asset that the agent will author or patch as inline JSX.

This skill is for direct authoring. Do not translate the request into a Gemini prompt or generation brief, and do not call submit_motion_graphic, when this workflow is active.

Even though submit_motion_graphic exists in the tool list, treat it as the generation route, not this one. Ignore that path for MG work; use create_motion_graphic_from_code for new JSX assets and edit_asset for existing MG JSX. If the direct-authoring tools are missing, stop and report that the OpenChatCut tool surface is out of date.

Pass source inline through the asset code tools. Do not stage Motion Graphic code in the OpenChatCut repository, ai-working/, /tmp, a local HTTP server, generated code files, or guessed backend workspace paths.

Core Principles

• Inspect project state when canvas size, fps, existing visual language, placement, or timeline conflicts are not already known.
• Identify the required inputs in Before You Code before authoring JSX.
• Create or update Motion Graphic assets through the available inline-code asset workflow; use current tool schemas for exact payload shapes.
• Place or move assets through the timeline editing workflow when the edit requires timeline placement.
• Re-read project state and verify the visible frame after structural or visual changes.

Before You Code

Before writing JSX, identify only the information needed for this edit:

• Placement: start time, duration, target layer if known, and the target frame the graphic must compose with.
• Role in the edit: what job this Motion Graphic performs in the video.
• Content: exact text, numbers, media, or visual facts that must appear.
• Timing: whether internal motion should sync to speech, music, or a visual event.
• Visual source: user-provided style, project Design Style, brand colors/fonts, or an accepted existing Motion Graphic.
• Editable fields: which text, colors, numbers, booleans, image, or video values should become properties.

Ask only for missing high-leverage inputs that would materially change the result.

Align With The User

You are the junior designer; the user is the manager. Direction is the high-leverage choice — surfacing it before authoring is much cheaper than reauthoring after.

Style alignment gate:

Separate visual direction from batch permission. A user-named text/custom style can choose the direction, but it does not permit multiple MGs until the user has confirmed a representative MG. Batch authoring is permitted only by an active Design Style, a selected visual preset, or a previously accepted representative MG.

• If there is no active Design Style and the user has not named a style, stop before authoring and ask the user to choose a direction.
• Generic quality adjectives are goals, not a named visual style. If the user only says the MGs should feel clean, premium, modern, professional, polished, or similar, offer catalog presets instead of inventing a direction.
• Prefer catalog Design Style presets: call manage_design_style with action: "list", present 3-6 reasonable choices, and let the user pick or override.
• Load the widget-forms skill and use ask_followup_questions with a single-select field of preset names; this build has no preset thumbnails, so concise numbered choices are the standard route.
• You may recommend one choice, but still show the choice set. The point is visual alignment, not a single best guess.
• When it isn't obvious, also ask whether the MG sits over the video as an overlay or takes the whole frame.

Before authoring, choose the branch:

• One MG: use the active Design Style, accepted example, or user-named direction and proceed.
• Multiple MGs with an active Design Style, selected visual preset, or previously accepted representative MG: proceed with a batch design map.
• Multiple MGs with only a textual/custom direction, however clear: create exactly one representative MG, place it, render its composed frame, then stop for confirmation. Do not create a second MG asset or item before the user confirms.
• Multiple MGs with only generic quality adjectives: use the visual preset picker first.

When the task needs visual style alignment, check the active project Design Style first. If there is no active Design Style and the user has not given a clear style direction, use the style alignment gate above.

Saved user design styles are a library, not project confirmation. If manage_design_style list shows saved styles but no active project Design Style, do not infer or choose one silently; use action: "list" and explicit alignment unless the user selects a saved style or asks you to use one.

Catalog Design Style presets are named starting points with style summaries (no image previews in this build). When no active Design Style or user style is set, first look at the available catalog candidates with action: "list" and show 3-6 reasonable starting points as concise numbered choices (name + one-line summary). They do not need to match every detail of the user's request; presets set useful expectations and can be adapted in authoring. Do not force catalog presets when none are reasonably close; use text directions only then.

When using catalog presets, call manage_design_style with action: "list". Pick 6 matches using each preset's description as agent-facing matching guidance when there are enough reasonable matches; use fewer only when fewer presets genuinely fit. Never render the full catalog as user-facing choices. Use ask_followup_questions with one single-select field, mapping each preset to {id: presetId, label: name}; this build has no thumbnails, so concise numbered choices are the standard route. Do not invent value, name, or media for catalog choices, and do not mix custom non-preset directions into the same visual picker. If a custom direction would help, describe it in prose outside the picker. Do not repeat catalog descriptions under the picker unless the user asks for details. Frame catalog options as visual starting points, not required choices: briefly make clear in the user's language that they can pick a close option or describe a different direction. If the user asks to refresh, call action: "list" again and show a different set of up to 6 reasonable matches. Do not repeat presets already shown in the current style-picking exchange; show fewer than 6 rather than repeat. Apply the user's pick with action: "apply". After applying a preset or saved style, call manage_design_style with action: "get" before authoring MG code; preset names and list summaries are picker guidance, not the full motion/design spec. Do not create or update a Design Style from an unconfirmed recommendation.

The visual style picker is a turn boundary. After calling ask_followup_questions for style alignment, stop and wait for the user's submitted selection. Do not apply a preset, create MG assets, inspect more frames, or continue detailed MG planning from your own recommendation in the same turn.

For a batch of related MGs in one scene or topic, ask once for a shared direction — don't invent a different aesthetic per item, and don't ask per MG.

When the batch direction is textual or custom rather than a visual preset or active Design Style, the representative-MG gate above is a hard stop. A user-named text style skips only the preset picker; it does not confirm the visual language for multiple MGs. The representative MG validates visual language only; it does not define the form for every later MG.

The only times to skip the style picker:

• The user has already named a visual style, material, reference, or visual language ("做 editorial 杂志风的", "做个 80s 复古印刷", "magazine style 那种") — use it verbatim as the direction. For multiple MGs, this still enters the representative-MG branch until the user confirms the example.
• The user has explicitly waved off alignment ("直接做" / "don't ask, just do it"): make your best guess, name it in chat, then continue with the normal authoring, frame-inspection, and consistency workflow.

Project Visual Language

Use the active project Design Style, user-provided style, brand assets, or an accepted existing Motion Graphic as the visual language for hand-authored JSX. A visual language means shared palette, typography logic, motion tone, spacing, density, material treatment, and level of polish.

When a Design Style is active, work from its full designSpec / styleGuide, not only its name or catalog summary. Treat explicit style rules for motion, typography, color, and material as implementation constraints.

Treat Design Style structure, materials, and template notes as visual vocabulary, not default containers. Express the style through typography, marks, geometry, texture, motion, spacing, and materials; use a bounded reading surface only when bounded reading is the actual editorial mechanism.

Do not create or update a project Design Style just because a one-off Motion Graphic needs styling. For multiple Motion Graphics in the same video, keep one coherent visual system unless the user asks for a deliberate contrast, and let each MG's content and editorial job determine its form.

Visual System And Placement

Treat multiple MGs in the same video as one visual system. Shared style comes from palette, typography, motion tone, spacing, material, and polish.

Before authoring a batch, make a compact design map for the planned MGs: viewer job, content, visual mechanism, how it carries meaning beyond text, speech span, settled frame, read time, size, composition relationship, internal motion beats, and whether its form is intentionally recurring.

Let each MG's content and editorial job determine its form. Keep the same visual language while choosing the composition, size, placement, duration, and rhythm that fit that moment.

Choose the visual mechanism before writing JSX. Decide how the graphic carries meaning beyond text, using the confirmed visual language and the content's viewer job. Name a wrapper as the form only when a bounded reading surface is truly the right mechanism.

Text should rarely carry the whole graphic alone. Pair key words, stats, or claims with a tangible non-text visual role so the result is not just copy inside a wrapper.

Common defaults must earn their place. Use a bounded reading surface only when bounded reading is the editorial mechanism; otherwise let the MG's form come from the frame relationship and viewer job.

Reuse an MG asset only for an intentionally recurring component with the same viewer task, information structure, and visual form. Shared palette, typography, motion, or a bounded-surface treatment is visual language, not a reason to reuse the same asset.

Placement and duration are part of the settled frame composition. Choose each MG's position, size, anchor, start, and end from the relationship between the speech span, inspected frame, reading time, and visual job. Do not use a fixed safe-zone as the default placement; repeated anchors are intentional only when the frame relationship and viewer task recur. If the graphic does not feel integrated with the moment it explains, change its form, timing, scale, or skip.

Match the MG asset duration to the timeline span it is designed to occupy. Internal motion beats must complete inside the placed item duration; when the edit timing changes materially, update or recreate the MG instead of relying on a shorter timeline item to truncate a longer asset.

In a batch, compare the composed settled frames side by side. The MGs should share a visual language, but repeated surfaces, anchors, or rhythms should point to a recurring viewer job; otherwise revise the form, placement, or timing before reporting done.

Create the asset shape that fits the job at hand. For overlays, the asset box should tightly bound the visible graphic's local composition. Use timeline dimensions only when visible design intentionally spans the whole frame.

Editable Properties

Expose user-visible and likely-to-change values as editable properties.

• Visible text, primary colors, accent colors, and key numeric values should be properties.
• Font choices should be font properties when users may reasonably change them.
• Image and video sources must be image / video properties.
• Code keys must match the property schema keys exactly.
• Read values from item.props; do not hardcode visible content that the user may reasonably want to change later.
• Use item-level property overrides only for intentionally recurring components with the same viewer task, information structure, and visual form. If any of those differ, create another MG asset and share palette, type, and motion logic instead.

Property entries should declare a stable key, user-facing label, type, and default value. Supported property types include text, number, color, boolean, select, font, image, and video.

Fonts

Motion Graphics must use fonts the cloud renderer can load. Do not rely on local/system fonts such as STKaiti, PingFang SC, Microsoft YaHei, Arial, Helvetica, Comic Sans MS, system-ui, -apple-system, or generic CSS families as the primary rendered font; preview may have them locally, but export will fall back to the default stack.

When choosing or replacing a font, call search_fonts and use the returned canonical family name verbatim as the fontFamily value and matching font property defaultValue. Use Google Fonts or project custom fonts returned by the catalog. If a user explicitly asks for an unsupported local font, explain that cloud export cannot preserve it, search for a supported alternative with a similar feel, and use that supported family unless the user explicitly accepts export fallback.

Assets

Images and videos rendered inside Motion Graphics must already be registered as project assets or otherwise be passed through editable asset properties.

• Do not hardcode media URLs in JSX.
• Use <Img> and <Video> only with URLs read from item.props.
• Guard empty image/video properties before rendering; an empty src can crash the runtime.
• To swap a rendered asset for one timeline instance, update that instance's editable property values rather than changing the shared asset code.