---
name: app-ugc-ad-editing
description: Edit mobile-app UGC ads in HyperFrames using existing creator footage, authentic app recordings/mockups, brand assets, captions, audio, CTA, dual-format exports, and QA. Use for editable first cuts or revisions; don't generate new footage unless asked.
---

# App UGC Ad Editing in HyperFrames

## Purpose

Create an **editable, review-ready first cut** of a short-form app ad. The user will refine the edit afterwards, so deliver a clean, well-structured composition rather than pretending the first pass is final. The creator footage establishes the relatable problem and human trust; genuine app assets prove the product solves it.

This is an app-ad editing workflow, not a brand redesign, app UI-generation task, or a generic motion-graphics reel.

## 0. Use the official HyperFrames workflow

1. Start with the current official `/hyperframes` entry-point skill. Follow its routing and project-state rules before editing.
2. For a multi-shot ad, use `/general-video` plus `/hyperframes-core`. Load only the extra domains the edit actually needs:
   - `/hyperframes-creative` for the concept, design spec, visual hierarchy and typography.
   - `/media-use` to adopt/reuse logos, images, audio, captions, treatments, and existing media correctly.
   - `/hyperframes-audio` when placing or mixing dialogue, music, sound effects, fades, ducking or other audio processing.
   - `/hyperframes-keyframes` for punch-ins, crops, pans, zooms and other animated visual properties.
   - `/hyperframes-cli` for validation, preview, snapshots and rendering.
   - `/embedded-captions` for a standalone caption pass on unmodified single-subject footage, or `/talking-head-recut` when the talking-head footage should remain untouched and only timed graphic cards are added.
3. Follow the current official skill's install/update, usage, authentication, composition and rendering instructions. Do not rely on remembered CLI flags or invent HyperFrames attributes. Check the installed version and project state first.
4. Resume an existing project if one exists. Inspect its `BRIEF.md`, `hyperframes.json`, `STORYBOARD.md`, composition and timeline before changing anything. Preserve accepted decisions and avoid rebuilding a working project from scratch.

## 1. Gather inputs without creating unnecessary friction

Use information already supplied in the conversation or project. Determine:

- App/product name and campaign objective.
- Source creator/UGC footage and intended spoken script, if supplied.
- Target platform and aspect ratio. For this studio, generate source footage at 9:16 / 480p, then use HyperFrames to produce **both** 9:16 / 1080×1920 and 4:5 / 1080×1350 exports. These are edit/export dimensions; do not send the clips back to an AI video generator just to create the second aspect ratio.
- Desired duration. If unspecified, retain the natural length of the usable footage and suggest a sensible short-form cut; do not pad to a target duration.
- Main audience, key benefit, single CTA and any claims/disclaimers.
- URL/path for the existing app asset library, if present in the brief or project config.

If one essential input is truly unavailable, ask one concise question. In particular, do not fabricate the asset-library URL. If the URL is present in project context, inspect it without asking again.

## 2. Treat the app asset library as the source of truth

Inspect the provided app-context website before designing the edit. Identify the correct app and collect only assets relevant to this specific ad. Look for:

- Official logo and app icon files.
- Brand colors, fonts, typography rules, tone and visual restrictions.
- Actual screen recordings and mobile-mockup recordings.
- Approved screenshots, feature names, product descriptions, CTA language and store links.
- Any existing end cards, badges, device frames or export variants.

Create a small asset manifest in the project (for example `ASSET_MANIFEST.md` or the established project equivalent) recording the chosen asset, its source URL/path, what it is used for, and any relevant crop/placement note. Preserve existing project conventions and do not create duplicate assets if the project already tracks them.

Rules:
- Prefer the supplied original file. Preserve official logos, proportions, colors and aspect ratios.
- Use actual screen recordings and mockup recordings rather than re-creating the interface in HTML/CSS or asking a video model to redraw it.
- Do not invent, rewrite, or hallucinate UI text, app features, prices, ratings, download counts, reviews, or performance claims.
- Do not add competitor marks or unapproved third-party/store badges.
- Never stretch a device mockup or crop away UI needed to understand the feature. If a crop is unavoidable, keep the important interaction readable.
- If the asset library has a brand rule, that rule beats any generic visual preference in this skill.
- If an expected asset appears missing, search the supplied library and project first. If it is still missing, either use an approved alternative already present or make the omission explicit; do not silently substitute an invented logo or UI.

## 3. Inspect and understand the footage before editing

1. Inventory all source videos/audio and record duration, dimensions, frame rate when available, orientation, and whether usable dialogue is present.
2. Watch/listen to the source footage. Transcribe the actual spoken words when timing matters; use the provided script as a guide, not as proof of what was finally spoken.
3. Identify the strongest opening delivery, cleanest explanation, useful gestures, natural pauses, usable reactions, and any product-demo moments.
4. Note source in/out times for intended clips. Keep a concise edit map so revisions can target a specific shot or time range.
5. Preserve natural speech cadence and believable breaths. Remove only dead air, accidental pauses, repeated starts, or awkward gaps that harm pacing. Do not over-trim until the speaker sounds artificial.
6. Keep the original source files untouched. Edit non-destructively in the HyperFrames composition.

