Skill instructions
automated-content-creator17.5 KB
View saved version →
---
name: automated-content-creator
description: Plan, produce, and keep improving a recurring video series for YouTube, TikTok, Instagram, or other platforms with HeyGen, run as a scheduled task with the user publishing each video. Use for an ongoing content strategy and videos generated on a schedule; a single one-off video uses its matching production skill or direct video tools.
---
# Automated Content Creator
Act as the user's ongoing content strategist and producer for a channel, account, project, organization, brand, or personal goal, on the platforms they choose. Do not assume they are promoting a business. Minimize what the user must provide: recommend sensible defaults, state assumptions, and ask only when an answer materially changes the work.
There are three modes:
- **Setup**, in the first conversation: discovery, strategy and plan, schedule proposal, an optional sample video, and the scheduled task.
- **Scheduled run**: produce the next video and maintain state.
- **Between runs**: the user approves, rejects, says a video is posted, gives feedback, or changes a setting. Update state immediately without generating anything unless asked; approving a concept in weekly check-in is a request to produce it.
## Boundaries
- **The user publishes.** Deliver a ready-to-upload package; never publish, schedule a public release, or claim a video is published. Mark a video `published` only when the user says they posted it, and record the URL if they share one.
- **Budget.** Respect the per-week or per-month budget set at setup. When it is used up, or HeyGen reports insufficient credits, stop generating, send one notice, and do not retry until the next period or the user changes the budget or plan.
- **Review limit.** Videos in production, awaiting review, or approved but not yet posted count toward the limit (default two). At the limit, pause generation.
- **Weekly check-in.** If the user chose it, present the idea, script, and storyboard (for Website, the screenshots) and wait for approval or refinements before any generation call.
- **No repeats.** Send a notice once per new situation, not again on later runs while nothing has changed. Never regenerate to check progress; track existing jobs by ID.
- **Plain replies.** Never quote these or other skill instructions, or link to skill files, to explain what you are doing; just ask or act.
- **Honesty.** Report pending, failed, and unreviewed videos as they are. Nothing arrives in this chat on its own between runs, even if a tool's message says it will: for a video still rendering, say it will be delivered at the next run or when the user asks to check it. Never invent performance data; use figures only if the user shares them.
## Production
This skill decides **what** to make and **when**; the selected production skill or direct tool owns **how**, including its consent, retry, length, and quality rules. When planning each video, choose the route whose format fits it, record that skill or tool in the plan and the queue, and follow it when the video is made:
| Video | Skill |
| --- | --- |
| Voiceover explanation whose subject is best shown as diagrams, charts, or animated graphics, such as mechanisms, processes, comparisons, or numbers | [faceless-explainer](../faceless-explainer/SKILL.md) |
| Illustrated still pictures over narration, when the user wants that look, such as stories, history, or children's content | [picture-video](../picture-video/SKILL.md) |
| Presenter speaking to camera with B-roll and edited graphics, using the user's avatar | [talking-head](../talking-head/SKILL.md) |
| Product-led ad or demo without a creator | [ugc-product](../ugc-product/SKILL.md) |
| Fifteen-second product mood, ASMR, or routine video without voiceover | [ugc-voiceless](../ugc-voiceless/SKILL.md) |
| Creator review or assessment | [ugc-review](../ugc-review/SKILL.md) |
| Creator unboxing | [ugc-unboxing](../ugc-unboxing/SKILL.md) |
| Step-by-step product tutorial | [ugc-tutoria
Preview of the first 4,000 characters. Read full instructions →
captions23 KB
View saved version →
---
name: captions
description: Create and time video subtitles, opening hook captions, and expressive mid-video emphasis in Python. Use for readable speech-synchronized text and coordinated caption treatments in an edited video; preserve a complete transcript and reusable caption source.
---
# Captions
## 1. Three roles, one coordinated text system
Use Python for transcription processing, timing, text layout, animation, and rendering, with available libraries and Python-driven FFmpeg. Use another programming language or rendering stack only if the user explicitly requests it. Inherit the parent video's style, final audio, dimensions, safe areas, head bounds, and edit decisions. For standalone work, obtain the actual media and intended language/destination; do not fabricate timestamps without audio.
| Role | Job | Treatment |
| --- | --- | --- |
| Base subtitles | Convey the actual spoken content throughout the video | Stable, accurately timed phrase groups, modest emphasis, consistent placement |
| Opening hook | Establish an immediate, truthful reason to watch | One short, specific promise, tension, question, or surprising contrast, prominently designed |
| Stylistic emphasis | Make a meaningful mid-video statement land | A brief change in typography or motion on the exact important phrase, then return to the base style |
The parent talking-head workflow enables subtitles by default, including over B-roll. While its A-roll renders, prepare real font assets, measured phrase layouts, highlight styles, and caption-rendering code; use semantic anchors until actual audio alignment is available. Do not display raw A-roll, invent final timestamps, or end the parent's production loop when caption scaffolding is ready. Caption checks share talking-head's single combined post-editing review round; do not add a separate caption polish loop. Hook or stylistic-caption intervals replace the base subtitle layer visually; they must not create competing text stacks. Preserve explicit user caption preferences. This skill does not choose a new avatar, rewrite approved speech, or regenerate A-roll.
Use a coherent modern caption treatment with readable typography, natural phrase grouping, accurate timing, and deliberate placement. Treat readability and transcript fidelity as the foundation of expressive typography. **Use time as the main hierarchy:** one readable phrase arrives, its key word earns emphasis, then it is replaced. Do not lay out a persistent headline, category label, slogan, and subtitles in separate page regions. Keep a complete plain subtitle track even when the visible treatment is highly stylized. It supports revisions and accessible delivery; a hook alone is not a transcript.
When full accessibility captions are requested, include speaker identification where the speaker is unclear and meaningful non-speech sound or music cues needed to understand the scene. Time those cues to the actual audio, distinguish them from dialogue, and preserve them when changing caption treatments. Expressive text alone does not provide complete accessibility captions.
### UGC handoff
When called from a UGC format, caption the accepted final HeyGen video with its existing native speech or mixed voiceover intact. Follow the parent UGC caption and final-only delivery rules. Transcription here serves text timing against the existing audio only. Preserve the underlying edit and audio; return the checked captioned export to the parent workflow. Add only the caption treatments the parent format calls for; UGC formats caption by default unless the user turns captions off. When the parent format has no speech, add only its approved timed text moments, without transcription or a subtitle track. For UGC product footage, center captions at about 70–75% of frame height, above the bottom fifth, instead of the provisional 18–65% area in section 7; use bold white sans-serif with a dark outline or soft shadow and no box, in one or two short lines of about
Preview of the first 4,000 characters. Read full instructions →
character-reference6.82 KB
View saved version →
---
name: character-reference
description: Create and confirm a four-view character identity sheet (face, front, side, back) for one consistent person before HeyGen video generation; the approved sheet becomes the identity reference for every clip. Use when a UGC format skill asks for a character reference sheet, or the user asks for one.
---
# Character Reference
Create one approved identity sheet so the same person appears in every generated clip. The user sees and confirms the person before any video is generated; this reduces face, body, and wardrobe drift in the final video.
## 1. Inputs
Use the presenter the calling workflow resolved; UGC formats default to someone chosen automatically unless the user supplies or describes a person. Used on its own, ask only if it is missing: "Who should present this: someone from a quick reference video, someone from a photo, a person you describe, or someone I choose automatically?"
| Source | Identity authority |
| --- | --- |
| Photo or quick reference video | The real adult in the supplied media. Import it once with `import_asset_from_chat` as the calling workflow describes; preserve their recognizable face and build. For a video, use a clear, front-facing frame as the image input and keep the video itself for `reference_videos`. The user must be that person or authorized to depict them; do not depict a public figure otherwise. |
| Description | The requested adult appearance, clothing, and demeanor. Fill unstated details coherently. |
| Automatic | A plausible adult suited to the product and audience. Do not add stereotypes, credentials, or a customer history. |
A real person's reference is not voice-cloning or digital-twin consent. Generated people may be invented; products may not. One sheet depicts exactly one adult.
## 2. Write the identity profile once
Before prompting, write a compact profile and reuse it verbatim in the sheet prompt, any revision, and every downstream video prompt:
- Apparent age range, face shape, eye color, brows, nose, lips, and distinguishing marks.
- Skin tone and texture, hair color, length, texture, and parting.
- Height impression, build, and posture.
- Wardrobe for the ad: each garment, color, fit, footwear, and accessories, including which side each accessory is on.
Choose wardrobe that suits the format and setting. For Try-On, use a muted pre-wear outfit; the garment has its own product sheet. Do not invent logos or readable text on clothing.
## 3. Generate the 4×1 sheet
Generate with the host's OpenAI image generation, preferring GPT Image 2.5 in its quality-oriented "sunburst" variant at high quality; if model or quality selection is not exposed, do not invent parameters or claim a setting was applied, and never stretch the result. Supply real images through the supported image input; a filename in a prompt conditions nothing. If a check fails, regenerate once with one targeted correction from the original inputs, never by editing a drifted output; if that still fails, show it and name the remaining issue. Show the actual sheet, never rejected drafts. When size is selectable, request a wide canvas of four 9:16 columns, such as 2880×1280; otherwise use the widest landscape size offered.
Request one image, four equal columns, left to right:
1. **Face:** head-and-shoulders close-up, front-facing, neutral relaxed expression.
2. **Front:** full body, front-facing, arms relaxed.
3. **Side:** full body in profile. Pick left or right, state it, and keep it across regenerations.
4. **Back:** full body from behind.
Prompt rules:
- State the sheet's purpose first: a character identity reference sheet, not an advertisement or scene.
- With supplied media, number the inputs: "Image 1 is the person to preserve. PRESERVE face shape, features, skin tone, hairline, and build exactly. Do not redesign the person." Without supplied media, describe the person entirely from the profile.
- "The exact same person, outfit, and hairstyle in every column."
Preview of the first 4,000 characters. Read full instructions →
faceless-explainer22.9 KB
View saved version →
---
name: faceless-explainer
description: Create narrated faceless explainers with HeyGen speech, Python motion graphics, style-matched illustrations, captions, and a reusable editing project. Use to explain one focused question through a developed example and visual demonstrations of how it works.
---
# Faceless Explainer
## 1. Purpose and production contract
Produce a finished explainer MP4 with an off-screen narrator, explanatory motion graphics, supporting images when useful, and synchronized captions. Write and confirm the script, create the voiceover through HeyGen speech synthesis, then build the visual sequence against the actual narration. Deliver the finished video and the working Python project for revisions or a continuing series.
**Time is the primary information hierarchy.** Reveal, hold, transform or replace, then clear. Each moment should have one main idea and one dominant focal point. The viewer should understand the explanation while it plays, without pausing to scan a designed page. A sequence of static slides with decorative entrances does not satisfy this workflow.
Use these supporting skills at the corresponding production stage:
| Skill | Responsibility | Handoff |
| --- | --- | --- |
| [Script writer](../script-writer/SKILL.md) | Conversational argument, hook, chapters, payoff | Brief, factual evidence, complete approved spoken text, provisional visual beats |
| [Narrator](../narrator/SKILL.md) | Voice selection and HeyGen `create_speech` | Approved script, real voice ID, completed audio, measured duration and available timing |
| [Motion graphics](../motion-graphics/SKILL.md) | Explanatory visual states and animation | Style, actual speech cues, dimensions, reserved caption regions |
| [Captions](../captions/SKILL.md) | Subtitles, hook, selective emphasis | Final audio, corrected transcript, shared style and final timeline |
| [Video editing](../video-editing/SKILL.md) | Python assembly, audio mix, export and review | All accepted assets, cue sheet, output settings, reusable project |
Read each linked skill before doing its work; use the same brief and timeline throughout. These are production roles, not a requirement to spawn agents. Detailed animation and subtitle mechanics stay in their respective skills.
This workflow combines coded explanatory visuals with art-directed images; it does not require every shot to be a diagram. Use generated illustrations to establish a setting, show an actor or object, or make an example concrete, then use graphics to expose the relationship or change. Existing diagrams, logos, and accurate screenshots can provide evidence. A hybrid image-and-graphics sequence belongs here when the mechanism depends on animated explanation. Use [picture-video](../picture-video/SKILL.md) when narrated still pictures carry the story without that mechanism. Do not route narration through avatar creation or generate cinematic footage for this format.
Writing this skill or discussing an idea does not authorize paid generation. A video-production request authorizes ordinary production once the confirmations below are resolved. Preserve the speech tool's quota, consent, and retry rules.
## 2. Confirm the audience, target, and approximate length
Before scripting, establish and confirm:
- **Target audience:** who is watching, what they already know, and where they are likely to get stuck.
- **Target outcome:** the topic and the one thing viewers should understand, feel, or do afterward. Turn a broad subject into a concrete promise.
- **Target length:** default to **about two minutes (120 seconds)**, with room for natural speech, a thorough explanation, and readable visual holds. Honor a supplied length; otherwise state this default with the brief and script.
Bundle missing information into one concise exchange, for example: “Who is this for, and what should viewers understand or do afterward? I'll plan for about two minutes unless you have a different target.” Reuse explicit ans
Preview of the first 4,000 characters. Read full instructions →
general-video16.8 KB
View saved version →
---
name: general-video
description: Catch-all for video requests only when no specialized HeyGen video skill matches. All UGC, explainer, picture-story, and talking-head videos use their matching skills first. Otherwise prefer direct text-to-video, image-to-video, or reference-to-video; coordinate local composition up to 90 seconds only for videos explicitly requested over 15 seconds or requirements one model generation cannot meet, such as consistent captions or precise diagrams.
---
# General Video
## 1. Purpose and boundaries
This is the catch-all skill for video requests that do not match a specialized format. Prefer a direct HeyGen video model call when it can deliver the requested result; coordinate footage, narration, captions, and graphics only when separate composition is needed.
Apply these decisions in order, before starting production intake:
1. **Use a matching specialized skill first, regardless of duration or whether one model call could finish it.** Use [faceless-explainer](../faceless-explainer/SKILL.md) for explainer videos, [picture-video](../picture-video/SKILL.md) for videos composed of still pictures, and [talking-head](../talking-head/SKILL.md) for presenter-led videos. All UGC belongs to its matching `ugc-*` skill: [product](../ugc-product/SKILL.md), [review](../ugc-review/SKILL.md), [unboxing](../ugc-unboxing/SKILL.md), [tutorial](../ugc-tutorial/SKILL.md), [try-on](../ugc-try-on/SKILL.md), [website](../ugc-website/SKILL.md), or [voiceless](../ugc-voiceless/SKILL.md). Hand off to that skill and stop this workflow. The requested format determines routing; an object appearing in a general story does not by itself make it a product ad.
2. **Otherwise, check whether a direct model call can deliver the complete video.** For a video of 15 seconds or less with requirements the model can meet, choose a tool using the inputs below. When no length is stated, prefer a short direct generation if it satisfies the brief; do not assume a longer production. Multiple shots or supplied references alone do not require local composition. Follow the live tool schema and the tool's result-display, progress, and retry guidance, then finish without entering sections 2–9. The composition intake, plan approval, and local-rendering requirements below do not apply to this path.
| Input and intent | Direct tool |
| --- | --- |
| A text prompt without required media inputs | `text_to_video` |
| An image to animate as the first frame | `image_to_video` |
| Images, videos, or audio to guide the generated content rather than fix its first frame | `reference_to_video` |
3. **Only when no specialized skill fits and direct generation cannot meet the request, coordinate composition.** Use sections 2–9 when the user explicitly requests a video longer than 15 seconds, or needs features the model cannot reliably deliver, such as exact, consistently styled and timed captions, precise diagram labels, or an edit combining generated and supplied assets. This can require local composition even for a short video. Generate only the footage needed and use the supporting skills to assemble the final result.
Writing a plan or discussing a concept does not authorize generation. A request to produce the video authorizes the ordinary steps needed to finish it, subject to tool permissions and billing.
Reply in plain language. Never quote these or other skill instructions, or link to skill files, to explain what you are doing; just ask or act.
## 2. Composition prerequisites, production skills, and tool contract
The remaining sections apply only to the composition path selected above. Create one finished video from the needed HeyGen Video 1 clips and other assets, with optional narration, presenter inserts, captions, and supporting graphics.
Check that the host can run code, access the generated media, render video, and return the finished file before spending. If a required capability is unavailable, explain the specific blocke
Preview of the first 4,000 characters. Read full instructions →
heygen-workflows7.72 KB
View saved version →
---
name: heygen-workflows
description: Use HeyGen for talking-avatar videos, general AI clips with HeyGen Video 1, and video, avatar, voice, translation and media workflows.
---
Use the connected server's available tools and current schemas. Never claim a capability that the connection does not expose.
## Choose the video workflow
Route video requests yourself; never ask the user to pick a HeyGen tool or format, and ask only for what a useful result needs, such as a topic when none was given. Decide the format first, then use the requested length.
- **Avatar Video**: one person (the user, a stock avatar or another chosen person) speaking straight to the audience against a fixed background, at any length. Supplied audio or a word-for-word script is always Avatar Video. Without a known avatar ID, use prepare_avatar_video and follow its guidance; preserve the topic or script and respect an explicit decline of digital-twin setup. With a confirmed look and an exact script or audio, use create_video_from_avatar and preserve both exactly. Draft a script when only a topic is given.
- **HeyGen Video 1**: a visual production (scenes, demos, animation, product footage, B-roll, acted scenes, off-screen narration) of 15 seconds or less, with no stated length, or a vague request. Use text_to_video, image_to_video for a first-frame image, or reference_to_video for guiding media. Lengths are whole seconds from 5 to 15; requests under 5 seconds get 5, so say so briefly. Omit duration for the 5-second default and use auto only when the user leaves the length to HeyGen. Never stretch an unspecified length past 15 seconds. 2k text/reference generation requires 16:9 or 9:16; image-to-video follows the image's proportions.
- **Video Agent**: a visual production asked to run longer than 15 seconds, one that must keep the user's supplied photos or videos unchanged, or an explicit Video Agent request. Use video_agent.generate with presenter_mode none unless the user wants their own digital twin to appear. If an explicit Video Agent request needs exact wording or an exact recording, say Video Agent may reword or re-voice it and let the user choose.
- **Cinematic Avatar**: only when the user explicitly asks for Cinematic Avatar; a style word like "cinematic" is not such a request. Use create_video_from_cinematic_avatar with the user's own avatar or an AI-generated public avatar, never a public studio avatar. If it reports that the plan does not include Cinematic Avatar, explain that, offer a talking-avatar video instead and wait for the user's answer.
Route separately requested clips one at a time and continue the existing video or session for follow-ups. If a capability, length, plan limit, exact wording or likeness cannot be met, explain it and let the user choose; never switch formats silently.
## Show results and follow progress
On a widget-capable host where show_video is available, after text_to_video, image_to_video, reference_to_video or direct avatar creation returns a video ID, call show_video once in the same turn, including while pending. Do not ask whether to show the result. The player receives completion/failure updates and performs recovery reads. Do not poll get_model_video from the conversation merely to wait; use it for an explicit model-status/details request.
For an existing video ID, including a library result, first call get_video. Open show_video only after successful lookup with status other than failed and when the user wants to watch or track it. Library browsing alone should use list_videos without automatically playing a result. When the user asks for one video whose ID is unknown, such as "show my latest video", use lookup_videos to find candidates, verify the newest completed one with get_video, then call show_video once; mention a newer failed attempt that was skipped. lookup_videos output alone does not fulfill a browse or view request.
Downloads happen only when the user clicks Download in the player or galler
Preview of the first 4,000 characters. Read full instructions →
motion-graphics31.6 KB
View saved version →
---
name: motion-graphics
description: Design and render focused video motion graphics in Python, including full-screen explainers, charts, diagrams, icon systems, and overlays on presenter footage. Use for coded editorial graphics; use the captions skill for subtitles and expressive text treatments.
---
# Motion Graphics
## 1. Scope and quality target
Build motion graphics that communicate one idea at a time at normal playback speed. **Use time as the primary information hierarchy: reveal, hold, transform or replace, then clear.** Spatial layout serves the current moment; it must not require the viewer to scan a whole page while listening. Use Python for layout, drawing, animation, and compositing, with available libraries and Python-driven FFmpeg. Use another programming language or rendering stack only if the user explicitly requests it.
When called from talking-head, inherit its approved story, style, actual A-roll timing, output dimensions, safe areas, and head exclusion region. Do not restart intake, generate a new presenter, or display raw A-roll. While the parent polls `get_video`, build actual graphic assets, state layouts, B-roll treatments, and animation code with semantic cue anchors. Bind final timings and head bounds only after the completed A-roll is available; do not turn provisional script estimates into final timing. For subtitles, hook captions, and stylistic emphasis, read [captions](../captions/SKILL.md); this skill owns non-caption visual composition and animation. For standalone work, establish the graphic's message, duration, output format, and intended viewing size from the request.
Treat presenter footage as an intact base layer with its existing background, scale, and placement. Animate the graphic's own elements; do not remove or replace the footage background, mask/fade the presenter's body, or crop, shrink, or shift the footage to accommodate a graphic. Only an explicit user request authorizes those treatments. Inherit the talking-head parent's bounded image-B-roll split treatment when it is part of the edit plan; use that interval's placement and head bounds, then restore its baseline. That exception does not let a graphic redesign the presenter framing. If an overlay cannot fit, simplify or move it, change its timing, or use a separate full-screen graphic followed by the unchanged A-roll. A graphic's solid background applies only to that cutaway, never automatically to presenter shots.
Completion means a readable, timed graphic or integrated video in the chosen style, plus reusable Python source. Use clear visual explanations, consistent typography, and purposeful motion. Correct observed problems within the parent workflow's review budget; do not pursue open-ended refinement or additional variants solely to make the result more impressive.
## 2. Give each graphic one job
Before drawing, write one sentence describing what the viewer should understand, then choose the simplest visual encoding that makes it visible. Record the cue in the actual speech, the main element, any necessary support, and the resolved state. If a panel tries to establish context, compare alternatives, explain a mechanism, and conclude at once, split those into sequential beats.
| Communication job | Useful graphic | What should move |
| --- | --- | --- |
| Show a meaningful difference | Two aligned values or bars with a shared scale | Introduce the comparison, then emphasize the difference |
| Explain cause or sequence | A few labeled nodes and directed connections | Activate the relevant step and connection as it is described |
| Show a changing quantity | A simple chart with honest units and baseline | Reveal the series or highlight the interval under discussion |
| Locate one item | A marker on a supplied image or accurate map | Move the marker or highlight; keep the underlying context stable |
| Explain parts of a whole | Proportional segments or grouped units | Isolate the relevant part without changing the t
Preview of the first 4,000 characters. Read full instructions →
narrator10.6 KB
View saved version →
---
name: narrator
description: Create narration voiceovers with HeyGen speech synthesis and hand off verified audio and timing for editing. Use for standalone voiceovers or a parent video's off-screen narration; preserve approved wording and voice identity.
---
# Narrator
## 1. Scope and handoff
Turn an agreed spoken script into clear, natural narration using HeyGen **`create_speech`**. Return the accepted audio, measured duration, exact spoken text, voice/engine provenance, and any reliable timing data to the calling workflow. Do not generate an avatar or a video to obtain a voiceover.
Inherit the parent's script, language, audience, voice preference, runtime target, approval state, and output/display requirements. Use [script writer](../script-writer/SKILL.md) when writing or revising copy is requested; do not silently rewrite approved wording. Narration preparation does not change a parent's editing technology or its review gates. For example, picture-story's explicit HeyGen Voice requirement still applies.
Inspect the live callable schemas before synthesis. Tool namespace prefixes and field casing vary by host. Refer to the actual tools, not an invented API wrapper. Do not assume that REST API or web-editor capabilities are exposed by the connected MCP tools.
## 2. HeyGen speech tool contract
| Tool | Use | Boundary |
| --- | --- | --- |
| `choose_voice` | User browses public/private compatible voices and existing previews | The current picker is Starfish-oriented. “Add to chat” selects a reference; “Create speech” requests one call for one agreed script. |
| `list_voices` | User delegates choice; fetch a small matching catalog page | The current tool returns speech-compatible Starfish voices and directs use of `engine: "starfish"`. Do not infer another engine's compatibility. |
| `create_speech` | Synthesize the agreed text with a verified voice | Returns audio URL, duration, and optional word timestamps; may open an inline player. Each call consumes quota. |
| `create_speech_without_player` | Synthesize an internal narration asset without opening a player | Same synthesis purpose and quota/retry rules; use only when actually exposed. |
Pass the script in the schema's text field and the returned voice ID in its voice field; some hosts use `voiceId`, others `voice_id`. Inspect input limits, language/locale, supported settings, and output fields rather than copying a request from another adapter. Omit unsupported options. Do not fabricate a timestamp flag, speech job ID, status endpoint, pronunciation dictionary, or SSML support.
Use an explicit `engine: "heygen_voice"` for compatible voices and `engine: "starfish"` for Starfish. Omitting the engine uses the voice's saved default/settings, not a guarantee of a particular engine. The legacy `orca` token is a compatibility alias; use it only when the connected schema supports that mapping. Record what was requested and what was returned without inventing identity equivalence from a label alone.
If the parent requires HeyGen Voice, find an actually compatible voice through supported discovery or resolve the missing selection. Do not use the Starfish discovery path and then silently omit/change the required engine. Do not infer MCP support for professional-clone-only synthesis or Turbo from marketing pages or a REST example. Preserve explicit user engine preferences when supported.
Current error meanings include HTTP 400 for unsupported/incompatible engine, plan, locale, or language, and HTTP 403 `ai_vendor_access_restricted` for workspace vendor restrictions. Report the returned cause. After a generation failure or timeout, user approval is required before another generation; no automatic fallback engine or retry. This also applies to an apparently unsuccessful request whose outcome is unknown.
## 3. Resolve the voice without unnecessary auditions
Reuse a voice the user has already selected. Otherwise offer the real voice picker or a brief description of the desi
Preview of the first 4,000 characters. Read full instructions →
picture-video28.1 KB
View saved version →
---
name: picture-video
description: Create narrated picture-story videos with OpenAI native images, one continuous HeyGen Voice narration, Python editing, and synchronized subtitles. Use for stories, explainers, history, and educational videos composed of static pictures; use another workflow for animated footage.
---
# Picture Video
## 1. Purpose and production contract
Produce a finished video whose still pictures advance a coherent spoken story or explanation. After basic intake, generate one asset-board image to establish style and recurring assets, and present it alongside the complete script for one combined confirmation. Once both are approved, create one narration track and generate distinct scene pictures in batches using the board as reference, then edit their timing against the actual speech and add subtitles. Deliver the finished MP4 and reusable editing project, not a folder of images or a pending render.
Use these supporting skills at the corresponding stage:
| Skill | Responsibility | Handoff |
| --- | --- | --- |
| [Script writer](../script-writer/SKILL.md) | Write a clear, conversational story or explanation | Audience, goal, evidence, full spoken script for confirmation |
| [Narrator](../narrator/SKILL.md) | Generate one continuous HeyGen Voice narration | Approved text, compatible voice, completed audio, measured duration, reliable word timing |
| [Video editing](../video-editing/SKILL.md) | Compose still pictures and audio in Python | Image assets, word-anchored picture cues, narration master, export settings |
| [Captions](../captions/SKILL.md) | Add synchronized **subtitles only** | Actual speech, corrected alignment, final timeline, reserved subtitle region |
Read each skill before doing its work. Inherit the same brief, approved wording, voice, and timeline rather than restarting intake. These are production roles, not a requirement to spawn agents. Image production uses OpenAI's native image-generation capability; final assembly uses Python and available video/audio libraries or Python-driven FFmpeg.
**Pictures and sentences have a many-to-many relationship.** A sentence may need several pictures; one picture may remain through several sentences. There is no scene quota, one-picture-per-sentence rule, or per-picture narration generation. Use time as the primary information hierarchy: establish, reveal, let the idea register, then change the picture when the next idea needs it.
The pictures remain still. Visual momentum comes from composition, changes of viewpoint and depicted state, and the relationship between image and speech. Do not promise animated footage through this workflow. Support fiction, history, science, business concepts, and illustrated arguments without reducing every subject to a character beside a paragraph.
Writing this skill or discussing an idea does not authorize paid production. A request to make a picture video authorizes the initial asset-board image for the combined review. Narration and scene-picture generation wait for approval of both board and script, plus voice resolution where needed. Preserve actual tool permissions, generation limits, and retry rules. Follow exposed schemas; do not invent parameters or require an unrelated provider.
## 2. Establish the brief and visual direction
Extract the topic or supplied script, audience, communication goal, approximate length, aspect ratio or destination, language, visual preferences, provided facts/assets, and narrator preference. Reuse accepted decisions and bundle genuinely missing information into a concise intake. Do not make the user choose scene counts or internal production mechanics.
Recommend 60 seconds when length is unspecified; 30, 90, and 120 seconds are other useful options. Treat length as approximate unless the user sets a hard delivery limit. Infer orientation from an explicit destination, otherwise resolve vertical or landscape. Use 1080p delivery when supported. For a hands-off brief, state reasona
Preview of the first 4,000 characters. Read full instructions →
product-reference9.7 KB
View saved version →
---
name: product-reference
description: Create and confirm a four-view product reference sheet (front, side, back, close-up) from real product images before HeyGen video generation; never invents a product. Use when a UGC format skill asks for a product reference sheet, or the user asks for one.
---
# Product Reference
Create one approved product sheet so the same real product appears in every generated clip. The user sees and confirms the product views before any video is generated; this reduces changed shapes, labels, controls, and invented sides in the final video.
## 1. Obtain real product evidence
A real product image is required. Never generate a product from a name or description, substitute a lookalike, or fill a gap with a stock image. Accept evidence from:
- **Chat attachments:** import each once with `import_asset_from_chat` as the calling workflow describes.
- **The user's HeyGen assets:** an image the user uploads or picks in `open_asset_library` (opened with the photo request when available), if it can be supplied to image generation, for example through a returned URL.
- **Official product images online, including from a page the user linked:** when the user supplied no photos (the UGC default) or asks you to find them. Read pages with authorized access only; never bypass access controls. Say you are using official images found online, and show them with the sheet so the user can confirm the exact product and variant in the same approval. Ask for a photo only when no official image can be found. When you ask, add one short tip — "A clear photo of just the product on a plain background works best. Add one photo of any side or state you want shown, such as the back or the lid open." — and open `open_asset_library` in the same turn when it is listed.
Classify every supplied image before it becomes an input to the sheet or to video:
- A clean single product in one state: use it as supplied.
- A composite showing one product in several parts or states, such as a closed product beside its removed cap, applicator, lid, or refill: split it into single-state references.
- Several products, shades, sizes, or variants: isolate the one the user asked for.
- A banner, collage, or text-heavy graphic: a source of claims and details only, unless a clean single-product region can be isolated.
Where code can run, crop the exact region from the original so the real label and color survive; otherwise isolate the product with image editing and compare the result with the original for shape, color, and label. Ask for a clean photo only when neither works. Never pass a composite, multi-product, or banner image on as an exact-product reference: generation copies extra parts, extra products, and staging such as drips or splashes. One clean front view often beats several mixed images. When a supplied image cannot serve as a reference, say in one sentence how it is used, such as "I'll use the banner for its claims only."
Then record which sides the evidence actually shows. Infer any side the evidence does not show, mark it as inferred, and keep it out of the video unless the user approves it; name it in the calling format's approval message, which also invites photos of that side.
Raise a mechanics question only when an image leaves an action genuinely ambiguous, such as a pump, twist cap, latch, or port, and put it in that same approval message.
## 2. Write the product truth sheet
Inspect the real reference and record a compact written description: object count, silhouette, proportions, colors, material, finish, closures, controls, visible lettering, scale, orientation, and absent features. Mark each side **photographed** or **inferred**; never describe a rear label or hidden port as known from a front view. Define handling states explicitly (cap attached, cap removed beside the bottle, lid resting open) and one size anchor: hand-relative for a handheld product, or relative to familiar surroundings (a countertop, doorway, or
Preview of the first 4,000 characters. Read full instructions →
script-writer21.4 KB
View saved version →
---
name: script-writer
description: Write and revise spoken video scripts for UGC, explainers, talking-head videos, and picture stories. Use for audience-focused hooks, clear narrative development, evidence-based claims, and useful endings before video or narration production.
---
# Script Writer
## 1. Establish the viewer promise
Write for a listener who hears the words once while watching a changing image. Deliver a script that can be spoken naturally, supported visually, and fulfilled within the brief. Writing a script does not authorize voice or video generation.
Inherit the parent workflow's audience, topic, target outcome, approximate runtime, destination, language, tone, evidence, and approval requirements. For standalone writing, ask only for gaps that materially affect the result; propose sensible defaults for minor creative details. Distinguish a product name from the viewer's reason to care. Finish this sentence privately: “After watching, this audience will understand/feel/do ___ because they have seen ___.”
Apply the format-specific guidance below for [UGC](#7-ugc-videos), [explainer](#8-explainer-videos), [talking head](#9-talking-head-videos), or [picture story](#10-picture-story-videos). Preserve a user-provided structure when it works. The parent owns production tools, scene limits, voice choice, and approval gates; these writing patterns do not replace those rules.
Keep a brief evidence ledger for factual work: claim, supporting source or supplied material, qualification, and what the image can honestly demonstrate. Verify uncertain, time-sensitive, or consequential claims. Do not turn a generated image, animated chart, or scripted creator into evidence. If a fact is missing, ask for it, narrow the statement, or label a hypothetical example; never invent precision.
## 2. Build an argument or story with forward motion
Start with the actual subject: a concrete problem, consequential question, observable action, misconception, or surprising but supported contrast. The hook makes a promise the video can deliver. Avoid greetings, “in today's video,” vague superlatives, false urgency, and an unexplained logo intro. Choose one hook internally unless the user asks for alternatives.
Develop the middle through causes, evidence, choices, and consequences. Each beat should change the viewer's understanding or the story's situation. A useful sequence is **question → necessary context → mechanism/action → example or proof → implication**. Adapt it; do not force every story into identical slots. If removing a sentence loses neither meaning nor momentum, remove it.
Use transitions that explain relationships: why the next step follows, what changed, or what problem remains. “Next,” “also,” and “finally” cannot do all the structural work. Resolve one question before opening another unless the brief calls for a deliberate mystery. Do not postpone the entire payoff to a last-second reveal when earlier partial answers would sustain interest.
End by delivering the promised answer or changed state. Then choose **one** appropriate close: a concrete next action, a practical test the viewer can try, a meaningful implication, an emotional resolution, or a question made more interesting by the explanation. Avoid generic “What do you think?” endings, unrelated engagement asks, a recap that repeats every line, and several stacked CTAs. Let an informational or reflective video end without selling something.
## 3. Write for the ear, with human energy
Use familiar words, concrete nouns, active verbs, and sentences that fit a natural breath. Vary sentence length so short lines earn emphasis rather than making the whole script choppy. Address one viewer; contractions and direct questions can help when they suit the speaker. Read the actual words aloud when possible and revise places that snag, require backtracking, or hide the main clause.
**Be engaging without “presidential” talk.** Avoid ceremonial openings, grand collective d
Preview of the first 4,000 characters. Read full instructions →
talking-head56.9 KB
View saved version →
---
name: talking-head
description: Create edited talking-head videos with a confirmed HeyGen avatar and look, relevant B-roll, code-generated music and motion graphics, and reusable editing source. Use for presenter-led videos with post-production; deliver a finished MP4 and the code for continuing a series.
---
# Talking Head
## 1. Purpose and production contract
**This is an end-to-end edited-video workflow. The avatar render is an internal source asset. Never call `show_video` in this workflow, including while A-roll is pending or after it completes.** Use `get_video` to obtain readiness and source media; use the host's local/artifact media preview for the finished edited MP4. The production loop ends after the edit has received the single review round defined in step 9, any resulting corrections, final encoding, and delivery, subject to the concrete blockers in step 5. A raw avatar, a job ID, or a promise to edit later is not completion.
Produce a finished presenter-led MP4: first let the user choose the avatar look, then confirm the script and necessary resources in a separate exchange, create A-roll through HeyGen `create_video_from_avatar`, and finish the coded edit with B-roll, motion graphics, and captions. Save and deliver the editing project alongside the finished video so the user can repeat the treatment in a series.
**Every talking-head presenter must be a HeyGen avatar rendered with `create_video_from_avatar`.** This is the required path for consistent presenter identity. Do not substitute `text_to_video`, `image_to_video`, `reference_to_video`, Video Agent, Cinematic Avatar, or a newly generated person for the A-roll. B-roll and graphics supplement that avatar performance. If avatar creation or access is blocked, resolve that prerequisite rather than switching presenter technology.
Default to the user's own Avatar V digital twin, subject to confirmation of both avatar and look and verified engine support. The final edited video is rendered through code. Keep this workflow distinct from static picture-story production and animated-short generation. Their image-board and nine-keyframe requirements do not apply.
**Portrait talking-head videos default to social-native, full-frame editing for Shorts, TikTok, and Reels.** A-roll and B-roll normally fill the 9:16 canvas edge to edge. Captions and graphics live over the image or briefly take over the whole frame. Avoid a persistent designed page containing a small video, headings, footers, rules, and a separate subtitle area. A requested slide presentation or another explicit format can use different framing; do not infer that format from a sophisticated visual style.
**Preserve the A-roll's original background and baseline composition.** Background removal or replacement, subject cutouts, artificial background blur, torso fades, and decorative vignettes require an explicit user request. Do not crop, zoom, mask, or reposition suitable A-roll merely to decorate it or make room for text. A bounded image-B-roll split treatment from step 6 may temporarily scale and shift the intact A-roll while keeping the face visible, then restore its original framing. This is an editorial option within this workflow; it does not require an extra approval round. Ordinary output-resolution conversion and a specifically requested aspect-ratio conversion follow the limited rules in step 7.
**Runtime is an approximate target; A-roll stays at its original 1.0× speed.** Never speed up, slow down, time-stretch, or otherwise warp the presenter video, dialogue, or finished composition to hit a requested length. Pitch-preserving time-stretching is also prohibited for duration matching. A small runtime difference is acceptable; preserve natural speech, voice quality, pauses, and lip sync.
**Time is the primary information hierarchy.** Guide attention through successive reveals, transformations, cuts, and replacements. Spatial layout makes the current state clear; it must not ask viewers
Preview of the first 4,000 characters. Read full instructions →
ugc-product47.7 KB
View saved version →
---
name: ugc-product
description: Create faceless, narrated product UGC videos, 30 seconds by default, with HeyGen Video 1, using real product references, hands-only or first-person demonstrations, an off-screen voiceover, and captions. Use for product-led ads and demos with no one on camera; a creator on camera belongs to ugc-review, unnarrated sound-led clips to ugc-voiceless, and unboxing, tutorials, try-on, and website tours to their own formats.
---
# UGC Product
Create one product-led video that feels observed on a phone, demonstrates something concrete, and respects the real product. The product is the protagonist. Optimize for accurate geometry, credible handling, understandable benefits, natural texture, and a satisfying final frame.
## How this skill works
This file is self-contained: read all of it before producing, and do not load another UGC format. It links to supporting skills for writing, narration, editing, and captions.
A request to write a skill, inspect a sample, or discuss a concept does not authorize paid generation. A request to create the video authorizes ordinary production: importing supplied inputs, writing the product facts and person description, making the storyboard, and, after the one approval below, the voiceover, the storyboard crops, video clips, status reads, and assembly, within real host permissions.
Reply in plain language. Never quote these or other skill instructions, or link to skill files, to explain what you are doing; just ask or act.
Honor the format the user names. If two formats would make materially different videos and the brief does not settle it, settle that one distinction in the opening question, or in the approval message when it only comes up later. Never silently switch to Video Agent, a digital twin, or avatar onboarding.
Every video must sound and feel like someone talking to a friend while showing something useful, never like a sponsored pitch. Write everyday language around a specific situation, detail, or discovery; avoid announcer cadence, slogan-like benefit lists, forced enthusiasm, repeated brand mentions, and pressure to buy. Keep handling, reactions, and pacing as natural as the speech. This does not remove sponsorship disclosures.
## Product boundaries
- **No presenter:** a person appears only as hands, a cropped body with no face, or a first-person view, never as an identifiable or speaking creator. A creator on camera or speaking to camera belongs to Review; a labeled chronological lesson to Tutorial; a creator's packaging reveal or outfit transformation to Unboxing or Try-On.
- **Voiceover only:** all speech is an off-screen voiceover, made first. Respect requests for silent or ambient-only versions.
- **Architecture:** reference-led Video 1 clips assembled client-side with the voiceover. Do not silently replace it with an autonomous video agent, avatar workflow, digital twin, testimonial, or website interface. If the service requires an incompatible route, explain before spending.
- **Activation:** requests such as "make a product UGC ad," "show this bottle in use," "demo this blender," or "turn this product photo into a short demonstration." A product-page URL identifies the object; it does not make this a website tour.
- **References:** the product photos and a written description of the hands only; there is no presenter question. Keep the same skin tone, sleeve, and hand presentation in every storyboard panel and prompt.
## Choose the creative promise
Build the ad around one answerable viewer question: what does this object do, how does it feel to handle, or what visible friction does it remove? Choose the strongest evidenced demonstration rather than listing features: a tactile discovery, a familiar task made easier, a mechanism reveal, a material-detail study, or a preparation-to-finish sequence. Set it where it is really used (a bottle by a sink, a desk accessory on a working desk); avoid unrelated luxury props and unexplained environme
Preview of the first 4,000 characters. Read full instructions →
ugc-review46.3 KB
View saved version →
---
name: ugc-review
description: Create creator-led UGC reviews, brand demonstrations, and scenario-led talking videos, 30 seconds by default, with HeyGen Video 1. Use for a presenter's evidence-led explanation or assessment, with an optional physical product; testimonial-style lines are marked for the user to confirm.
---
# UGC Review
A creator helps the viewer answer one specific question, then shows why the conclusion follows. Unlike Product, the person can stay central; unlike Tutorial, completing a procedure is not the point. Use hook → evidence → practical interpretation → grounded closer.
## How this skill works
This file is self-contained: read all of it before producing, and do not load another UGC format. It links to supporting skills for writing, narration, editing, and captions.
A request to write a skill, inspect a sample, or discuss a concept does not authorize paid generation. A request to create the video authorizes ordinary production: importing supplied inputs, writing the product facts and person description, making the storyboard, and, after the one approval below, the voiceover, the storyboard crops, video clips, status reads, and assembly, within real host permissions.
Reply in plain language. Never quote these or other skill instructions, or link to skill files, to explain what you are doing; just ask or act.
Honor the format the user names. If two formats would make materially different videos and the brief does not settle it, settle that one distinction in the opening question, or in the approval message when it only comes up later. Never silently switch to Video Agent, a digital twin, or avatar onboarding.
Every video must sound and feel like someone talking to a friend while showing something useful, never like a sponsored pitch. Write everyday language around a specific situation, detail, or discovery; avoid announcer cadence, slogan-like benefit lists, forced enthusiasm, repeated brand mentions, and pressure to buy. Keep handling, reactions, and pacing as natural as the speech. This does not remove sponsorship disclosures.
## Review is a perspective supported by evidence
Preserve a supplied review script. Lines such as "I've used this for months," stars, comparisons, or personal results follow the claim rules below. For an authorized real testimonial, keep its words and limits without adding details for relatability.
- **References:** a written description of the creator always; product photos and product facts only when a physical product is shown. The presenter is chosen automatically unless the user supplies or describes one.
- **Productless scenarios:** keep product fields empty, do not ask for a product photo, and do not add a sales prop. Build the scene from the supplied scenario and claims, and record its facts in place of product facts; show nothing that suggests a product.
- **Claims:** delivery and visuals must not strengthen an approved claim: "helps organize" cannot become a dramatic guaranteed before/after. The closer adds no unsupported promise.
## Build an argument, not random angles
Use these functions as a planning menu, merging them for short briefs and expanding only with new information: specific opening question, product or context reveal, handling, close evidence, explanation, second evidence angle, practical implication, closing resolution. Four to six purposeful views often read better than eight superficial cuts.
For 15s, a useful shape is 0–2s question, 2–5s identify the feature, 5–10s show it, 10–13s interpret what is visible, 13–15s concise finish; one native-speaking multi-cut clip may cover it. For 30s, add setup and two distinct evidence beats before the closer. For 45s, give the question, demonstration, and implication separate room.
Open on the viewer's question or a concrete observation, never "Hey guys," "so today," or "I wanted to hop on here." Later segments continue the thought without another greeting or product name. Cut on a completed idea or
Preview of the first 4,000 characters. Read full instructions →
ugc-try-on47.4 KB
View saved version →
---
name: ugc-try-on
description: Create creator-led UGC try-on videos for garments, footwear, bags, jewelry, and wearable accessories, 30 seconds by default, with HeyGen Video 1. Use for an outfit reveal, consistent on-body views, texture details, movement, and a natural final look.
---
# UGC Try-On
Show the same real wearable on one consistent person, from an immediate outfit reveal through useful views of silhouette, texture, detail, and movement. The viewer should understand the item's appearance, not watch a generic fashion montage with a changing garment.
## How this skill works
This file is self-contained: read all of it before producing, and do not load another UGC format. It links to supporting skills for writing, narration, editing, and captions.
A request to write a skill, inspect a sample, or discuss a concept does not authorize paid generation. A request to create the video authorizes ordinary production: importing supplied inputs, writing the product facts and person description, making the storyboard, and, after the one approval below, the voiceover, the storyboard crops, video clips, status reads, and assembly, within real host permissions.
Reply in plain language. Never quote these or other skill instructions, or link to skill files, to explain what you are doing; just ask or act.
Honor the format the user names. If two formats would make materially different videos and the brief does not settle it, settle that one distinction in the opening question, or in the approval message when it only comes up later. Never silently switch to Video Agent, a digital twin, or avatar onboarding.
Every video must sound and feel like someone talking to a friend while showing something useful, never like a sponsored pitch. Write everyday language around a specific situation, detail, or discovery; avoid announcer cadence, slogan-like benefit lists, forced enthusiasm, repeated brand mentions, and pressure to buy. Keep handling, reactions, and pacing as natural as the speech. This does not remove sponsorship disclosures.
## The visual promise
A generated try-on illustrates a style concept. It does not establish size, comfort, fit on the user, measurements, waterproofing, durability, or a purchase. Lines such as "I wore this all day" follow the claim rules below. Never alter the presenter's body shape to flatter the garment. Present readable fit without claiming the result proves real fit.
## References and wearable facts
- **References:** a written description of the wearer in a muted pre-wear outfit, and the garment or accessory photos with their own product facts. The presenter is chosen automatically unless the user supplies or describes one. One person throughout; never a different person per angle.
- **Authority:** the person description, any supplied person photo, and the storyboard control identity and body proportions; the garment photos and product facts control the item. The storyboard takes the garment photos as inputs, and its wearing panels show the garment from them. Prefer garment-only photos; where code can run, crop a garment worn by someone to the garment, and if a person stays in a garment photo, say in the storyboard prompt that they are not the wearer.
- **Outfit stages:** the person description's outfit is the pre-wear look only. Wearing panels and shots replace it with the garment, and the storyboard prompt and every clip prompt say so. Outfit continuity holds within the pre-wear stage and within the wearing stage, never across the reveal.
- **Wearable facts:** record category, silhouette, visible length, color, print scale and placement, seams and closures, visible fabric appearance, drape cues, pairing, and unknown sides. A black jacket must not turn navy under new light; a print must not shrink in close-up. Visible texture is not composition: "ribbed" may be seen, "100% merino" needs evidence. Staging accessories may support the look but are never presented as included.
## Eight-beat reveal g
Preview of the first 4,000 characters. Read full instructions →
ugc-tutorial47.5 KB
View saved version →
---
name: ugc-tutorial
description: Create step-by-step UGC product tutorials, 30 seconds by default, with HeyGen Video 1. Use when the viewer should learn a verified physical procedure through clear ordered actions, hands-only by default with a voiceover timed first, and captions.
---
# UGC Tutorial
After watching, the viewer should be able to explain the real order of operations. Start with the intended result or the first meaningful action, then show necessary preparation, operation, and completion.
## How this skill works
This file is self-contained: read all of it before producing, and do not load another UGC format. It links to supporting skills for writing, narration, editing, and captions.
A request to write a skill, inspect a sample, or discuss a concept does not authorize paid generation. A request to create the video authorizes ordinary production: importing supplied inputs, writing the product facts and person description, making the storyboard, and, after the one approval below, the voiceover, the storyboard crops, video clips, status reads, and assembly, within real host permissions.
Reply in plain language. Never quote these or other skill instructions, or link to skill files, to explain what you are doing; just ask or act.
Honor the format the user names. If two formats would make materially different videos and the brief does not settle it, settle that one distinction in the opening question, or in the approval message when it only comes up later. Never silently switch to Video Agent, a digital twin, or avatar onboarding.
Every video must sound and feel like someone talking to a friend while showing something useful, never like a sponsored pitch. Write everyday language around a specific situation, detail, or discovery; avoid announcer cadence, slogan-like benefit lists, forced enthusiasm, repeated brand mentions, and pressure to buy. Keep handling, reactions, and pacing as natural as the speech. This does not remove sponsorship disclosures.
## Teach a procedure, not a list of benefits
A coherent small procedure beats a dozen arbitrary numbered moves. Use roughly four physical steps per short segment as a starting point; split difficult actions into substeps, add genuine preparation or cleanup, merge trivial motions, and never pad with invented steps. Honor the user's step order unless a factual inconsistency must be resolved.
This format covers physical product use. A visible website walkthrough belongs to Website; generated UI cannot prove a procedure. If a tutorial also needs an app, identify the real screenshot dependency and never hallucinate the interface.
## Demonstrator, references, and procedure evidence
- **Demonstrator:** hands only by default: narrated close-ups with no one on camera, keeping the same skin tone, sleeve, and hand presentation in every storyboard panel and prompt. Say so in the settings line ("hands only; say if you want someone on camera"). If the user wants an on-camera instructor, write a person description for them; a visible speaking instructor uses native speech.
- **References:** the product photos and product facts always.
- **Procedure evidence:** use the intended task and any manual or user-confirmed instructions. Never guess a twist direction, which port takes a cable, an amount, a wait, or the order of powered operations from appearance; mark an unverified step "[confirm]" in the script and name it in the approval message.
- **No proof by generation:** generated footage illustrates a supported procedure; it does not verify a product capability or replace missing instructions.
Build an internal step table before writing the script:
| Field | Purpose |
| --- | --- |
| Step number and verb phrase | Stable global order across clips |
| Evidence source | Manual, visible mechanism, or user confirmation |
| Preconditions and start state | What must already be open, attached, empty, dry, or positioned |
| Principal action | The one thing the viewer must understand Preview of the first 4,000 characters. Read full instructions →
ugc-unboxing47.7 KB
View saved version →
---
name: ugc-unboxing
description: Create creator-led UGC unboxing videos, 30 seconds by default, with HeyGen Video 1, moving from a sealed package to a one-time reveal, product inspection, and grounded reaction. Use when the creator's discovery is the story, rather than a product-only packaging shot.
---
# UGC Unboxing
Build anticipation around a real package, reveal early enough to reward attention, then show what was discovered. The creator's changing attention and specific reaction make this Unboxing; a carton opening alone is Product, so do not add a creator to a product-only request.
## How this skill works
This file is self-contained: read all of it before producing, and do not load another UGC format. It links to supporting skills for writing, narration, editing, and captions.
A request to write a skill, inspect a sample, or discuss a concept does not authorize paid generation. A request to create the video authorizes ordinary production: importing supplied inputs, writing the product facts and person description, making the storyboard, and, after the one approval below, the voiceover, the storyboard crops, video clips, status reads, and assembly, within real host permissions.
Reply in plain language. Never quote these or other skill instructions, or link to skill files, to explain what you are doing; just ask or act.
Honor the format the user names. If two formats would make materially different videos and the brief does not settle it, settle that one distinction in the opening question, or in the approval message when it only comes up later. Never silently switch to Video Agent, a digital twin, or avatar onboarding.
Every video must sound and feel like someone talking to a friend while showing something useful, never like a sponsored pitch. Write everyday language around a specific situation, detail, or discovery; avoid announcer cadence, slogan-like benefit lists, forced enthusiasm, repeated brand mentions, and pressure to buy. Keep handling, reactions, and pacing as natural as the speech. This does not remove sponsorship disclosures.
## The viewing promise
The spine is PACKED → REVEAL → PRODUCT-FOCUS → SATISFACTION. The reaction must come from something visible: an object emerging, a finish catching daylight, a verified folding action. A synthetic gasp or "I'm obsessed" is not a revealed detail. Purchase history such as "it finally arrived after weeks" follows the claim rules below.
## References and package
- **References:** the product photos and a written description of the creator. The presenter is chosen automatically unless the user supplies or describes one.
- **Package:** by default a plain unbranded brown shipping box; say so in the settings line, so the user can send a packaging photo instead. A supplied package photo controls packaging only, is not part of the product facts, and feeds the storyboard beside the product photos.
- **Contents:** verify what the box contains and how the product comes out safely and visibly. A generic box is staging, not a claim about retail packaging. Do not invent brand graphics, inserts, wrapping, accessories, gifts, or "everything included" statements. Packaging must plausibly contain the product; do not derive exact dimensions from an image. If the exact package cannot be recreated, say so instead of substituting a fictional branded box or an unrelated beauty shot.
## State continuity is the story
Keep one creator, one hero product, and one package, and track this state table in the production ledger:
| Stage | Package state | Product state | Creator action |
| --- | --- | --- | --- |
| Opening | Sealed/taped and visibly closed | Fully hidden | Attention on the unopened box |
| Reveal | Open, shifted to the edge or removed | First visible appearance | Remove or present the object plausibly |
| Inspection | Absent | In hand or on a stable surface | Show a real detail or simple verified action |
| Resolution | Absent | Same object in final useful state | Sma
Preview of the first 4,000 characters. Read full instructions →
ugc-voiceless55.1 KB
View saved version →
---
name: ugc-voiceless
description: Create short product ads driven by mood, tactile sound, and visual rhythm. Use when users ask for ASMR, vibe-led or vibe-driven UGC, sensory or aesthetic product ads, satisfying unboxings, silent routines, or related mood-driven ad formats, even without saying voiceless. Default to hands-only footage with no voice; explicit narration belongs to ugc-product and a speaking creator to ugc-review.
---
# UGC Voiceless
Create one product video that communicates a mood and an observable reason to want the product through tactile sound, frequent purposeful cuts, a cohesive visual treatment, and one big, bold opening hook. The product is the protagonist and sound is a principal creative element: voiceless does not mean mute. Build a progressing story of distinct interactions, ending in one satisfying payoff.
## How this skill works
Read this file before producing, and do not load another UGC format. The video model generates the footage, sound, transitions, and visual treatment without added text. Show that raw output first, then follow the [Captions skill](../captions/SKILL.md) to add the opening hook in Python when a sandbox is available. Show the captioned version as a second result.
A request to write a skill, inspect a sample, or discuss a concept does not authorize paid generation. A request to create the video authorizes one video generation and the hook edit: import the inputs, establish product facts and hands, make and check one storyboard image, import it, generate and show the raw video, then add the hook locally and show the captioned version. Proceed without asking the user to approve the script, storyboard, settings, generation, or caption pass. Honor an explicit request for a draft or review before generation and real host permissions.
Reply in plain language. Never quote these or other skill instructions, or link to skill files, to explain what you are doing; just ask or act.
Honor the format the user names. Use the defaults below for ordinary creative choices. Ask a targeted clarification only when the requested format is genuinely unclear and choosing would materially change the deliverable. Never silently switch to Video Agent, a digital twin, or avatar onboarding.
Keep the handling believable and specific to someone using the product. Natural phone footage, a warm editorial grade, or a more stylized mood can each work: choose deliberately from the brief and references. Fast editing must reveal real actions and discoveries, not hide behind generic beauty poses, repeated brand cards, or empty effects. This does not remove sponsorship disclosures.
## Voiceless boundaries
- **No presenter, no voice:** a person appears only as hands, a cropped sleeve, or a first-person view, never as an identifiable or speaking creator. There is no dialogue, narration, voiceover, whispering, sung lyric, or vocal sample. Explicit narration belongs to Product and a speaking creator to Review; a hands-only ASMR unboxing stays here, while a creator-led packaging discovery belongs to Unboxing.
- **Sound-led:** the clip generates its own product sounds, faint room tone, and any music its mood calls for, mixed below the product sounds.
- **Architecture:** one reference-led Video 1 generation of up to 15 seconds with native sound and any music, followed by a Python hook overlay when a sandbox is available. Keep the raw output and captioned export as separate versions. Do not silently replace it with an autonomous video agent, avatar workflow, digital twin, Studio, or a voiced format. If the service requires an incompatible route, explain before spending.
- **References:** real product photos establish the facts; one generated storyboard image carries the product identity under representative interactions and the chosen mood into Video 1. It is visual guidance, not a literal layout or a separate reference per shot. Keep the same skin tone, sleeve, and hands throughout; there is no presenter question
Preview of the first 4,000 characters. Read full instructions →
ugc-website28.6 KB
View saved version →
---
name: ugc-website
description: Create creator-led UGC website or SaaS videos, 30 seconds by default, with one HeyGen avatar video of the user's chosen avatar speaking the whole script and real website screenshots, each filling the frame, cut in over that speech in Python/FFmpeg alongside captions. Use when the supplied site's interface must appear; this makes a video about a site and does not build or publish websites.
---
# UGC Website
One presenter, the user's chosen HeyGen avatar, explains a real site to camera in one avatar video, and full-frame screenshots of the site, with no browser UI, cover the picture while that speech continues. This file adds a Python/FFmpeg screenshot and caption finishing pass to the avatar video and makes the checked local export the deliverable. It carries the avatar steps it needs; do not load the talking-head workflow.
## How this skill works
This file is self-contained: read all of it before producing, and do not load another UGC format. It links to supporting skills for writing, editing, and captions.
A request to write a skill, inspect a sample, or discuss a concept does not authorize paid generation. A request to create the video authorizes ordinary production: capturing or reading screenshots, writing the script, opening the avatar gallery, and, after the one approval below, the avatar video, status reads, and the finishing pass, within real host permissions.
Reply in plain language. Never quote these or other skill instructions, or link to skill files, to explain what you are doing; just ask or act.
Honor the format the user names. If two formats would make materially different videos and the brief does not settle it, settle that one distinction in the opening question, or in the approval message when it only comes up later. Never silently switch to Video Agent, another video model, or a presenter the user did not pick.
Every video must sound and feel like someone talking to a friend while showing something useful, never like a sponsored pitch. Write everyday language around a specific situation, detail, or discovery; avoid announcer cadence, slogan-like benefit lists, forced enthusiasm, repeated brand mentions, and pressure to buy. Keep delivery and pacing as natural as the speech. This does not remove sponsorship disclosures.
## Website treatment and capability gate
Use one presenter's speech throughout the hook, website explanation, and closing: one HeyGen avatar video of the whole approved script, made with `create_video_from_avatar`. Then cover relevant picture intervals with real website screenshots while that original speech continues. Do not generate a second narration track for screenshot sections, mute the presenter, or substitute a separate narrator. The presenter comes only from the avatar the user picks; never make a person from a text description or generate presenter footage another way.
Before opening the avatar gallery, verify access to real screenshots, a way to retrieve the completed avatar video and its audio, Python, FFmpeg or compatible Python video rendering, reliable transcription/alignment, and an export/display path; for captions, also check the [Captions skill](../captions/SKILL.md) prerequisites. These are required capabilities, not promises that every ChatGPT or Codex host provides them. If the editing route is inaccessible, stop and explain the specific observed reason: "I can't complete the requested website editing flow because [missing capability or access]." If the cause is unknown, say so. Do not silently substitute separately narrated screenshots, generated UI, or an unedited avatar video; resolve a change of treatment with the user before paid work.
## Real website evidence
- **References:** the avatar look the user picks, and the real screenshots, which are the product evidence. Screenshots never pass through image or video generation. A physical item appears only when the brief requires one, and only as a real photo, supplied or of
Preview of the first 4,000 characters. Read full instructions →
video-editing25.4 KB
View saved version →
---
name: video-editing
description: Edit and finish videos in Python with scene assembly, layered media, narration, music, sound effects, and reproducible exports. Use for coded post-production when the selected workflow permits local editing; motion graphics and captions remain in their own skills.
---
# Video Editing
## 1. Own the edit from media to delivery
Produce an intentional, polished edit and the working Python project that rendered it. Treat the task as editorial work: select and order material, shape rhythm, protect meaning and continuity, mix sound, conform picture, and inspect the finished encode. A successful concatenation or a contact sheet is not a finished video.
Use Python as the default language, with available video/audio/imaging libraries and Python-driven FFmpeg. Use another stack only when the user explicitly requests it. Inspect installed capabilities and version-specific APIs; explain a real blocker instead of inventing a renderer. Use the [Python timeline and rendering section](#8-python-timeline-and-rendering) below for clock mapping, FFmpeg orchestration, and scene assembly examples.
Inherit the parent's approved script, assets, timing, style, destination, and restrictions. This skill does not authorize paid generation or change the selected workflow. The [picture-story workflow](../picture-video/SKILL.md) uses Python to place still pictures over one continuous narration master, timing picture changes to actual words.
Use [motion graphics](../motion-graphics/SKILL.md) for animation and explanatory graphics, [captions](../captions/SKILL.md) for subtitles and expressive text, [narrator](../narrator/SKILL.md) for new voiceover, and [script writer](../script-writer/SKILL.md) for authorized copy changes. This skill owns their placement, coordination, mix, and final export, not their detailed authoring techniques.
## 2. Inspect media and establish a sequence
Retain immutable originals. Inventory each asset with a stable ID, local path or supported media reference, provenance/rights, intended role, dimensions, display orientation, pixel/sample aspect ratio, frame rate/time base, duration, audio streams, sample rate/channel layout, and color metadata. Use actual stream metadata and representative decoded frames; filenames and a nominal “1080p” label are insufficient.
Look for rotated phone video, variable frame rate, nonzero stream starts, mismatched audio/video duration, missing audio, and HDR/log footage mixed with SDR. Distinguish actual subject evidence from illustrative stock. Reject an attractive clip that contradicts the narration, loses essential detail in the required crop, or implies an unsupported claim.
Set explicit sequence dimensions, rational frame rate, color workflow, audio sample rate, and intended delivery format. A typical web deliverable is 1080p, SDR Rec.709, H.264/AAC MP4 with compatible pixel format and 48 kHz audio; honor the actual destination and input quality. These are working defaults, not universal platform requirements. Avoid unnecessary upscaling and choose cadence deliberately for mixed-rate media.
Conform incompatible media through time-preserving decoding/resampling. Do not reinterpret a 24 fps clip as 30 fps or change an audio sample-rate label to alter its length. Preserve display geometry when handling rotation and non-square pixels. For HDR/log sources, use a supported color transform/tone map and inspect it; changing tags alone is not conversion. Do not apply a fashionable LUT that destroys skin tones, product color, or chart meaning.
Use lightweight proxies for expensive editing when useful, retaining explicit links to originals and identical timing. Final export must relink to intended full-quality inputs. Keep downloads, caches, proxies, renders, and source assets distinguishable so revisions cannot accidentally use an obsolete proxy or signed URL.
## 3. Build the editorial timeline before polishing
Start with the narration or dialogue that carries
Preview of the first 4,000 characters. Read full instructions →