Motion Graphics

For authorized motion sound, ask Earshot through FrameCore Works Toolbox (toolbox:toolbox, in Codex toolbox) when it is in the skill list and follow sound through Toolbox: it is the preferred SFX/kit engine, with measured onset/peak/end anchors aligned to the existing motion-score; without it use Studio's sound.py, named by the engine that ran. Listed but its engine not installed (Toolbox's status unavailable): one question with both routes, install Earshot through Toolbox, full (about 2.6 GB, chooses sounds by listening) or light (about 470 MB, makes and measures sounds but does not choose them by listening), or make the sound now with Studio's own sound.py; run neither before the answer (owner decision 2026-10-23). Ask Earshot for takes chosen by listening for each cue's character (from the picture and the request), with their readings; never accept a preset's take unchecked. Code around Earshot (cue mapping, placement, mix scripts): when Superpowers is available, load the matching skill before acting, superpowers:test-driven-development with a failing onset check per cue, superpowers:systematic-debugging when its install, runtime or a cue fails, superpowers:verification-before-completion on the encoded MP4. Keep Studio mixing, direction and bounded QA. Local only: no audio upload to Gemini or any model service. For a real recorded sound or ambience the user has not supplied, use the Open Assets reference base, then let Earshot, through Toolbox, import and assess its verified local audio with provenance.

Use native Superpowers support for build planning, coded choreography/layout implementation, technical diagnosis and completion verification. Studio owns the creative direction and motion craft. Preserve approved boards and exact timing/copy; inspect actual motion and sound as well as code checks.

Before final delivery of a substantive authored, revised or generated creative artifact, automatically apply output review. Reuse domain QA in one bounded loop; inspect actual media, preserve accepted locks and stop unchanged on a pass. This does not run for greetings, menus or onboarding questions. When Superpowers is in the skill list, load superpowers:systematic-debugging before diagnosing a reproducible technical defect and superpowers:verification-before-completion before calling a deliverable ready; Studio keeps ownership.

Read Studio integration authority before this method. It defines the active owner map, host capability rules and exceptions to the repository’s installation conventions. For substantive creative work, apply the conditional Research gate and search only when one of its triggers applies; purely mechanical state or packet maintenance uses its documented exemptions. Scale the artifact to the requested stage. Quick pitches remain short; known intent and valid scoped authorization do not need repeated confirmation.

The technical ID hyperframes-workflow is kept for compatibility. It does not select the HyperFrames engine: present this area as motion graphics from code and choose the runtime from requirements. Use the user's working language; keep exact copy and requested prompt language separate.

Method

Start at the requested stage and reuse supplied decisions, approvals and the existing project. The full method is the code-based motion workflow; this entry summarizes its order.