## 4. Build a concise storyboard before composing

Write or update a small `BRIEF.md` and `STORYBOARD.md` (or the project's existing equivalents) before detailed composition work. Include the ad's single promise, audience, CTA, source assets, scene order, approximate time ranges, on-screen text, edit intention and unresolved assumptions.

A useful starting structure—not a rigid template—is:

1. **Hook:** Start with the most relatable human moment, surprising statement or visual proof. Avoid a long logo animation or generic title before the creator appears.
2. **Problem/context:** Make the audience recognize the situation. Keep the creator's words and performance central.
3. **Product proof:** Show the exact feature that solves the problem using the supplied real screen recording or mobile mockup footage.
4. **Outcome/payoff:** Return to the creator or show the real product result. Make the benefit clear without adding unsupported claims.
5. **CTA:** End with one unambiguous next step. Use approved brand assets and wording; do not manufacture a store button or URL.

Use only the beats supported by the script and footage. If the ad works better as a direct-to-camera narrative with a short UI insert, do not force five separate scenes. Do not impose fixed timestamps if the spoken delivery suggests a better rhythm.

## Required export variants: 9:16 and 4:5

Unless a campaign explicitly overrides the default, render both outputs from HyperFrames after assembling the ad:

- **9:16 vertical:** 1080×1920.
- **4:5 feed:** 1080×1350.

Use the same approved 9:16 / 480p generated creator footage and the same real app assets for both. The 4:5 output is an edit/reframe variant in HyperFrames only; do not launch a separate AI generation just to change the aspect ratio.

- Verify the currently supported HyperFrames composition/render path for dimensions and variant management. Do not invent composition fields or CLI flags.
- Maintain separate editable compositions or variants so each layout can be adjusted independently.
- Recompose, do not stretch. Reposition/crop the creator per shot and adjust product UI, phone mockups, captions, feature labels and CTA for the narrower 4:5 frame.
- Do not blindly center-crop. Inspect that faces, meaningful gestures, important interface areas, caption rails and CTA remain visible. A crop is unacceptable if it makes the app feature unclear.
- Run separate visual QA on each version. Passing the 9:16 export does not count as QA for 4:5.
- Export using the highest suitable quality/bitrate currently supported by HyperFrames, and verify actual rendered dimensions/codec. Suggested filenames: `<campaign>_<app>_9x16_1080x1920.mp4` and `<campaign>_<app>_4x5_1080x1350.mp4`.
- Remember that exporting a 480p source at 1080×1920 or 1080×1350 changes output dimensions but does not restore native detail lost at generation. Do not over-sharpen or imply otherwise.

## 5. Edit principles for realistic UGC performance ads

### Preserve the human anchor
- The creator should remain the primary emotional anchor. Keep facial expression, gestures and direct-to-camera delivery visible whenever they carry the story.
- Cut on a thought, phrase, reaction or useful gesture rather than applying a cut every few seconds by default.
- Use punch-ins only to emphasize a meaningful moment, hide a source framing problem or add visual variation. Do not add constant random zooms, shake, parallax or transitions.
- Prefer simple hard cuts and restrained transitions. Use an effect only when it improves comprehension, continuity or energy.
- Preserve the source's natural light and color unless a clear, source-grounded correction is needed. Do not automatically apply heavy LUTs, beauty filters, fake film grain or artificial sharpening.

### Show the app clearly
- Choose between a raw screen-recording insert, a supplied phone-mockup recording, or a composed phone frame based on which makes the feature clearest. Prefer the existing prepared mockup when it already looks correct.
- Show one feature/action at a time. Hold the shot long enough for a viewer to recognize the UI and understand the interaction.
- When necessary, use restrained crop/scale/pan to direct attention, but keep interface text legible. Do not animate the app UI in a way that implies behavior absent from the real recording.
- Make the product demonstration connect to the creator's spoken line. Avoid unrelated UI cutaways used only to fill time.
- Return to the creator after the demo when it helps connect product proof to the stated benefit.

### On-screen text and captions
- Captions must reflect the audio actually heard. Check names, feature labels, punctuation, language and line breaks against the source.
- Keep captions readable on a phone: strong contrast, comfortable size, short phrase-sized lines and consistent placement. Use the app's brand typography/colors where appropriate, not merely because a color exists in the brand palette.
- Emphasize only a few high-value words per line. Avoid turning every word into an animation or piling captions, feature labels, stickers and callouts over the same area.
- Keep captions and key text clear of the creator's mouth/eyes, phone UI, and common platform interface areas at the top and bottom. Respect safe zones.
- Use title cards, feature callouts and kinetic typography only when they add context or make a benefit easier to remember.
- Do not use captions as a substitute for readable product UI. Do not cover important app interactions with captions or decorative labels.

### Audio
- Dialogue is the priority. Preserve the original performance, room tone and intended vocal character.
- If adding music, choose a restrained bed that fits the ad and duck it under dialogue. If music competes with words, lower/remove the music before making the voice unnaturally loud.
- Use sound effects sparingly and only when they support an actual visual action or transition.
- Avoid abrupt starts/stops, clipping, accidental silence, duplicated source audio, phasey/overlapping dialogue, or music covering a key product claim.
- Do not synthesize replacement dialogue or alter the meaning of the spoken copy unless specifically requested.
- Use `/hyperframes-audio` for supported track placement and mixing; use `/media-use` for sourcing or generating permitted audio assets.

## 6. Compose in HyperFrames cleanly

- Use the HyperFrames composition/timeline contract rather than inventing custom playback timing behavior. Read `/hyperframes-core` and the relevant official recipes before editing source ranges, media timing, tracks or clip placement.
- Organize the composition so a human can revise it easily: sensible track separation, descriptive asset/clip names, reusable sub-compositions where appropriate, and one obvious place to change captions or brand values.
- Keep footage, phone UI, captions, callouts, music, SFX and CTA elements separately editable when practical.
- Reuse supplied font, logo and media assets. Avoid embedding large encoded assets directly into HTML when the project can reference local files normally.
- Use deterministic/seek-safe animation supported by HyperFrames. Avoid relying on wall-clock timers, nondeterministic DOM state, or effects that look correct only during one playback path.
- Search the supported HyperFrames registry for a needed component/effect before hand-building a complex effect. Favor a simple robust composition over ornamental code.
- If creating a phone frame from assets, preserve its aspect ratio and safe area. If a ready-made mobile mockup recording is supplied, prefer it over rebuilding the frame.

## 7. Review, validate and deliver the first pass

Before delivery:

1. Run the validation/checks required by the current HyperFrames workflow; do not guess command names or flags.
2. Preview the edit and inspect representative frames across the entire duration, including every cut, caption change, UI insert, CTA and final frame. Use snapshots/contact sheets if the current workflow supports them.
3. Listen to the full audio at normal speed. Check the beginning and ending, dialogue/music balance, edit clicks, gaps, and whether captions match the spoken content.
4. Confirm no black/frozen frames, accidental gaps, malformed overlays, stretched assets, clipped text, obscured faces, unreadable UI, incorrect app branding, or unsupported claims.
5. Check the rendered resolution, orientation, duration, frame rate and codec against the requested platform/export requirements. Verify both exact dimension contracts: 1080×1920 for 9:16 and 1080×1350 for 4:5.
6. Inspect the 4:5 version separately for reframing defects, cropped faces/hands, hidden UI, caption collisions, and misplaced CTAs; passing the 9:16 QA does not imply the 4:5 version passes.
7. If a problem appears, fix the smallest relevant section and re-preview it. Avoid re-generating the whole composition for a localized defect.

Deliver an **editable first-pass project** plus a preview render when rendering is requested/appropriate. Include:
- The HyperFrames project/composition files, not just a flattened MP4.
- Both exports: `..._9x16_1080x1920.mp4` and `..._4x5_1080x1350.mp4`.
- Editable HyperFrames variants/compositions for both aspect ratios.
- The preview MP4 and/or contact sheet if produced.
- `ASSET_MANIFEST.md` (or the project equivalent) listing assets used.
- A short edit note with the opening hook, scene order, main cuts, caption approach, audio choices, CTA, assumptions, and 3–5 high-value places the user may want to refine.

Do not call the work final or polished if the user explicitly intends to refine it. Avoid high-cost/full-quality renders until the first-pass preview is accepted, unless requested otherwise.

After the first pass is rendered, hand it to the owner through `/review` (Cut Notes rounds) and apply the returned notes with `/review done` until a round closes with no open notes. The owner's confirmation of the last round is the sign-off; delivery to the final folder happens after it.

## 8. Final quality checklist

- [ ] The first second gives the viewer a reason to continue watching.
- [ ] The message follows a clear problem → product proof → benefit → CTA arc where supported by the material.
- [ ] Creator identity and source performance remain consistent; edits do not create visible continuity jumps.
- [ ] The actual product UI—not a fabricated replacement—is shown accurately.
- [ ] Captions match the audio and are readable on a phone.
- [ ] The logo, colors, typography, end card and CTA come from the approved app library.
- [ ] Dialogue is clear, music supports rather than competes, and cuts are audible/visual clean.
- [ ] No unsupported claims, added features, fake social proof or fabricated store details.
- [ ] Both requested exports exist and have verified exact dimensions: 1080×1920 (9:16) and 1080×1350 (4:5).
- [ ] The 4:5 version is correctly reframed in HyperFrames and does not rely on stretching or another AI generation.
- [ ] The video is technically valid and the project remains easy for the user to revise.
- [ ] The handoff clearly describes what was built and where further refinement would have the greatest value.