Media in HyperFrames

Media Use resolves and prepares media for HyperFrames projects. It finds or creates an asset, places a local file in the project's assets directory, and records it in a ledger so rendering does not fetch media remotely. The workflow covers music, sound effects, images, icons, logos, voiceovers, presenter video, transcripts, cutouts, grades, and looks.

Start by listing reusable candidates and judging whether they fit the intended scene. Reuse, ingestion from an existing source, and adoption are supported paths alongside generation. The resolution command accepts the desired type, intent, and project:

npx hyperframes media-use resolve --type <type> --intent "<what you need>" --project <dir>

The result identifies the resolved asset, local path, type, and metadata. The Apache-2.0 skill also includes procedural CC0 offline sound cues rather than redistributing upstream Pixabay recordings. Openverse sounds that require attribution must receive it.

Use the skill when a HyperFrames piece needs licensed media or audio preparation with clear provider choices. Inside a host application with its own media tools, use those tools first. For footage that is dark, flat, dull, retro, printed, obscured, or revealed, inspect the actual image or video, choose one treatment intent, and persist the result with the media-treatment workflow rather than substituting CSS, SVG, or a cube-file stand-in.

Review a piece once for concrete gaps such as text without voiceover, placeholder images, silent cuts, a color cast, or a long passage without music. Offer specific fixes together when such signals exist. Do not add them silently, repeat suggestions without a signal, or override a request to leave the piece unchanged.

Inputs include the project, intended media role, existing candidate assets, provider access, rights, and an authorized budget. Outputs are locally available media and its ledger record, with prepared audio, transcripts, cutouts, or treatments where requested. Verify actual visible output and accessibility before delivery; a recipe does not prove every environment works.

Provider selection affects both availability and payment. Signed-in HeyGen access supplies a music catalog, asset search, and Voice Turbo. Credits cover generated music and images, other voices, cloning, avatar video, and certain operations. Local options include MusicGen, installed FLUX through mflux, Kokoro text-to-speech, installed LTX for generic clips, transcription with Parakeet or whisper, and local background removal. Use local tools or the user's own key when asked, rather than automatically substituting them after a sign-in gap. Logos come from sources such as theSVG, GitHub avatars, or favicons rather than redrawing.

Check HyperFrames authentication before a request needing a HeyGen model or catalog. Missing sign-in requires the person to complete login and confirm it. When the host supplies the HeyGen API base, use its payment context without requesting another sign-in; relay a refused call and stop. Direct HeyGen CLI recipes use that CLI's separate login and payer, so they require that payer to be selected.

Use only authorized paid actions and the approved payer. Review known costs and uncertainty, pass the remaining credit limit, subtract completed charges, and stop at the limit. A refusal cannot authorize a subscription, top-up, different payer, policy bypass, or uncertain duplicate charge. Obtain rights and consent for footage, likeness, and cloned voices.

Use the installed or explicitly chosen CLI version and review dependency downloads. Default invocations disable telemetry, skill updates, and update checks. Feedback needs a user request. Keep secrets in existing storage or ignored files, preserve unrelated work, and follow plugin installation rules when applicable.