1. Stage and inputs. Identify whether the request is a concept, storyboard, build, repair or review. Confirm it is time-based motion, not a static raster graphic. Collect what exists: brief, exact copy, assets, brand tokens, runtime and delivery needs. Ask only the next consequential missing question.
2. Concept and storyboard. When the user asks for examples, templates or inspiration, or has no idea yet, first show up to three matching entries from Studio's own library: the brief index type, the gallery shortlist (mechanism, creator, film link) and the reel starters; search the web only for what they lack; a Studio original or starter can become a direction as it is, a gallery film is linked and adapted (ready templates). For an open brief, find the idea before the look (ideation method): tell the user in one line which obvious motif, palette and move you set aside, and propose transformations invented for this brief (what becomes what), at most one using the category's defaults as the labelled classic. For an advert or promo, first decide the argument in commercial motion: audience, action, verified offer, benefit, friction and evidence, a few different concepts weighed internally, a hook with a payoff and a CTA that closes the shown action, recorded in the contract's strategy. Then test stopping power: what fills the screen in the first second, the biggest change in the film and where it lands; a clever idea that stays small on screen loses to one that strikes, and an ad must also give a reason to choose this business (a result, a proof, a person), not only list services. A reel for a local service, product or before-and-after needs pictures: the client's photos or footage, or generated assets planned from the boards; without them, say before building that a type-only reel is a weaker fallback and ask where the pictures come from. Define one communicative mechanism, the scenes on one master frame timeline with readable holds, and exact copy and asset locks in one motion contract JSON file, using the storyboard contract as the field checklist. When several aspect ratios are needed, declare them as formats of the same contract instead of separate projects. Before presenting it, even for a storyboard-only request, open the gallery shortlist (one small file, never the full gallery shard), take its section for the brief type and name in one line the mechanism you take and its creator with the film link; it is a read, not a build, and is not postponed to the build. Present it to the user as a storyboard table, not raw JSON; where the host composes native elements it may be a scene timeline of the same revision (presentation and interaction), a planning view that never exports or replaces the render. Keep Confirmed, Proposed and Unknown explicit. Present the identified revision for approval before the first build; existing approval of the same revision is enough.
3. Motion design. Before expanding a substantial film, judge the opening, the densest and the ending frames with exact copy and real assets at full size and phone scale. Apply motion craft for easing, durations, staggers, holds, rhythm and transitions, and motion quality direction for references, style frames and a focused motion proof. Record the chosen values in the contract's motion system. Before building, run the scene logic check on every board: each object does its real job on its material, seen from the side that shows the result, and the next board grows out of that result; colours, type and objects come from the brand, never from a reference. A dense brand showreel (chat hook, a carrier from the logo, kinetic offer boards, logo assembly) follows dense kinetic reels; a teaser, trailer or launch film in huge type on the beat follows kinetic launch films (beat sheet, energy targets, 4K master). When the brief leaves the look open, derive it from the chosen idea and execute it with a motion style or values of its own instead of asking brand questions; the user's brand values always win. For a product photo, a trend or a word-by-word hook, use photo-hero, line-chart and word entries, and keep a logo or offer tag on screen with persistent elements (scene kinds). For a vertical ad, the ad templates (offer, product, testimonial) render a chosen idea whose structure they fit, and variants.py makes brand, language and format versions; an idea that needs another structure gets scenes of its own. For a film of a product's interface, follow product films and the device scene kind with the user's screenshots. With music or voice-over, use the sync tool for the beat grid and captions, and for a song's words lyric timing. The motion compendium maps all motion knowledge, ad creative, tools and licences. When the film needs realistic objects, products, hands, close-ups or photographic light and the user supplied none, plan generated cut-out assets from the storyboard, one object per image with its transparency route for the named generator, and offer ready prompts or, with an approved connected generator, make them; never draw realistic objects or hands in code, and ask for light effects on black with no backing plate. When the user points to a motion effect on a website as the reference, measure it with the web motion probe where a shell and a browser exist (libraries, each tween or CSS animation with its duration, delay, ease and properties, frames over time) and take values, not code: rebuild the technique in Studio's runtime and never copy the site's code, assets or text. A technique the brief names ("morph match cut") is looked up in the technique atlas after the HyperFrames registry and then written from the brief, never copied from its card. Once the idea is chosen, the library's brief index and at most three records from the motion prompt library, including the 703-film Opus 5.5 gallery, can supply technique for it; they are not a source of directions: name the mechanism taken, credit the creator's post, never paste a source prompt. For a prompt to paste into another coding agent, first open assets/motion-prompt-library/README.md with the file tool and follow its section writing a prompt for a coded film, then the gallery shortlist for technique; never grep the full gallery shard.
4. Runtime. With neither a shell nor code execution (only reading and search tools), this is the no-code route: in the first answer name the motion player (Open contract) beside the storyboard as the way to watch and export the video, and after approval write the .motion.json contract with the exact copy in the reply; switching on a shell may be offered as an extra option, never as the only way forward. Otherwise probe before you choose or promise a runtime: node -v, ffmpeg -version, a Chrome or Chromium path and whether the npm registry answers (npm view hyperframes version); then tell the user in one line which route you chose and why. In Claude Code or another shell host with Node.js, FFmpeg and Chrome or Chromium, client reels and ads are HyperFrames compositions by default: follow client reels in Claude Code and plan them with the reel board system (owner decision 2026-10-12). In ChatGPT Work the sandbox can run HyperFrames too: when the check finds Node.js, FFmpeg, Chromium and the npm registry, offer to install the pinned CLI for this session and make it the route for client reels (owner test 2026-10-14; the runtime map gives the steps); never say the sandbox cannot install it before the check. Otherwise start from the host with the runtime map: it says which tools run with no code execution, with code execution or with a shell. Preserve an explicit user choice or a working project; otherwise recommend the simplest suitable available stack using the runtime selection and the toolkit routing table. React/TypeScript compositions go to Remotion Video. When the npm registry is unreachable but Node.js, FFmpeg and a browser are there, write the composition as one HTML page and render it with `capture-html.mjs`; do not promise npx hyperframes.
5. Build. Only when authorized and capable: implement the approved contract with every visual state derived from the requested frame, shared preview and export state, loaded fonts and assets, and no wall-clock or unseeded randomness. Declare scenes with the scene kinds where they fit, so the contract alone drives the preview and the Remotion render; write custom scene code only for the rest. Start from a starter when no project exists: for a client reel in HyperFrames, a reel starter whose job matches the brief; the GSAP motion starter for HTML, the Remotion kinetic type starter for React/TypeScript, or the dependency-free frame starter. Both runtime starters read the same motion-score.json contract.
6. Review and deliver. Where Node and a local Chrome or Chromium exist, run the automated frame review first and repair its errors; for a composition outside the contract (HyperFrames, GSAP, hand-written HTML) run the visible-text audit. Check generated assets with the asset check before compositing, and their edges in the rendered film at peak zoom. Run motion activity on every rendered MP4 and rework a REVISE (undeclared stills); plan change inside each board too, not only between boards. Before delivery compare the reel with the user's reference reels or the board system measurements (full-frame changes, scale changes, the largest moment); a reel that passes every check can still be too quiet for a client, so say so instead of calling it finished; judge whether the idea develops with the development review (idea, composition, rhythm, cause, signature, physical logic, ending; restraint is not a defect). Check the plan and the frames for page chrome, the strongest tell of a template film: a small label parked in a corner or along an edge, a chapter counter ("02 / 04"), a timecode or progress bar, a kicker line above a headline, the same left headline block beside a card or device in scene after scene, a headline typed letter by letter. Remove each one the idea does not need; what the ad must carry (a persistent logo, the offer, phone, address) stays, placed as part of the composition (adapted from motionmaxxing, Apache-2.0). Accept in four separate verdicts (technical, fidelity, composition, temporal) with acceptance.py and deliver via --pack (for a HyperFrames or hand-written composition, --copy with the locked copy and --motion-activity with the measurement): a valid export or a contract-only score never passes the picture or the viewing. Inspect actual output at frame 0, N-1, readable holds and both sides of each boundary, watch the full sequence when possible, and inspect the encoded file. Use the QA record within the shared review budget, then deliver the editable project, exports actually produced and remaining limits.

Technical explainers and interactive figures

For report/chart animation, real-product walkthroughs, format changes or timestamped corrections, use data-led motion and revision-bound feedback. Bind displayed quantities to checked sources and scenes, distinguish reconstructed UI from captured interaction, inspect format-specific layouts and retain revision-bound feedback. Reuse existing contracts and working notes; do not invent runtime fields, live data refresh or a Claude Motion API.

For a requested coded explanation of a mechanism, process or system, use the bundled Anatomy toolkit and method within the selected runtime. An interactive HTML/SVG deliverable stays interactive; it does not require an unsolicited MP4. Static technical graphics stay with Graphic Design. This profile does not select an engine, require isometric styling or authorize installation.

• Map the explanation before the parts. Identify the real inputs, outputs, units, thresholds and relationships, separating verified facts from assumptions. When a physical analogy helps, state which part/action represents each relationship and where the analogy stops. Use the detail needed for the audience; do not force a machine, a minimum part count or ornamental density onto a simple explanation. Retain useful labels and the user's visual direction.
• Use one model. Geometry state, moving parts, numerical readouts and captions must describe the same state at the same instant. Derive them from one small testable model; check boundary values, reset and input changes. Do not animate a plausible-looking counter independently of the mechanism or present a teaching simplification as an engineering simulation.
• Respect both runtimes. In interactive work, support the relevant pointer/touch and keyboard actions, clear focus, reduced motion and a meaningful still state; pause idle work offscreen. For video, replay recorded inputs or a prescribed sequence deterministically from frame/time and reset model state before seeking. Do not copy a wall-clock animation loop into the export path or claim a working interactive page proves video export.
• Keep the parts connected. Build static geometry once, use consistent camera/coordinates, and update only changing parts. Check attachment points, clearances, clipping and front/back order in resting, extreme and intermediate states. A quick or sampled geometry audit covers only its recorded shapes and states; inspect actual pixels as well. Never replace true geometry with a stand-in merely to silence a checker.
• Use effects where they explain. A shader must add information that simpler geometry cannot convey. Keep it in the same camera and masks as the illustration, with continuous transitions and a readable non-WebGL fallback. Inspect phone-size output, relevant controls, transitions and fallback within the existing review budget; do not impose a card frame, corner labels or a universal light/dark style on other motion work.

The complete SVG/WebGL/3D kit, React adapters, geometry audits, browser review tools and source examples are bundled in the Anatomy engine. Copy it into a new project with studio.mjs init, probe the selected runtime with its executable fixtures, then author from the brief. Its frame bridge feeds Studio's existing HTML video capture; it needs no separate Anatomy install. 3D remains upstream beta and requires project-specific render evidence. Offer the original anatomy plugin from FrameCore Works Toolbox only for a separately requested original workflow. Gallery publication, session-log collection and host-security changes are outside the graphics integration.

Deliver the video

• With code execution but no shell, render the MP4 from the contract with the bundled Python renderer, copied byte for byte as <id>.render.py (exact size, FPS and frame count, H.264, no audio unless requested). An SVG logo needs cairosvg; ask for a PNG of the mark up front.
• Improve before delivery. Run the craft critique (assets/motion-review/critique.py) and make at least one improvement round when it finds an error or warning (fix, re-render, critique again; report the score before and after), within the shared budget of at most two repair rounds. Check the frames at every scene boundary, hold start and transition for overlapping, clipped or off-frame text.
• Deliver the MP4 download link and the actual editable project that rendered it: the <id>.motion.json and <id>.render.py for the Python route, or the source composition and build instructions for HyperFrames, Remotion or another engine (delivery steps). Every scene declares a scene kind. An optional HTML preview is for watching only: no Export video button and no MediaRecorder. A complete copy of the player template is delivered only byte for byte with its contract replaced. Wherever a .motion.json exists (ChatGPT, Work, Codex, Claude Code), also give the motion player in the reply: the one-click link from the render summary's player (link, or url with Open contract when link is null; player-link.mjs builds it with Node), so the user can watch, scrub and export the video in the browser after the sandbox is gone.
• With a shell, Node.js 22, FFmpeg and Chrome (Codex or a local project), HyperFrames is the default for client reels and ads as in step 4 and also serves website-to-launch films, longer narrated videos, word-level captions or music-driven edits; Studio keeps intake, approvals and review, and the HeyGen catalog is used only on request (HyperFrames engine).
• Choosing among the look routes below: when several fit, choose by the deliverable and say why in one line: a real mechanism with true geometry goes to the Anatomy method above; isometric line art driven by sound to Iso Glow; a calm isometric object whose one bright stroke follows the story (no glow) to Hairline; a painter's look or an explainer channel's grammar to art-style direction (with the Animate engine as its renderer when a shell exists); a whole hand-made film with its own check-ins to the Animate engine. When the user does not know what is possible, apply FrameCut's strongest-result check: recommend one route in their terms and offer a missing add-on from the recommended extensions or Toolbox catalog once, never the simplest look by default.
• Illustrated or hand-made looks (cut paper, crosshatch ink, riso, sketchbook, manim-style math, pixel art, isometric, or a look matched from references) for explainers, histories and little stories: with a shell, Node.js and FFmpeg (Codex or Claude Code), offer the Animate engine; its story, look and storyboard check-ins are the approval, and its review numbers feed the four verdicts.
• Isometric line art that lights up (a device, building or small city drawn in hairlines where only what is live glows, for example a loudspeaker pumping with the bass): with a browser runtime, use the Iso Glow kit and drive it from the track with `audio_envelope.py`. Offer the original iso-glow app note from FrameCore Works Toolbox only for interactive pages.
• Quiet isometric line figures without glow (a shelf, rack, stack, device or empty state built from rounded solids, where one brighter stroke marks what the story points at and parts lift or open in turn): before answering, open assets/hairline/README.md and assets/hairline/examples/spice-rack/index.html with the file tool (the kit's rules and its time functions are only there, not in this file), then adapt the example and answer in the user's language. Use the Hairline kit: find the object and its giveaway features first, compose the rest pose, plan a tour of three to six stops, and move everything as functions of time. Offer the original hairline plugin from FrameCore Works Toolbox only for pointer figures on a website.
• Interface and type craft: a UI mock, landing or dashboard inside a film, a title card or an HTML composition follows the type, colour and interface sections of the shared craft rules (caps tracking, accent discipline, no default indigo or trust gradients); timing and easing come from motion craft. Run `craft_lint.py` on the composition HTML; a brand colour the lint flags is allowed with --allow and noted in the review.
• Art-style animation and explainer grammars (a painter's or tradition's look that must stay alive, Vox, Kurzgesagt, 3Blue1Brown, whiteboard, keynote or finance-chart explainers, or recreating a reference animation): apply art-style and explainer motion direction for camera, look and shot-list rules, and measure a reference with reference breakdown before rebuilding it. The original skill is the huashu-art-motion plugin in FrameCore Works Toolbox, offered only on request.
• Without code execution, give the .motion.json file and the motion player https://framecoreworks.github.io/framecore-works-creative-studio/, which opens it (Open contract) and exports it (browser video export). Check which tools the host actually exposes before promising an MP4: with no code execution, say so in the first answer and name this route beside the storyboard, instead of promising a render or only asking for other tools. After approval, give the contract in the reply (as a file too when the host can write one) with the player link; never replace them with a hand-written render script.
• Sound is designed here. Never deliver toy tones; the MP4 stays silent unless the user asks for sound, supplies audio or authorizes a provider that is actually connected. Ask once whether sound is wanted and offer the routes in motion audio: Studio asks Toolbox's Earshot (toolbox:toolbox) for procedural SFX/kits when Toolbox is installed (engine missing: the choice above), and otherwise designs effects and composes a music bed at studio standard from the contract's timing with motion-sound/sound.py (motion sound design), mixes them into the MP4 and reports the timing status. After mixing, listen with numbers: run `listen.py critique` and `sync` on the delivered MP4, fix the cause of each timed finding, and report what was measured and what only a listener can judge (craft and targets).
• Report and revise honestly. Mark preview and export NOT VERIFIED until someone has actually watched the file. A change to a delivered video starts from its contract and render script, changes only what was asked and re-renders with the same script (contract revisions). The optional stage prompts are instruction packets, not a mandatory sequence.

Owners around this skill

Guardrails

• A work-area choice or this skill's name never selects a runtime, installs tools or authorizes rendering, uploads or publishing.
• HyperFrames is a coded-video path, not a paid media-provider integration.
• Do not use coded overlays to bypass the one-pass policy for raster graphics with visible text.
• Do not invent runtime APIs, package versions, platform safe zones or render results; check installed versions and current documentation when a named tool's behavior matters.
• Do not claim a render, playback or audio review that did not actually happen.
• Every visible word is complete in readable holds; audit flags such as data-layout-ignore never exempt visible text, and a deliberate exception needs data-text-clip-ok with a reason and a pixel review.
• Keep private paths, unapproved assets and hidden metadata out of deliverables.

Handoff

Review gate: structure_fit. The workflow role hyperframes-producer maps to this skill and execution-manifest to the existing manifest owners. Keep the internal HyperFrames Production Brief handoff type for compatibility; it is not an engine selection. Hand off with:

• scene_list and timing on the master frame timeline
• copy_locks and asset_needs
• motion_system with the chosen easing, durations, staggers, holds and transitions
• runtime stated as selected, proposed or unknown
• implementation_prompt or component brief
• render_constraints and render_qa_checklist

QA checklist

• The plan is time-based motion, not static raster generation.
• Every scene has a frame interval, focal point, readable hold and transition.
• Motion values come from the recorded motion system and serve the message.
• Text is readable at the intended viewing size for the full hold.
• No page chrome (corner labels, counters, timecodes, progress bars, kickers, repeated slide layouts) unless the idea needs it.
• Assets, fonts and exclusions are explicit; locks are preserved.
• Preview, temporal review, audio and encoded export are reported separately, with NOT VERIFIED where evidence is missing.

FrameCut handoff

FrameCut can execute simple keyed transforms, per-format framing, freeze frames, variable speed and bounded effects itself. Reuse those native capabilities when sufficient; take ownership of the requested designed motion rather than rebuilding its global edit. Native composition stills and authored specialist stills feed the same complete board. A FrameCut speed change does not authorize stretching a previously bound motion return.

Honor FrameCut's stage: before storyboard acceptance, return the requested designed still states and motion/sound plan for its full-sequence contact sheets. Execute a video sample only when the user requested it or accepted the offer. Final composition rendering follows acceptance of the current complete FrameCut board; a broad build request or local sample acceptance does not replace that evidence. Keep still rendering separate from a mandatory video preview. Return a proposed creative change to FrameCut's board revision loop; technical implementation repairs that preserve the accepted design keep its acceptance.

For a FrameCut handoff, reuse its working agreement and request; author only the requested local composition at origin 0 with exact frame count/FPS, dimensions and alpha convention. Return rendered media, the hashed authoring contract, original request and actual review/limitations. FrameCut binds them with attach-motion --request, checks stale context and owns global placement, audio/caption mapping and final composition. A changed request requires reconciliation, not silent stretching. Do not restart intake or create a second global timeline.