Pixara

View saved version →

---
name: "ad-creative"
description: "A coordinated static ad set from one product and one message: product intake, a headline under eight words from the user’s own claims, one key visual approved first, then hooks and sizes as variants with the headline rendered inside the image on a text-rendering model, the logo exact, spelling checked. Use when: paid-ad creatives with a product and a message; a static ad set, Meta or TikTok ad images, a billboard or out-of-home visual, a seasonal campaign key visual, a menu or poster with the product, banner ads in several sizes. Not for: organic posts with no product (social-graphics), product stills with no message (product-photoshoot), a video ad (product-reel), listing images (amazon-listing), a thumbnail (thumbnail)."
---

# Ad creative

Produce a coordinated set of static ad visuals. One product, one message, one key visual approved first, then the variants. The words live inside the image and are checked letter by letter.

## Rules that never bend

- The headline is under eight words and comes from the user's claims or their own line; a number, a price or a time appears only when the user wrote it. Body copy under twenty words when present. Nothing invented about the product, the offer or the results.
- Text is rendered inside the image on a text-rendering model (google/nano-banana-pro at 2K for 4:5, 9:16 and every wide format; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string quoted and its placement named; spelling is checked on every render and a misspelling is re-rendered, never accepted.
- The product is passed in the reference image field on every render and keeps its identity (the staging contract from intake); the logo is passed as a second reference when the brand has one and reproduced exactly.
- One key visual (the idea, the palette, the composition) is approved before any variant; variants change the hook, the format or the size, never the idea.
- Platform safe zones: at 9:16 the headline sits in the middle third; at 1:1 and 4:5 nothing important sits in the outer five percent; a billboard keeps the headline readable at a glance from the far side of a road.

## Intake, only for the gaps

Parse the brief first, then ask in one message only for what it left out: the product (a photo to upload, a URL, or a description), the message or offer, the audience, the formats (1:1, 4:5, 9:16, a billboard at 3:1 or wider), the count, the season or occasion when the campaign has one, the brand palette and logo when there are any. Ask for a missing message when the brief carries no line and no claims, and for a missing product. Never ask about models.

## Phases

1. Product intake. Look at the product photo inline (or read the description) and write a one-paragraph staging contract you reuse verbatim: the object type and form, material and finish, colours, the label state (the exact printed text if legible, otherwise "blank" or "unreadable"), its size next to a hand, how it opens or is used, one honest imperfection. Lock the angle to the side the photo shows. Lock the claims as a short allowlist.
2. Message. Write the headline and the optional body in two lines; show them; a nod proceeds.
3. Key visual. One generate_image at the primary format on google/nano-banana-pro at 2K with the product (and the logo) in imageUrls; verified: the headline rendered exactly on the first try at 4:5 and again on every variant. Open with the manifest ("image 1 is the product: same label, same visible side; image 2 is the logo, exact shape and colours"), then the scene that dramatises the message, the product large and sharp, the headline as an exact string in quotation marks with its placement and the safe zone, the logo where the brand puts it, the palette, the light with a direction, the mood in two words; then the negatives: no extra product, no invented label text, no stock-photo gloss, no HDR glow, no lens flare, no watermark, no other text. Wait, look at it inline, read the text back letter by letter. Refine once at most with "change only X, keep everything else exactly" on the same model. The user approves it.
4. Variants. One wave with generate_batch, the approved key visual passed as a reference and declared as the style and product reference beside the product photo: the other hooks when a set was asked (the problem, the mechanism, the result, a comparison of visible attributes only, the lifestyle) at the primary format, and the other formats by re-composing the same scene at each aspect, never by cropping text away. Each prompt repeats the manifest, the palette lines and the exact headline; only the hook or the aspect changes. wait_for_jobs.
5. Check. Look at every variant inline: the spelling of every word, the product's identity against the contract, the logo exact, legibility at phone size. One refinement per variant with "change only"; a misspelling is re-rendered.
6. Delivery. The set grouped by hook then by format, each with its headline, a note on which claims were used, and one next step (a product reel from the key visual, a second headline for a test).

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.

View saved version →

---
name: "amazon-listing"
description: "A marketplace image set from one product photo: a compliant main image on pure white, a seven-slot secondary sequence and optional A+ modules, one message per image, mobile-legible text from the user’s claims only, the approved main image reused as the anchor for every other one. Use when: marketplace listing images; an Amazon, Etsy, Shopify or eBay image set, a main image on white, infographic or feature images, an A+ content set, \"listing photos\" for a product page. Not for: general product photography with no marketplace (product-photoshoot), a paid ad with a headline (ad-creative), a video (product-reel), a thumbnail (thumbnail)."
---

# Amazon listing

Produce a compliant listing image set. One product, one message per image, text only from the user's claims, the approved main image as the anchor for every secondary.

## Rules that never bend

- The main image: a pure white background, the product alone and filling about 85 percent of the frame, the reference's visible side, no props, no text, no logos, no hands, square, at least 1600 pixels.
- Secondaries carry exactly one message each; text is short, at least a 24 point equivalent, with strong contrast, rendered on a text-rendering model (openai/gpt-image-2 or google/nano-banana-pro) from the user's claims verbatim. No claim, number or comparison the user did not write; competitor names never appear.
- The approved main image is passed in the reference image field on every secondary as the product; the label, colours and proportions never drift.
- Nothing invented about what is in the box; the contents come from the brief.
- Spelling is read back on every image that carries text; a misspelling is re-rendered, never accepted.

## Intake, only for the gaps

Parse the brief first, then ask in one message only for what it left out: the product photo (required; upload a local one; a description alone gets a packshot first through the product-photoshoot recipe, and that packshot becomes the reference), the scope (main only; main plus secondaries; main plus A+ modules; the full set), the claims allowlist, the box contents, the brand palette. Ask for a missing scope, and for a missing claims list when secondaries are wanted. Never ask about models.

## The sequence

Secondaries in order, each square: a hero in context; features and scale (a dimension callout or a hand for scale); in use; an infographic of three benefits from the claims; a comparison of visible attributes only; a lifestyle scene; a trust image (the box contents laid out, a material close-up).

A+ modules, when in scope, at 3:1 wide: a banner with the product and one line; pain points as three panels; features with callouts; ingredients or materials; how to use in three steps; an endorsement panel only from the user's own quotes.

## Phases

1. Product intake. Look at the product photo inline and write a one-paragraph staging contract you reuse verbatim: the object type and form, material and finish, colours, the label state (the exact printed text if legible, otherwise "blank" or "unreadable"), its size next to a hand, how it opens or is used, one honest imperfection. Lock the angle to the side the photo shows. Lock the claims as a short allowlist.
2. Main image. An EDIT pass, never a reference render: a reference render on google/nano-banana-pro keeps the photo's kitchen or desk no matter how the prompt asks to discard it (verified twice). generate_image on bytedance/seedream-5-pro with the photo in imageUrls, imageSize square_hd, and the prompt "keep the product exactly as it is, same shape, same angle, same finish, and replace everything else with a pure white seamless studio background; the product upright filling about 85 percent of the frame, only a faint soft contact shadow under the base; no props, no text, no logos, no hands" (2048 pixels; a faint grey cast is normal), or openai/gpt-image-2 with the photo in inputImages at 1:1 and quality high when the white must be pure. Wait, look at it inline against the contract and the rules (white, fill, no text). Refine once at most with "change only X, keep everything else exactly". The user approves it.
3. Secondaries. One generate_image per slot in one wave with generate_batch on google/nano-banana-pro at 2K, the approved main image in imageUrls and declared as the product, the message in the prompt, the text as an exact string in quotation marks where the slot carries one with its placement and size, the brand palette for backgrounds and callouts, the contract for the product; the negatives: no extra product, no invented label text, no stock-photo gloss, no HDR glow, no watermark, no other text. A+ modules the same way at 3:1. wait_for_jobs.
4. Check. Look at every image inline with the main image beside it: the same product, legible text at phone size, correct spelling, exactly one message. One refinement per image with "change only"; a misspelling is re-rendered.
5. Delivery. The set in listing order, each with its message in a few words, a note on which claims were used, and one next step (the A+ modules, or a product reel).

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.

View saved version →

---
name: "animated-story"
description: "A finished story video in 10 second blocks: a style key, a cast sheet per character, a three-act script with a narrator and optional character lines, every take first on ElevenLabs V4 or Seed Audio 1.0 for dialogue, five-shot blocks with a blocking still when two characters share a frame, assembly by construction, captions from the script. Use when: a narrated story with characters; a storybook or bedtime story, a myth or fairy tale retelling, a kids video or kids song video, a picture story, a comic-style short, an animated short with a beginning, middle and end. Not for: an explainer or documentary with no cast (faceless-explainer), a person talking to camera (presenter-video), a live-action cinematic trailer (cinematic-trailer), a single illustration, one character sheet on its own (character-sheet)."
---

# Animated story

Produce ONE finished story video. It runs on the same block engine as the faceless-explainer recipe (fixed 10 second blocks, every take before any clip, five hard-cut shots per block) with a cast that must stay themselves across every block, a narrator, and, when the brief wants them, character lines. Read faceless-explainer with get_skill for the block prompt and character-sheet for the cast; this recipe adds what a story needs.

## Rules that never bend

- Blocks: the duration in seconds divided by ten, whole blocks only. One narration line per block of 20 to 23 words, generated before any clip, never paraphrased, sized to its window.
- One style key image and one style formula of 80 to 100 words for the whole piece, passed or pasted byte-identical into every prompt; one hero portrait per character approved before any block, passed as a reference on every block that shows them.
- The narrator carries the story; characters speak only in declared dialogue blocks, and then only through a voice take laid over the clip, never native video speech, so the words are exact.
- Two characters in one frame means a blocking still for that scene: one wide frame in the style placing each character by their reference on a named position, passed with the cast so the clip keeps who stands where.
- Picture-story mode (the roster stills and one still per block with slow pushes in the assembler) is the cheap path; offer it when the brief is a bedtime story or a picture book.
- No text inside clips. A title card is a designed frame from a text-rendering image model as its own shot; captions come from the subtitles tool with the authored script.
- Nothing about a real person; a named public figure is declined.
- A story with nobody presenting on camera is still full of faces: every character keeps theirs, and the word faceless never enters a cast sheet, a style key or a clip prompt.

## Intake, only for the gaps

Parse the brief first, then ask in one message only for what it left out: the length (60, 90, 120 seconds; recommend 90), the look (storybook watercolour, flat cartoon, clay, paper cut-out, anime, comic ink, 3D toy), the audience (kids or general), the mode (animated clips or picture story), the aspect (16:9 or 9:16). Never ask about models or voices by name. Captions and a title are the one delivery question after the master exists.

## Phases

1. Style key. Write the style formula (medium, line and shape language, palette as five colours, light, texture, camera distance habit, mood; ending in negatives: no photoreal skin, no text, no logos). generate_image one style key on bytedance/seedream-5-pro at 1K from the formula: a neutral scene in the look, no subject. Look at it inline; get a nod. The formula and the key travel with every prompt from here.
2. Story. Three acts across the blocks (a setup, a turn, a payoff), one narration line per block of 20 to 23 words with numbers as words, a through-line object that resolves at the end, a cold open under eight words. Dialogue blocks, when wanted, hold one or two short character lines instead of narration, marked with the speaker. A kids song comes from generate_music on minimax/music-3 with the lyrics, and its blocks carry no narration. Show the script with the block count before any spend.
3. Cast. For every character, the character-sheet recipe in this style: the identity prompt, a hero portrait at 3:4 on bytedance/seedream-5-pro with the style key passed as a reference and the formula in the prompt, the split-screen when the character has many blocks. Look at each inline; the user approves each; the hero portrait is the reference for every block that shows them. Locations and props as a roster on the key, as faceless-explainer's phase 3: each location at the output aspect, props at 1:1, no location for more than two consecutive blocks.
4. Takes. Narration with list_voices on eleven-labs/v4, one voiceId and one delivery phrase repeated verbatim on every take; character lines on bytedance/seed-audio-1.0 with one voice description per character repeated verbatim (a two-voice exchange in one take when both speak in one block). generate_batch the takes, wait_for_jobs, get_media_metadata on each key; a take over 9.5 seconds is rewritten shorter and regenerated, three attempts, never time-stretched.
5. Blocks. Five shots per block with faceless-explainer's block prompt: the formula verbatim, the manifest naming the key, the location, each character by their portrait and any prop, five shots with times that sum to ten and no two neighbours sharing size or angle, the through-line when it appears, an Audio line of ambience and action sounds only, a negative line of no lip movement, no speech, no captions, no text. A blocking still first for every scene with two or more characters, generated on bytedance/seedream-5-pro with the portraits as references and passed with them. In a dialogue block the speaking character's mouth moves on their line's beat and the Audio line says so; the take is laid over it in assembly.
6. Clips. One generate_video per block on minimax/hailuo-3-max in reference mode with resolution "768P" exactly (capitals, the only value it renders; never 480P), duration 10, 16:9 or 9:16, the references in referenceImageUrls in the manifest's order (the key, the location, the characters, the props, the blocking still, at most seven of its nine slots); about 830 credits a block, verified with a 30 second three-block story where the cast held. Launch independent blocks together with generate_batch and wait with wait_for_jobs. Picture-story mode skips this phase and uses the roster stills and one still per block generated the same way.
7. Check. Tell the user what to check per block unless they asked for no check-ins: five cuts (a block with fewer than four is regenerated once with the cuts spelled out, then accepted), the look held, each character matching their portrait, no text, no leading freeze.
8. Music. generate_music once on google/lyria-3.5 (instrumental) in the story's mood with a named tempo, loop-safe, at least the piece's length; a kids song replaces it on its blocks.
9. Assembly. get_assembly_guide once, get_media_metadata on every key, then assemble_video: block N clip (or still with a slow push) at 10N for 10 seconds on the base track; block N take centred inside its block on an audio track; the bed on a second audio track at 0.6 with duck: true; a designed title card as a 2.5 second first shot only when asked; no text clips.
10. Delivery. Captions through the subtitles tool on zapcap/subtitles when wanted, with referenceTranscript authored from the script, one cue per block split into lines of at most five words and timed from the take's real start inside its block. Then one paragraph: what it is, the acts in a line each, and two next steps (a second episode with the same cast, a picture book from the stills). State each character's hero portrait key once so the user can bring the same cast back next time; nothing here is remembered for them yet.

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.

View saved version →

---
name: "avatar-video"
description: "A presenter video driven by an audio track, so the words are exact: the identity locked to a portrait, the script by type with every literal on-screen element listed, the voiceover first on ElevenLabs V4 or the user’s own track, the engine by input shape (Omni Human 1.5, Minimax Hailuo 3 Max Avatar, Kling Avatars V2, Sync Lip Sync 3), a frame check before spend, cutaways on the silent beats, captions from the script. Use when: the user asks for an avatar or a lip-synced presenter by name, supplies their own audio track or recording to drive a face, or needs the exact words over a static framing for a long read (a training module, a product walkthrough) where a sheet-based presenter would ad-lib. Not for: the default presenter route where the video model speaks (presenter-video), narration over scenes (faceless-explainer), a product with hands and a narrator (product-reel), a voice clone as the deliverable (clone_voice), dubbing an existing video into another language (dubbing)."
---

# Avatar video

Produce ONE presenter video where the words are exact because the audio comes first and the face follows it. This is the lower-priority route: the default presenter is the presenter-video recipe, where the video model speaks; this one runs when the user asks for an avatar, supplies audio, or the brief needs a long exact read.

## Rules that never bend

- The voiceover is generated first and its real duration read back; the picture is made to the audio, never the reverse. eleven-labs/v4 with a voiceId from list_voices, the user's own recording when supplied, or bytedance/seed-audio-1.0 replicating a voice the user owns from a sample they supplied.
- The script is written by type (a demo: hook, problem, solution, call; an explainer: context, concept, takeaway; a tutorial: what we build, the steps, a recap; a pitch: the pain, the vision, the product, the call; an announcement: hook, what changed, why, what next), and every literal element (a number, a name, a handle, a URL, a call to action) is listed in a critical-text block so nothing is paraphrased. Show it with the word count and the estimated duration before any spend.
- The presenter is addressed only through the attached portrait ("the person in the image"); their appearance is never described in the prompt; that mismatch is the first cause of a wrong face.
- Frame check before spend: the portrait's orientation against the output aspect (a landscape portrait for a 9:16 output is reframed with luma/reframe-image, chest-up and centred, never letterboxed) and a background added when the portrait has none.
- The engine by input shape: a portrait plus audio on bytedance/omni-human-1.5 by default (160 credits per second, audio under 35 seconds; verified: an 11 second read cost 1760 and kept the setting); minimax/hailuo-3-max-lipsync (the most lifelike face; audio 5 seconds to 5 minutes; about 170 credits per second at 1080P; keeps the portrait's shape; it can overact, so a serious line gets a calm delivery in the take) or kling/avatar-v2-pro for a plain talking head at a fixed framing (kling/avatar-v2-standard for the economy version); wan-video/wan-2.7 through generate_video with the track as its reference audio when the scene must be directed (a camera move, a gesture, a place; describe_model names the field); sync/lipsync-3 through lip_sync when the user supplied their own footage to revoice. describe_model on the chosen engine gives its audio length limit, and that limit decides the clip count.
- Cutaways (a product still, a screen, a designed frame with the critical text) sit on the silent or B-roll beats in the assembler; the avatar clips carry no baked text; captions come from the subtitles tool with the script as srtContent.
- Consent: a supplied photo is not permission to impersonate its subject. Decline public figures, minors and anyone the user has no right to use. Never imitate a real person's voice without a sample they own.

## Intake, only for the gaps

Parse the brief first, then ask in one message only for what it left out: the portrait (upload it if local; or a generated person with a stated gender and vibe), the script or the points it must cover, the audio when the user has their own, the duration when no script exists, the aspect (9:16 or 16:9 by destination), the product when there is one. Never ask about engines or models. Captions are the one delivery question after the master exists.

## Phases

1. Identity. The user's portrait, or one generated portrait with generate_image on google/nano-banana-pro or bytedance/seedream-5-pro (phone-camera realism, natural light, looking at the lens, chest-up, a plain background, a mature adult face, at the output aspect) followed by a realism pass (an image-to-image pass on bytedance/seedream-5-pro that keeps the framing and face and adds pore-level skin and real material detail, no beauty-filter smoothing). Look at it inline; get a nod. Then the frame check: reframe with luma/reframe-image when the aspect does not match; a background when there is none.
2. Script. By type, with the critical-text block; about 2.3 words per second; show it with the count and the duration.
3. Voice. list_voices for a voiceId from a one-sentence description, then generate_voiceover on eleven-labs/v4 with the script verbatim; wait; get_media_metadata for the real duration. When the engine's audio limit is shorter than the track, generate the voiceover per segment from the start, one segment per sentence group inside the limit (generate_batch, then wait_for_jobs); a user-supplied track longer than the limit is cut at sentence ends with media_utility on shotstack/trim-audio.
4. Clips. One avatar call per audio segment with the portrait in the image field and the segment in the audio field that describe_model names (image and audio on Omni Human 1.5; imageUrl and audioUrl on Minimax Hailuo 3 Max Avatar and Kling), or lip_sync with the user's footage and the track; the engine by shape, the scene directive only on wan-video/wan-2.7. Launch the segments together with generate_batch when the engine supports it, else one avatar call each, and wait with wait_for_jobs.
5. Cutaways. Stills or designed frames for the beats the script marks as B-roll, generated on google/nano-banana-pro (openai/gpt-image-2 when a frame carries the critical text as an exact string); nothing goes over the presenter's face.
6. Check. Tell the user what to look for in each clip unless they asked for no check-ins: lips on the words, no stiffness or drift in the face, the portrait's identity, no text. A clip that fails twice is retried once on the next engine in the list.
7. Assembly. get_assembly_guide once, get_media_metadata on every key, then assemble_video: the avatar clips in order on the base track with their own audio muted, the full track (or the segments at their moments) on an audio track, the cutaways as image clips over their beats, a bed only when asked; no text clips.
8. Delivery. Captions through the subtitles tool on zapcap/subtitles when wanted, with referenceTranscript authored from the script. Then one paragraph naming the engine by its display name, what was made, and two next steps (the other aspect, a second language through the dubbing tool).

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.

View saved version →

---
name: "character-sheet"
description: "An invented character that stays themselves: a fixed-order identity prompt, one approved hero portrait, a split-screen and a slot sheet of views and expressions in one of five style presets, checked for consistency and kept as the anchor other recipes reuse. Use when: a character sheet, model sheet, reference sheet, turnaround, expression sheet, or one invented character held consistent across views, poses and expressions for later images or videos. Not for: a real person's headshots, a single portrait, a thumbnail (thumbnail), a product (product-photoshoot), a face built from someone's photos."
---

# Character sheet

Invent one character and hold them stable. The deliverable is a hero portrait (the identity reference later work attaches), a split-screen (a standing full body on the left, a tight close-up on the right) and, when asked, a slot sheet of views and expressions.

## Rules that never bend

- Original characters only. A real person is never the seed unless the user supplied their photo and has the right to use it; then this recipe only adds views.
- One character per sheet. A second character is a second sheet.
- The identity prompt is written once in fixed order and repeated verbatim in every prompt; iteration changes one clause and keeps the rest.
- Adults have mature facial structure with defined bone and a real age; never a rounded, youthful face on an adult.
- The slot layout is fixed and named in the prompt; the model may not merge or drop slots. No text, labels or slot numbers in the pixels; no watermark.
- The style preset is stated once and repeated verbatim.

## Intake, only for the gaps

Parse the brief: who the character is (age, build, hair, skin, distinguishing features, wardrobe), the world they belong to, the style preset, the use (stories, a mascot, a game, videos, a virtual presenter). Ask in one message only when the character is undefined beyond a name, or the style cannot be inferred from the use.

## Presets

- Photoreal unretouched: real skin with pores, natural light, a phone or camera feel, no beauty filter, faint sensor noise.
- Editorial: studio light with a direction, clean backdrop, a fashion restraint in colour.
- Anime or 2D: flat colour, a named line weight (thin or bold), a consistent eye style, cel shading.
- 3D stylised: soft global light, rounded forms, subsurface skin, a clay or toy finish named.
- Game concept: painterly, a costume with function, a silhouette that reads at small size, a muted world palette with one signature colour.

## Models

google/nano-banana-pro for photoreal and editorial presets; bytedance/seedream-5-pro for anime, 2D and painterly presets and for the realism pass; the split-screen and the sheet always on a model that takes the hero in its reference image field (imageUrls on the two above, referenceImages on runwayml/gen4-image, which is built for character consistency).

## Phases

1. Identity prompt. Write it in this order, one clause each: the composition clause (one identical original character on every view, a white seamless studio); the identity in a sentence (age, gender, ethnicity when given, build); the face (shape, nose, mouth, jaw, skin texture and tone); the eyes (colour, shape, no glare or reflections); the brows; the hair (cut, colour, finish); the realism module for photoreal presets (pores, fine hair, no retouching, a phone or camera feel); the body; the wardrobe head to toe with materials and colours; the light (soft, even, a direction); the quality tail (sharp, natural colour); the negative tail (no text, no extra limbs, no second person, no glare in the eyes, no beauty filter). Then the preset lines verbatim.
2. Hero portrait. generate_image one three-quarter portrait at 3:4 as a draft; for photoreal presets, a realism pass (an image-to-image pass on bytedance/seedream-5-pro that keeps the framing and face and adds pore-level skin and real material detail, no beauty-filter smoothing). Look at it inline; show it and get a nod. It becomes the reference for everything after.
3. Split-screen. With the hero passed as the reference and declared ("image 1 is the character: same face, hair, skin and wardrobe"): one 16:9 image, a standing full-body view on the left panel and a tight face close-up on the right, same wardrobe, same light, thin gutter, no text.
4. Slot sheet, when asked. With the hero passed as the reference, generate one wide image laid out as a grid of named slots: front, three-quarter, profile, back; then four expressions (neutral, joy, doubt, anger); then two full-body poses. Same wardrobe, same light, plain background, thin gutters, no text. Name every slot in the prompt in reading order.
5. Check. Look at each image inline: the same face in every slot, the same wardrobe, no merged slots, no extra limbs. One refinement pass on a named defect as an image-to-image pass on bytedance/seedream-5-pro with "change only X".
6. Delivery. The hero, the split-screen and the sheet, the identity prompt in prose so the user can reuse it, and the hero's asset key stated once so later requests can attach the same face. Suggest the user keep the key and the prompt in their notes; nothing here is remembered for them yet.

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.

View saved version →

---
name: "cinematic-trailer"
description: "A multi-shot cinematic trailer, teaser, brand anthem, fashion film, car commercial, travel teaser or game trailer run as a phased production: story, treatment, a locked style contract, anchor stills before motion, a shot list on a beat grid, clips in waves, music, then one assembled cut with a designed title. Use when: a multi-clip cinematic trailer, teaser, brand anthem or manifesto film, fashion film, car commercial, travel or destination teaser, game trailer, or short promo with a story, a look and several shots. Not for: a single clip, a talking presenter (presenter-video), a narrated explainer (faceless-explainer), a narrated story with a cast (animated-story), a product with hands and a narrator (product-reel), cutting existing footage."
---

# Cinematic trailer

Produce a short cinematic piece from the user's idea as a phased production, never a single generation. You play each creative role in turn and show its artifact in a few lines of prose before moving on.

## Before planning

Ask once, in one message, only for what the brief did not answer: the target length (about 30 seconds as a teaser, about 60 as a story), the tone or genre, and whether music or a voiceover is wanted. Recommend one option per question.

## Rules that never bend

- The style contract: every image and clip prompt after the style phase includes the style lines verbatim. That is what makes the clips feel like one film.
- Anchors before motion: when a character, vehicle, object, product or place recurs across shots, never go straight to text-to-video. Establish a still first (the user's reference if supplied, otherwise a generated hero still approved by the user), then generate every shot with that subject from the same still, whichever video model the shot lands on. Prose alone drifts. A still costs a few dozen credits; re-rendering one off-model shot costs hundreds.
- The music is briefed with a tempo before the shot list; shot lengths are whole beats or bars of that tempo; cuts land on actions.
- Text is minimal: at most a title and an end card, each a designed frame from a text-rendering image model (google/nano-banana-pro; openai/gpt-image-2 only at 1:1, 2:3 or 3:2) with the exact string, animated with a slow move or placed as an image clip; never an assembler text clip; no text inside the shots.
- Faces: bytedance/seedance-2.5 refuses reference images that show a realistic person, so shots with a person go to minimax/hailuo-3 in reference mode with the still as the reference (2K); a shot in which the person speaks carries its line as a recorded take in referenceAudioUrls, the way presenter-video does, never as native speech from the prompt. Seedance 2.5 takes the shots with nobody in them, where its 30 second takes and camera work shine.
- A voiceover, when wanted, is generated on eleven-labs/v4 from an approved script and cut to its real duration.

## Sub-modes

The brief decides one; it changes the arc and the anchors, never the phases: a trailer or teaser (a hook image, rising fragments, a turn, a title); a brand anthem (a belief, the world it fights, the product or people as proof, the line at the end); a fashion film (one model, three looks at most, movement as the subject, macro texture beats); a car commercial (the car as an anchor still from three angles, a location with weather, driving beats with named camera moves, one interior beat, no invented spec claims); a travel teaser (five places, dawn to night, humans only as silhouettes or hands); a game trailer (a style key, a hero character, three escalating action beats and one quiet beat, the title as a designed frame).

## Phases

1. Story, as a dramaturg: a logline, the theme in one line, a through-line image that resolves at the end, 6 to 10 beats with their seconds and the one turn marked.
2. Direction, as a director: two treatment options in three lines each (world, camera language, the emotional shape, a tempo in beats per minute); recommend one, or let the user pick.
3. Style, as a style architect: the style contract in six lines: palette (three colours by name), light, medium and grade, lens and movement vocabulary, texture (grain or the medium's surface), mood in two words; plus two negatives. Repeat them verbatim from here on.
4. Sound first. generate_music on google/lyria-3.5 (instrumental) or minimax/music-3 (vocals) briefed like a producer: genre, mood, the tempo, instrumentation, the swell and the drop placed by seconds, at least the cut's length; a voiceover on eleven-labs/v4 (voiceId from list_voices) with the lines verbatim when wanted. Wait; get_media_metadata for the real durations. The tempo is the beat grid.
5. Shots, as a shot planner: 6 to 12 shots of whole beats or bars, 3 to 10 seconds each (up to 30 for a Seedance 2.5 take), one line per clip: subject, action, framing distance and angle (neighbours differ), one camera move or one subject motion, sound if the model renders it, which anchor still it starts from, and the action the cut lands on. No shot opens on a settled pose.
6. Anchors. generate_image the hero stills (a character, a product, a car, a key location) on bytedance/seedream-5-pro or google/nano-banana-pro with the style contract in the prompt; a photoreal person gets a realism pass (an image-to-image pass on bytedance/seedream-5-pro that keeps the framing and face and adds pore-level skin, real material detail, faint sensor noise, no beauty-filter smoothing); look at each inline; get the user's nod on anything that recurs.
7. Clips in waves. Launch every independent shot together, then wait_for_job on each. Shots with a person: minimax/hailuo-3 in reference mode with the still, plus the recorded line in referenceAudioUrls when the shot speaks. Empty shots: bytedance/seedance-2.5 or google/gemini-omni-flash-1.1 with the style contract. Open every prompt with a manifest naming what each attachment is and address the subject through the reference, never also in prose. Native audio on when the model has it and the sound is wanted (name all four layers: any line after a colon, room tone, the sounds of the actions, no music); otherwise "no speech, no music". End every prompt with the contract lines and "no text, no subtitles, no watermark". Draft an uncertain shot at 720p and re-run it at 1080p with the same prompt. Retry a failure once with the named fix or on the next model with the same tags.
8. Check. Tell the user what to look for in each clip against its shot line (the subject unchanged, the move, no text) unless they asked for no check-ins.
9. Title and end card. One designed frame each on a text-rendering model with the exact string in the style's palette and type feel; animate the title with a slow push on google/gemini-omni-flash-1.1 (3 to 4 seconds) or place it as an image clip.
10. Assembly. get_assembly_guide once, get_media_metadata on every key, then assemble_video: the shots on the beat grid on the base track (each trimmed to its whole beats, tighter toward the peak, one longer hold before the end, cuts by default and a fade only between scenes), the title and the end card as clips or image clips, the music bed at 0.7 (0.6 with duck: true under a voiceover), the voiceover clips at their moments, output at the delivery aspect. No text clips.
11. Delivery. An honest paragraph: what was made, the arc in a line, which models carried what, what failed and how it was covered, and two next steps (the other aspect ratio, a 15 second cut-down).

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.

View saved version →

---
name: "faceless-explainer"
description: "A finished narrated video in 10 second blocks: a style key image and formula, an asset roster, a script with a through-line, every narration take first on ElevenLabs V4, five hard-cut shots per block on Hailuo 3 Max, assembly by construction, captions from the authored script. Use when: a narrated video with no one on camera that explains, teaches or documents something; an explainer, a faceless channel video, a documentary or history piece, a how-it-works, a listicle, a kids explainer, \"a video that explains X\" over scenes. Not for: a person talking to camera (presenter-video), a story with characters and dialogue (animated-story), a product with hands and a narrator (product-reel), a single clip, a silent montage, edits of existing footage, a trailer with no narration (cinematic-trailer)."
---

# Faceless explainer

Produce ONE finished narrated video. Nobody speaks on camera; the voice is a narrator. The piece is built from fixed 10 second blocks so the audio and the picture sync by construction: one narration line lives inside its own block, and one clip of five shots fills that block.

## Rules that never bend

- Blocks: the duration in seconds divided by ten, whole blocks only (30 seconds is three blocks, a minute is six). Never a block of any other length.
- One narrator voice for the whole piece, every take generated from the approved script before any clip, never paraphrased, sized to its window (7.8 to 9.5 seconds of speech, 20 to 23 words, two sentences at most, numbers as words).
- One style key image and one style formula of 80 to 100 words, both passed or pasted byte-identical into every asset and clip prompt.
- Every recurring subject (a character, a location, a prop) exists as an approved still in the roster before any clip shows it. Characters never talk; the narrator is external.
- Every block is five hard-cut shots of about two seconds, each different in size and angle from its neighbours; no leading freeze; no re-establishing wide of a location already seen.
- No text inside clips. A section title is a designed frame from a text-rendering image model placed as its own shot; captions are the subtitles tool on the master with the authored script.
- Factual topics carry a sources gate: the user's sources, listed in the delivery; nothing asserted that the sources do not carry.
- Faceless means nobody presents on camera, nothing more. Characters the story shows keep their faces; the word faceless never enters a roster, a style key or a clip prompt.

## Intake, only for the gaps

Parse the brief first, then ask in one message only for what it left out: the length (30, 60, 90 seconds; recommend 60), the look (a named style such as paper cut-out, flat vector, clay, watercolour, photoreal documentary, or reference images as style donors), the tone (friendly, authoritative, playful, calm), the aspect (9:16 or 16:9, by destination). Never ask about models or voices by name. Captions and a title are the one delivery question after the master exists.

## Types

- Explainer: one idea the viewer must understand; the blocks move from the question to the answer to what it means for them.
- History: a chronology with dates spoken as words; one map or place still anchors the setting; archive-like restraint in the look.
- Kids: bright palette, one or two characters with big readable expressions, a gentle narrator; declared dialogue blocks may carry one short character line as a voice take instead of narration.
- Picture story: the roster stills and one still per block with slow pushes in the assembler instead of clips; one narration line per block; the cheapest type.
- Myth, fairy tale or storybook with recurring characters: that is the animated-story recipe (the same block engine plus a cast that stays itself and dialogue takes); stop here and read it with get_skill.

## Phases

1. Style key. Write the style formula (medium, line and shape language, palette as five colours, light, texture, camera distance habit, mood; ending in negatives: no photoreal skin unless the look is photoreal, no text, no logos). generate_image one style key on bytedance/seedream-5-pro at 1K from the formula (with the donor images as references when given): a neutral scene in the look, no subject. Look at it inline; get a nod. The formula and the key travel with every prompt from here.
2. Script. One line per block, 20 to 23 words, numbers as words, one idea per block; the arc is hook, build, turn, payoff; the cold open is under eight words and lands in the first two seconds; a through-line object or image appears in every block and resolves in the payoff. Write speech, not prose. Show the script with the block count before any spend.
3. Roster. Name every recurring subject the script needs. generate_image one still each on bytedance/seedream-5-pro with the key passed as a reference and the formula in the prompt: characters full-body at 2:3, each location dressed at the output aspect with a second coverage angle when it carries more than one block, props at 1:1. Show the roster; regenerate a rejected still from the same description. No location carries more than two consecutive blocks.
4. Narration. Describe the voice in one plain sentence (gender, age range, tone, pace, accent, language) and pick a voiceId with list_voices on eleven-labs/v4 (minimax/speech-2.8 only when it fails; say so). One delivery phrase repeated verbatim on every take holds the timbre. generate_voiceover per block with that block's exact text; wait for all; get_media_metadata on each key; a take over 9.5 seconds is rewritten shorter and regenerated, three attempts, never time-stretched. Passing takes are final.
5. Shot manifest. For every block write the five shots with sizes and angles, the references in order (location, then characters, then props, at most seven), the through-line's presence, and check the variety rules before generating anything.
6. Clips. One generate_video per block on minimax/hailuo-3-max in reference mode with resolution "768P" exactly (capitals, the only value it renders; never 480P), duration 10, at most nine references in referenceImageUrls (google/gemini-omni-flash-1.1 in reference mode for the economy version), generateAudio limited to ambience and action sounds. Prompt: the style formula verbatim and the manifest ("image 1 is the style key: take palette, medium and light from it only; image 2 is the location; image 3 is the character; image 4 is the prop"); five shots with times that sum to ten ("Shot 1, 0 to 2 s, wide, low angle: ..." then "Hard cut to."), each naming the subject by its reference, one action, one within-shot motion, the through-line when it appears; no two neighbouring shots share size or angle; a static description of the location; an Audio line: ambience and the sounds of the actions only, no voice, no music; a negative line: no lip movement, no speech, no captions, no text, no logos, no photoreal drift from the key.
7. Check. Tell the user what to check per block unless they asked for no check-ins: five cuts (a block with fewer than four is regenerated once with the cuts spelled out, then accepted), the look held, the subject matching its still, no text, no leading freeze. A moderation refusal is resubmitted, then reworded, then reframed; a block is never dropped.
8. Music. generate_music once on google/lyria-3.5 (instrumental) with a producer's brief: genre, mood, tempo, instrumentation, loop-safe, at least the piece's length. minimax/music-3 when the user wants vocals.
9. Assembly. get_assembly_guide once, get_media_metadata on every key, then assemble_video: block N clip at 10N for 10 seconds on the base track; block N take centred inside its block on an audio track (start = 10N plus half of 10 minus the take's duration); the bed on a second audio track at 0.6 with duck: true; a designed title frame as a 2.5 second first shot only when asked; no text clips, no caption clips.
10. Delivery. Captions through the subtitles tool on zapcap/subtitles when wanted, with referenceTranscript authored from the script: one cue per block split into lines of at most five words, timed from the take's real start inside its block. Then one paragraph: what it is, the blocks in one line each, the sources when there were any, and two next steps (the other aspect, a thumbnail).

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.

View saved version →

---
name: "presenter-video"
description: "A finished vertical video of one person talking to camera about a product or a topic: every line recorded first on ElevenLabs V4, one storyboard sheet per clip through a realism pass, clips on Minimax Hailuo 3 in reference mode that speak the recorded line, a check against the transcript, hard-cut assembly, captions from the subtitles tool. Use when: a person introduces, presents, reviews, pitches, unboxes, tries on or demonstrates something on camera; a presenter, spokesperson, talking head, creator ad, UGC video, \"my avatar says\", \"me explaining\"; also a product alone with hands and a voiceover. Not for: narration over scenes with nobody on camera (faceless-explainer), a product alone with hands and a narrator (product-reel), an avatar or lip-synced portrait driven by an audio file (avatar-video), a cinematic story with several shots (cinematic-trailer), edits of existing footage, voice cloning as the deliverable."
---

# Presenter video

Produce ONE finished 9:16 video in which one person talks to camera. The person is a photo the user supplied or a portrait you generate; every line is recorded first on ElevenLabs V4 and the video model speaks that take, so the words are the script by construction; captions come from the subtitles tool on the finished master. An avatar engine is the exception, used only when the user asks for one by name or a clip fails the transcript check twice.

## Rules that never bend

- One identity for every sheet and clip. Never regenerate the person mid-run.
- Product claims come only from the user's own words, verbatim. With no claims, speak of what is visible. Never invent a number, a result, a review or a price.
- A generated presenter demonstrates and hosts; it never claims to have bought, used or loved the product. Deliver the piece as a demo or a creator concept, never as an organic review.
- Text is never generated into a talking clip and never added by the assembler. Captions are the subtitles tool on the master. The only words inside pixels are a tutorial's step headings on its sheet and a designed title frame when asked.
- Every sheet passes the realism pass; every clip is checked before assembly. A failed clip is re-rendered once with the named fix.
- Consent: a supplied photo is not permission to impersonate its subject. Decline public figures, minors and anyone the user has no right to use. Never imitate a real person's voice.
- Hide the plumbing: display names only, no ids, no phase talk.

## Intake, only for the gaps

Parse the brief first, then ask in one message only for what it left out: the duration (10, 15, 30, 45 seconds; recommend 30), who is on camera (an attached photo, or a generated person with a stated gender and vibe), the product (optional: a photo or a description, never required), the register (natural and engaged recommended; hyped; calm). Never ask about models, aspect ratio, sheets or audio. A brief that carries a duration and a face needs no questions at all. Captions and a title frame are the one delivery question, asked after the master exists.

A one-liner gets the full treatment; a brief with tone or rough flow keeps its direction; a brief with beats or a shot list is mapped one to one.

## Structure by duration

| Total | Clips | Roles |
| --- | --- | --- |
| up to 15 s | 1 | the full arc in one |
| 16 to 19 s | 2 | balanced halves: hook and setup, apply and closer |
| 20 to 30 s | 2 | 15 s hook and setup, the rest apply and closer |
| 31 to 45 s | 3 | hook, main, closer |
| 46 to 60 s | 4 | hook, reveal, apply, closer |
| over 60 s | one per 15 s | the last at least 4 s |

Clips run 10 to 15 seconds; a talking clip carries eight beats, a hands-led clip (unboxing, tutorial, product-only) four. Never one long take.

## Phases

1. Product intake (only with a product). Look at the product photo inline, or read the description, and write a one-paragraph staging contract you reuse verbatim: the object type and form, material and finish, colours, the label state (the exact printed text if legible, otherwise "blank" or "unreadable"), its size next to a hand, how it opens or is used, its weight class (heavy needs two hands and visible strain, light one relaxed hand, tiny pinched near the lens), one honest imperfection that keeps renders from looking like CGI. Lock the angle: the product shows the side the photo shows, never rotated or mirrored. Exactly one product in frame, held fully or resting fully or absent.
2. Creator lock. Source the identity in this order: a photo the user attached (upload it if it is local); otherwise generate one portrait with generate_image on bytedance/seedream-5-pro or google/nano-banana-pro: phone-camera realism, natural light, looking at the lens, the wardrobe and setting the piece needs, a mature adult face, 3:4; then the realism pass (phase 5) on it. Show it and get a nod before spending more. Write the identity line once and carry it verbatim into every prompt's manifest: "image 1 is the person: same face, hair, skin tone and build, same dark crewneck, same warm kitchen light". Address the person only through the reference after that; describing the face in prose beside it makes the model invent a second person.
3. Script. Budget the words before writing: a line rides its clip as a recorded take and must finish with a beat to spare, so 22 to 27 words for a 10 second clip and 32 to 38 for 15 at a conversational pace; when the take runs long, cut words, never the pace. Split the total into one segment per clip. Pick one story shape and one way in (the first word lands during an action already underway; the piece opens mid-sentence; a confession that the creator caved after seeing it everywhere; the product's mechanism already moving). Exactly one turn, the product entering near the middle, the call to action inside the last line. The first word of every segment is content, never "Okay", "So", "Hey guys". Banned anywhere: "literally", "obsessed", "game-changer", "changed my life", "hits different", "you need this", "trust me", "seamless", "effortless". Emotion lives in the words: at most two capitalised words per segment, one peak per clip, never a respelled or stretched word (it breaks the read), no stage pauses or ellipses. Greetings and the product's name belong to clip one; later clips open mid-thought. Show the script before any clip is spent.
4. Storyboard sheets, one per clip, in order. generate_image on google/nano-banana-pro at 2K and 21:9 (openai/gpt-image-2 renders only 1:1, 2:3 and 3:2 on this stack, so it never makes a sheet), with the portrait and the product passed in imageUrls and declared in the manifest; from the second sheet on, also pass the previous sheet. Prompt: a single wide 21:9 image holding exactly eight (four for unboxing, tutorial and product-only) equal vertical 9:16 slots in one row on a white background with thin gutters, no labels, no text. The slots are the beats of the clip in order. For every slot write the camera (arm's-length selfie or locked static), the distance (tight, medium, wide, macro), one action, what each hand does (a selfie has one hand on the phone and one free; two-handed actions are static camera; the idle hand is parked), where the product is (held fully, resting fully, or absent; the reference's visible side) and the expression. The point of view alternates every slot and no two neighbours share both camera and distance; a background shift is the strongest cut. Default cadence for eight: selfie mid, static wide, static macro, selfie tight, static mid, static macro, static wide, selfie tight. Setting, light and wardrobe stay identical across slots. Phone optics: deep focus, digital noise, pore-level skin, one motivated light, no bokeh, no flare, no grade, no mirrors. Exactly one hero product, no clones. Performance: a natural register with small behaviours and ONE human-scale peak that is a body event, never a smile at the camera. Look at each sheet inline and fix a wrong beat before moving on.
5. Realism pass, on every sheet and on the portrait. One image-to-image pass on bytedance/seedream-5-pro with the sheet as the input and this fixed prompt: keep the framing, the slot layout, every face and the product exactly as they are; change only micro-realism: pore-level skin with fine vellus hair, real fabric and material detail, even daylight with a gentle roll-off, faint sensor noise, a flat phone-camera look, deep focus; no waxy or beauty-filter skin, no HDR glow, no teal and orange, no bokeh, no cinematic grade; no face narrowed or reshaped; any step captions stay legible and unchanged. The passed version replaces the raw one everywhere.
6. Takes, one per clip. list_voices once on eleven-labs/v4 and pick one voice that matches the presenter's gender, age and register; hold it for every clip. generate_voiceover per clip on eleven-labs/v4 with the segment exactly as written, a warm conversational read. get_media_metadata on every take: the clip's duration is the take's seconds rounded up plus one, never under 5 or over 15; a take longer than 14 seconds means the segment is cut and recorded again. The take carries the words from here on; nothing downstream may change them.
7. Clips. estimate_cost first (about 1300 credits for a 10 second clip at 2K; reference images beyond five add cost, so never more than three). One generate_video per clip on minimax/hailuo-3 with mode "reference", duration as computed, aspectRatio "9:16", referenceImageUrls holding the portrait first, then the product when there is one, then the passed sheet, and referenceAudioUrls holding that clip's take. Prompt structure: the manifest first ("image 1 is the person: same face, hair, skin tone and build, same clothes and setting in every frame; image 2 is the product, the reference's visible side; image 3 is the storyboard of this clip's beats; audio 1 is the person's voice and the only speech: they say exactly the words in audio 1, lips matching every syllable, starting on the first word and finishing with the last, no other words, no music"); a style and mood line (real phone footage, the light and the place, selfie and static cameras alternating); a one-line summary of the clip in the persona's voice ending in the register; the cuts with times ("Cut 1, 0 to 1.9 s, tight selfie: ..." then "Hard cut to."), slices that sum to the clip length exactly, each with one action, both hands, two or three small behaviours, an expression that evolves, the product's placement, and a camera position that differs from its neighbours; a static description of the place and the subjects; a quality line: consistent face and clothes, no on-screen text, no subtitles, no captions, no watermark, no extra limbs, no mirrored product, handheld micro-shake on selfie cuts and an absolutely static camera on locked cuts. The person faces the lens from the first cut even when the photo looks away; the first word lands at once. One closed-mouth beat per clip, one unguarded moment, at most one sound intrusion. Renders take eight to nine minutes per clip, so launch independent clips together with generate_batch and wait with wait_for_jobs.
8. Check. When each clip finishes, tell the user what to look for: the same face as the reference, two hands at most, exactly one product the right way round, no baked text, lips moving through the words, steady clothes and light, a real cut where the prompt said one. The words are checked by machine: the subtitles tool on zapcap/subtitles transcribes the clip's own audio, and its captions must read as the take. A caption that is not the take means the model re-voiced or drifted: re-render that clip once with the same take and the audio line moved to the top of the prompt; a second mismatch sends the piece to the avatar route. A staging failure means rewriting that beat and re-rendering the clip; never re-render a passing clip. Skip the visual check only when the user asked for no check-ins; the transcript check always runs.
9. Assembly. Call get_assembly_guide once, then get_media_metadata for every clip key, then assemble_video: one video track with the clips hard-cut in order, no music unless asked, no text clips, output 9:16.
10. Captions and delivery. Ask the one delivery question: captions, a title frame, both, or neither, plus a post package. Captions: the subtitles tool on zapcap/subtitles with the master's key, a style from list_caption_styles as preset (a bold highlighted one for social, the default for a clean look), position around 70 so the captions sit low in the frame, the language; no referenceTranscript, because captions must follow what was said and a caption that is not the take is the phase 8 check failing late. A title frame: one 9:16 still on a text-rendering model with the exact string, placed as an image clip over the first 2.5 seconds in a second assembly, never an assembler text clip. Then one paragraph: what was made (length, format, who, what is said in one line) and what to know (the generic copy when no brand name or claims were supplied). Offer three next steps: a version with the brand name worked in, a landscape version, a post package (caption, hashtags, first comment, the sponsorship note) as text. Never expose ids or intermediate assets.

## The presenter model and its limits

Verified through live briefs; follow the evidence unless the user rules otherwise.

- minimax/hailuo-3 in reference mode is the presenter model: the portrait, the product and the sheet in referenceImageUrls, the clip's take in referenceAudioUrls, 4 to 15 seconds, 2K output. Verified twice, once with a generated portrait and once with a real photo: the clip's own transcript matched the take word for word, brand name and number included, and a three-quarter photo turned to camera and held the face, beard, glasses and clothes across the clip. Audio can never be its only reference; reference audio caps at 15 seconds combined; reference images beyond five add cost. There is no draft resolution: one render per clip, priced first.
- bytedance/seedance-2.5 refuses any reference image that shows a realistic person ("may contain likenesses of real people"). The presenter photo was refused and so was a generated sheet; both charges were refunded. Never send a face to it. It stays a B-roll model for shots with nobody in them.
- wan-video/wan-3.0 and kling/o3-video are not presenter models here: Wan 3.0 drifts on faces, and both invent the speech from the prompt, which slurs stretches of a line into non-words. A talking clip is never made with native speech from a prompt; the take is always recorded first.
- minimax/hailuo-3-max caps at 768P; the presenter route uses minimax/hailuo-3 for its 2K output. Its 768P is written exactly so, in capitals, if it is ever used for a silent shot.
- B-roll and cutaways (the product on the counter, hands, the place) are not presenter clips: bytedance/seedance-2.5 for shots with nobody in them and camera work, google/gemini-omni-flash-1.1 for cheap fragments, estimate_cost first; no speech, on the beats the script leaves silent.

## Sub-modes

The brief decides the sub-mode; it changes only the staging, never the phases.

- Talking head (default): the person talks to camera about a product or a topic; the product is optional. Eight beats per sheet.
- Review or demo: an explicit "review it" or "show how it works"; the person demonstrates observable mechanics, exactly one close-up beat placed right after the line that reveals the mechanism, no ownership or result claims.
- Unboxing: four beats per sheet: packed (a sealed package, the product invisible), reveal (the product just out, the peak), product focus (the box gone for good), satisfaction. The product is named only after the reveal; the confession opener is the default.
- Try-on: a wearable; eight beats: pre-wear with a plain bag never opened, wearing with one turn, a front pose, a hand-free texture macro, a turn, a second macro on another detail, a pose in another room, the final look. The item stays on once worn; no mirrors; the two macro beats are silent with the mouth closed.
- Tutorial: numbered steps, four per sheet, numbering continuous across sheets; every step physically real for the product; each slot carries a baked "Step N, heading" caption in one typography (the sheet is generated on google/nano-banana-pro, which renders the caption text, and the realism pass keeps it); the hands do one action per beat; a call to action under a second on the last cut only.
- Product-only: nobody on camera, hands only, a narrator over the clips. That is its own recipe: stop here and read product-reel with get_skill.

## The avatar route, only when asked

When the user asks for an avatar engine by name, supplies their own audio track, needs a read longer than 15 seconds over a static framing, or a clip fails the transcript check twice, the audio drives a dedicated avatar engine instead. That is its own recipe: stop here and read avatar-video with get_skill.

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.

View saved version →

---
name: "product-photoshoot"
description: "Finished product photography in one of ten modes, from a product photo or a description, with one product identity across the set, variants that differ by instruction, the typography three-case rule, and a refinement pass only for defects actually seen. Use when: finished product stills; a packshot, catalog or shop images, lifestyle scenes, a closeup with hands, a Pinterest pin, a hero banner, a social carousel, a static ad set, a product worn or used by a model, a conceptual or CGI-style product image, a restyle of an existing product photo. Not for: a video (product-reel), marketplace listing sets (amazon-listing), a paid ad set with a headline and an offer (ad-creative), a text-led carousel (social-graphics), thumbnails and video covers (thumbnail), portraits of people, a creator on camera with the product (presenter-video)."
---

# Product photoshoot

Produce finished product stills. The product is the hero in every mode. Pick one mode, apply its rules, keep one product identity across the set, and refine only what you or the user can name from the pixels.

## Rules that never bend

- The product's shape, colours, label and proportions survive every image. A drift is a failure to fix, never to present.
- One product in frame unless the mode says otherwise; realistic scale next to hands and props; the reference's visible side, never rotated or mirrored.
- Text follows three cases and only these. The user gave an exact string: write it into the scene as integrated typography on a text-rendering model and check the spelling. The user will add text themselves later: ask for one tonally uniform area that belongs to the scene (sky, a blurred background, a smooth surface), never "empty space", which renders as a flat colour band. The user said nothing about text: say nothing about text either, beyond "no text, no logos, no watermark". Never invented label copy.
- Brand facts come from the user, never assumed.
- A set shares one light, one palette and one surface world; variants differ by an instruction (the preset, the light's direction, the camera angle, the palette), never by paraphrase.

## Intake, typed by what the user gave

Parse the brief and classify it, then ask at most one message, only for the real gaps. A photo and a vague ask: three packshot variants at 1:1, say so, ask nothing. A photo and a named use (a pin, a banner, a shop page): the mode is the use; ask only for the exact text when the use normally carries one. A description only: ask for the product's form, colours and label state when the description leaves them open; the first image becomes the reference for the rest. An existing image to restyle: the restyle mode; ask for the target look only when none was given. A model wearing or using it: the virtual-model mode; ask for the wearer's gender and vibe when unstated. A vague brand ask: three lifestyle variants in the brand's palette. Tie-breakers: platform beats environment (a pin over a lifestyle scene, a banner over a scene, a carousel over a single shot, a named genre over a mood). Counts: 1, 3 or 5. Never ask about models, lenses, lighting terms or resolution.

## Models

google/nano-banana-pro at 2K for every render, the product photo passed in the reference image field (imageUrls) and declared in the prompt; bytedance/seedream-5-pro for every refinement pass (image-to-image on the latest version, never the original); google/nano-banana-pro or black-forest-labs/flux-2-pro for a stage that must render an exact text string (openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here); ideogram-ai/remove-background for a transparent cutout; recraft-ai/recraft-crisp-upscale for print sizes.

## Phases

1. Product intake. Look at the product photo inline (or read the description) and write a one-paragraph staging contract to reuse verbatim: object type and form, material and finish, colours, the label state (the exact printed text if legible, otherwise "blank" or "unreadable"), size next to a hand or a mug, how it opens or is used, the weight class (heavy needs two hands and visible strain, light one relaxed hand, tiny pinched near the lens), one honest imperfection that keeps renders from looking like CGI. Lock the angle.
2. First image. Generate index one of the set with the product photo as the reference (or from the description when there is none). Look at it inline against the contract: shape, label, colours, scale. When the product was described rather than photographed, this image becomes the reference for every other image in the set.
3. The set. Generate the remaining variants with the product reference passed on every call, each changing one named thing per the mode. Append the negatives: no extra product, no duplicate, no look-alike; no warped or invented label text; no stock-photo gloss, no HDR glow, no lens flare; no mixing of styles; no flat colour bands or empty grey zones; no waxy skin on hands; no watermark. Launch them together, then wait for each.
4. Refinement. Look at the set inline. Fix only a defect you can see: pick ONE weakest area per pass, name it, and run an image-to-image pass on bytedance/seedream-5-pro on the latest version with "change only X, keep everything else exactly" and a fix in photographic language (flat light: a key from camera left at 45 degrees and a rim on the far side; a warped label: crisp legible print; plastic skin: visible pores and micro-texture, no sheen; a flat band: extend the real environment into it). At most two refinements and three generations per image. Never name a defect you have not seen.
5. Delivery. The final image per index in order, one sentence naming the mode, the ratio and any correction applied, and one next step (a product video from the strongest still, an upscale for print, a cutout for the shop).

## Modes

- Packshot: seamless white or a soft gradient sweep, front three-quarter angle, soft key from the upper left with a gentle fill, true colours, a faint contact shadow, no props, catalog framing with margin on all sides; variants change the angle and the sweep's tone.
- Lifestyle: the product where it lives, in use or within reach, real daylight with a direction, one or two props that belong, the product sharp and the scene honest, the camera at eye level or slightly above; variants change the room and the hour.
- Closeup with hands: tight on the product held or used by one pair of hands, partial face at most, real skin texture, the product's front visible, the action clear (opening, pouring, applying), two hands at most with correct fingers, the grip matching the weight class.
- Pin: vertical 2:3, one product large, a calm palette drawn from the product, a single prop or surface; a tonally uniform area at the top or bottom only when the user will add their own text.
- Hero banner: 16:9 or wider, the product on one side; the headline integrated when the exact string was given, otherwise a uniform area on the other side only when the user will add one; light and palette from the brand.
- Carousel: 3 to 10 connected square slides that read left to right (the hero, the detail, the use, the context, the range); the same surface and light on every slide; a slide is one idea; slide copy, when given, rendered into each slide on a text-rendering model.
- Ad pack: 3 to 6 coordinated square and vertical variants, each a different hook (problem, mechanism, result, comparison, lifestyle), same product, same palette, exact text only where given.
- Virtual model: the product worn or used by a generated adult, plain and unbranded, the product the sharpest thing in frame, wardrobe and setting from the brief, a realism pass on the model (pore-level skin, no beauty-filter smoothing), no real person's likeness.
- Conceptual: surreal or CGI-style (floating, exploded, splash, sculptural, macro); the product's shape and label exact; one idea per image; a restrained palette so the concept reads at a glance.
- Restyle: the existing product image as the canvas; change the aesthetic (light, palette, surface, mood) and preserve the product, its position and the composition; describe only what changes and say everything else stays.

## Prompt shape

Open with the manifest ("image 1 is the product: same label, same visible side"). Then the subject and what it is doing; the setting; the light (source, direction, softness); the camera (distance, angle, lens feel); surface and material detail; the palette; the mood in two words. Concrete nouns beat adjectives. Then the text case, then the negatives.

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.

View saved version →

---
name: "product-reel"
description: "A finished vertical or square product video with a narrator and nobody on camera: product intake, a four-slot storyboard sheet per clip through the realism pass, silent product clips with native sound, one narrator generated first on ElevenLabs V4, music on a beat grid, hard-cut assembly, captions from the script. Use when: a short product video with no one talking on camera; a product reel, a product ad or commercial, a product showcase, hands using the product with a voiceover, a launch teaser for a physical item, an app or software promo built from its screens. Not for: a person presenting on camera (presenter-video), an avatar reading a script (avatar-video), narration over illustrated scenes (faceless-explainer), product stills (product-photoshoot), listing images (amazon-listing), a cinematic story with characters (cinematic-trailer)."
---

# Product reel

Produce ONE finished product video in which the product is the hero and nobody talks on camera. Hands may appear; a face never does, and no identity is carried. The voice is a narrator over the clips, generated first, so the clips are cut to the words and never the reverse.

## Rules that never bend

- The product's shape, label and visible side survive every frame; the staging contract from intake is reused verbatim in every prompt. Exactly one hero product, no clones.
- Claims come only from the user's own words, verbatim. With none, the narrator describes what is visible: materials, mechanism, packaging, what it does on screen. No numbers, ratings or comparisons the user did not write.
- The narrator is generated from the exact script before any clip; every clip is sized to its take's real duration.
- No text inside product clips. A price, a name or a line of copy is a designed frame from a text-rendering image model placed as its own short shot; captions are the subtitles tool on the master with the script, opt-in.
- Phone-real by default: no studio strobes, no dramatic side light, no shallow depth of field, no golden hour. A cinematic look only when the brief asks for a commercial.
- Hands only, never a face, never a real person's likeness. Hide the plumbing: display names only, no ids, no phase talk.

## Intake, only for the gaps

Parse the brief first, then ask in one message only for what it left out: the product (a photo to upload, a URL, or a description), the duration (10, 15, 30 seconds; recommend 15), the destination and its aspect (9:16 recommended, 1:1 for a feed), whether music is wanted, the register (calm and confident, energetic). Ask only for a missing product and a missing duration. Never ask about models. Captions are the one delivery question after the master exists.

## Structure

One storyboard sheet per clip, four slots each, clips of 10 to 15 seconds; the clip count follows the duration (one clip up to 15 seconds, two up to 30, three up to 45, four up to 60, then one per 15 seconds). The four slots: the product in its native context, not yet in use; demo A, the main action; demo B, a visibly different action, scale, context or target (a mouse glides, then the scroll wheel in macro; perfume mists on the wrist, then droplets on skin; a blender spins, then the pour); the result, distinct from slot one, what the product leaves behind. Hands follow the weight class from intake; a pair is one in each hand or one set down. An app or software product shows a blank device screen in the clips and its real screens as designed frames between them, never a generated interface.

## Phases

1. Product intake. Look at the product photo inline (or read the description) and write a one-paragraph staging contract you reuse verbatim: the object type and form, material and finish, colours, the label state (the exact printed text if legible, otherwise "blank" or "unreadable"), its size next to a hand, how it opens or is used, its weight class (heavy needs two hands and visible strain, light one relaxed hand, tiny pinched near the lens), one honest imperfection that keeps renders from looking like CGI. Lock the angle: the product shows the side the photo shows, never rotated or mirrored. Lock the claims. Derive the narrator's gender and register from the product's coding and lock them.
2. Script. One narration segment per clip, about 2.3 words per second, two sentences at most per 10 seconds, the product named after the intro, the call to action inside the last line. The first word of every segment is content, never "Okay" or "So". Banned anywhere: "literally", "obsessed", "game-changer", "changed my life", "hits different", "you need this", "trust me", "seamless", "effortless". Show the script before any spend.
3. Narration. Describe the voice in one plain sentence (gender, age range, tone, pace, accent, language) and pick a voiceId with list_voices on eleven-labs/v4 (minimax/speech-2.8 only when it fails; say so). One delivery phrase repeated verbatim on every take holds the timbre. generate_voiceover per segment (generate_batch when there are several), wait_for_jobs, then get_media_metadata on every key. A take that overruns its clip by more than a second is rewritten shorter and regenerated, never time-stretched. Passing takes are final.
4. Sheets, one per clip, in order. generate_image on google/nano-banana-pro at 2K and 21:9 (openai/gpt-image-2 renders only 1:1, 2:3 and 3:2 on this stack, so it never makes a sheet), the product passed in imageUrls and declared in the manifest; from the second sheet on, also pass the previous sheet. Prompt: a single wide 21:9 image holding exactly four equal vertical 9:16 slots in one row on a white background with thin gutters, no labels, no text. Manifest first: "image 1 is the product, same label, same visible side; image 2 is the previous sheet". Per slot: the camera (locked static or a slow handheld), the distance, the action, the hands (both named, the weight class respected, safe verbs per material: a glass rests on a palm, a box is held from the sides), the product's placement, the surface and the place. Neighbouring slots never share both distance and camera. Phone aesthetic in every slot: deep focus, natural light with a direction, faint sensor noise, real surfaces, no editorial vocabulary. Then the realism pass: one image-to-image pass on bytedance/seedream-5-pro with the sheet as the input and this fixed prompt: keep the framing, the slot layout and the product exactly as they are; change only micro-realism: real material and fabric detail, even daylight with a gentle roll-off, faint sensor noise, a flat phone-camera look, deep focus, pore-level skin on any hand; no HDR glow, no teal and orange, no bokeh, no cinematic grade. The passed version replaces the raw one. Look at each sheet inline and fix a wrong beat before moving on.
5. Clips. estimate_cost first: on this stack bytedance/seedance-2.5 costs about three and a half times minimax/hailuo-3 per second (a 10 second 9:16 clip is about 4700 credits at 720p against about 1300 at 2K) and tops out at 720p. Take Seedance for a single long take or its camera work; otherwise make the clip on minimax/hailuo-3 in reference mode with the sheet and the product in referenceImageUrls, no reference audio, the same cut list. On Seedance: reference mode with the sheet and the product in imageUrls, native audio on, the aspect, the clip length rounded up to its take; verified: it accepted a sheet with hands in it. Prompt: a style and mood line (phone footage, the light, the place); the four cuts with times that sum to the clip length ("Cut 1, 0 to 3.5 s, static mid: ..." then "Hard cut to."), each with one action, the hands, one within-cut motion and the product's placement; a static description of the place; an Audio line naming room tone and the sounds of the actions only, "no speech, no music"; a quality line: one product, the label as the reference, never rotated or mirrored, no on-screen text, no subtitles, no watermark, no extra hands. Frame one is already mid-action. When Seedance refuses a sheet, fall back to the Hailuo 3 route above. Launch independent clips together with generate_batch and wait with wait_for_jobs.
6. Music, when wanted. generate_music once on google/lyria-3.5 (instrumental) with a producer's brief: genre, mood, a named tempo, instrumentation, loop-safe, at least the piece's length. The tempo is the beat grid.
7. Check. Tell the user what to look for in each clip unless they asked for no check-ins: the same product as the photo, the right side, believable scale, the right hands, no text. Re-render a failed clip once with the named fix; never re-render a passing clip.
8. Assembly. get_assembly_guide once, get_media_metadata on every key, then assemble_video: the clips hard-cut in order on the base track, each sized so its take sits inside it with air on both sides; the narration takes at their moments on an audio track; the bed on a second audio track at 0.6 with duck: true; a designed price or name frame of 2.5 seconds as an image clip only when the brief carries that exact string; no text clips.
9. Delivery. Captions through the subtitles tool on zapcap/subtitles when wanted, with referenceTranscript authored from the script, one cue per segment split into lines of at most five words and timed from the take's real start. Then one paragraph: what was made, what the voice says in one line, and two next steps (a square version, a stills set from the strongest frame).

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.

View saved version →

---
name: "social-graphics"
description: "Static social posts where the words live inside the image: the copy written first, one idea per slide, a cover that hooks and promises the swipe, a save call at the end, every slide rendered with its exact text on a text-rendering model in one locked style, spelling checked. Use when: static social posts with words on them; an Instagram or LinkedIn carousel, quote cards, a story sequence, a text-led announcement post, a tip or listicle post, a sticker pack, a meme with a supplied caption. Not for: a product image set (product-photoshoot), a thumbnail (thumbnail), an ad set with a product and an offer (ad-creative), listing images (amazon-listing), any video."
---

# Social graphics

Produce finished static posts with their text rendered inside the image. Copy first, then one locked style, then one render per slide with the exact words.

## Rules that never bend

- The copy is written and shown before any render; the user's exact words are final; a slide's text is short enough to read on a phone (a headline under eight words, a body under twenty-five).
- One idea per slide. The cover hooks and promises the swipe; the last slide asks for a save, a share or a follow in one line.
- Every slide is rendered on a text-rendering model (google/nano-banana-pro at 2K for 4:5 and 9:16; openai/gpt-image-2 only at 1:1, 2:3 or 3:2; bytedance/seedream-5-pro as the backup) with the exact string quoted in the prompt and its placement named; spelling is checked on every render and a misspelling is re-rendered, never accepted.
- One style sheet (the palette, the type feel, the layout grammar, the image treatment, the logo placement) written once and repeated verbatim on every slide; the logo passed in the reference image field when the brand has one.
- No AI-tell praise in the copy: never "literally", "obsessed", "game-changer", "changed my life", "hits different", "you need this", "trust me", "seamless", "effortless".
- Never a real person's face in a meme or a sticker.

## Intake, only for the gaps

Parse the brief first, then ask in one message only for what it left out: the format (a carousel of N, quote cards, a story sequence, a single post, stickers, a meme), the platform and its aspect (4:5 or 1:1 for a feed, 9:16 for stories), the topic or the supplied lines, the brand palette and logo when there are any. Ask for a missing topic or a missing count. Never ask about models.

## Phases

1. Copy. Write every slide's text: the cover line, one idea per slide, the closing call. Show it; a nod proceeds.
2. Style sheet. Write it in five lines: the palette with hex values, the type feel (a bold grotesque, a serif editorial, a handwritten accent), the layout grammar (text top-left with a wide margin, a full-bleed image with a band), the image treatment (flat illustration, photo with a duotone, plain colour), the logo placement. generate_image slide one on google/nano-banana-pro as the draft at the platform's aspect with the style sheet verbatim, the exact text in quotation marks with its placement, the logo declared when passed; the negatives: no other text, no watermark, no misspelling. Wait, look at it inline, read the text back. The user approves it.
3. Slides. One generate_image per remaining slide in one wave with generate_batch, slide one passed as the reference and declared for style continuity ("image 1 is the style: same palette, type and layout"), the style sheet verbatim, the exact text quoted, the platform's aspect. wait_for_jobs.
4. Check. Look at every slide inline: the spelling of every word, legibility at phone size, the style held. Re-render a failed slide with the same prompt; never accept a misspelling.
5. Delivery. The slides in order with each one's line, an offer of a caption and hashtags as text, and a note on the disclosure when the brief is sponsored.

## Stickers and memes

Stickers: a set of 6 to 12 on a plain white ground, one character or motif in one style, each with its short word when given, 1:1, generated in one wave with the first sticker as the style reference; then remove_background on each (ideogram-ai/remove-background). Memes: the supplied caption rendered in the classic top and bottom bands over the described scene, the exact words quoted, never a real person's face.

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.

View saved version →

---
name: "thumbnail"
description: "Click-worthy thumbnails the way the big channels build them: an information-gap concept from sixteen frameworks, a face locked to a reference, an eleven-block house prompt at 4K, one render per concept, surgical tweaks that change one thing, and text only on an explicit ask. Use when: a YouTube thumbnail, a video cover, a preview image, an Instagram cover, bold viral-style packaging for a video. Not for: the video itself, a product still with no packaging intent (product-photoshoot), a carousel or quote card (social-graphics), an ad with an offer (ad-creative), a poster for print, a logo."
---

# Thumbnail

Produce 1 to 3 finished thumbnails that read at 120 pixels wide. The concept comes first, the face is locked to a reference when there is one, the render is checked, and text appears only when the user asked for it, exactly as given.

## Rules that never bend

- A thumbnail is one idea and one information gap: the viewer must need the video to close it. If it needs a sentence to explain, it fails. It never promises what the video does not show.
- Faces come from the user's reference and stay that person; no reference means a generated adult, never a lookalike of a real one. A reference thumbnail the user shows is read by eye for its framework, palette and layout and never sent to the model.
- No text by default. Text only when the user gave the string, at most four words, rendered in a final pass on a text-rendering model, never over a face.
- Contrast beats detail: one bright subject, one dark ground, one accent colour, nothing small. Subjects fill 40 to 60 percent of the frame.
- One generate_image call per concept on google/nano-banana-pro at 4K; never a count parameter. Three concepts means three frameworks.

## Intake, only for the gaps

Parse the brief: the video's subject and its hook, who is in frame (attached or none), the exact text if any, the platform (YouTube 16:9, Shorts and Reels 9:16, Instagram cover 1:1 or 4:5), the brand palette. Ask in one message only for the hook when the brief has no angle, and for the face when a person is implied but none is given.

## Frameworks, one per concept, brainstorm five before choosing

Before and after; a social post or chat card recreated in the scene; a three-step progression; a real screenshot held or shown; a posed portrait with one emotion; a posed action mid-move; a day or count badge as a physical object; a graphical diagram made physical; a landscape with a tiny subject; a map or aerial with one marker; the object huge and lit like a product; repetition of one object many times; a size difference between two things; a news-clip framing; an amplified-reality exaggeration of something true; a versus split only on an explicit layout ask.

## Models

google/nano-banana-pro at 4K with the face passed in the reference image field (imageUrls) and a logo as a second reference when given; runwayml/gen4-image (referenceImages) when the face must hold across three concepts and drifts; surgical tweaks on bytedance/seedream-5-pro as an image-to-image pass on the render; the text pass on google/nano-banana-pro, black-forest-labs/flux-2-pro or reve/2.1.

## Phases

1. Concept. Write one line per thumbnail: framework, subject, emotion (shock, delight, doubt, disgust, fear, smug, curiosity, pride, exhaustion, anger, deadpan), colour pair, and where any text would sit. Show them; a nod or silence proceeds.
2. Render. One generate_image per concept with the house prompt in eleven ordered blocks, one clause each: the frame (poster grade, one unified frame, no split unless asked); the scene brief in one sentence; the text policy (no text, or the exact string and where); the subjects large, 40 to 60 percent of the frame, with an identity-lock sentence per referenced person ("the person in image 1, same face, hair and skin, no changes to the face"); the key elements (the object, the badge, the screen); logo preservation when a logo is attached ("image 2 is the logo, exact shape and colours"); the location in one line; the composition (one hero on a power third, eyes toward the viewer or the object); the background (a vivid field in the accent colour, a soft vignette, simplified); a named lighting rig on people (a key from the front-left, a soft fill, a rim and hair light in the accent colour); the grade (punchy contrast, saturated, crisp). Then the negatives: no text unless given, no watermark, no extra fingers, no duplicate person.
3. Check. Look at each render inline and describe it in one glance as a viewer would at 120 pixels: if the description needs a second clause, simplify the scene. Verify the identity, no stray text, truthfulness, no extra limbs. Surgical tweaks only, on bytedance/seedream-5-pro: "change ONLY the expression to X, keep everything else pixel-faithful"; allowed scopes are the expression, a background swap, a background recolour, a rim-light recolour. One refinement per concept. Alternate takes when asked: a low-angle hero, an extreme close-up punch-in, a wider tilt; emotions times takes never above sixteen.
4. Text, only when asked. One image-to-image pass on a text-rendering model: the exact string, bold sans, high contrast, placed where the concept reserved space, nothing else changes. Check the spelling inline; a wrong letter is a re-run of this pass only.
5. Delivery. The finals in order with the framework named per thumbnail, one line on which to run first and why, and an offer of a second text variant or an A/B pair.

## Pixara tool mechanics

- Discover: recommend_model for a goal, list_models for a service or a capability, describe_model for the exact parameters, the constraints and the price. The models named in this recipe are the ones verified for it; if one has left the catalog, take the newest model with the same tags.
- Run: generate_image, generate_video, generate_voiceover, generate_music and the editing tools return a job id. wait_for_job(id) polls for up to 45 seconds; call it again until the job finishes. A failed job is refunded and its error names the constraint that was hit; fix that and retry once.
- Waves: when several generations do not depend on each other (a shot list, a set of variants, the takes of a voiceover), queue them in one generate_batch call and wait for all of them with wait_for_jobs; one failing job never stops the others.
- Results: every finished asset carries a URL and a key. Pass the URL as the input to the next generation (describe_model names the image, video and audio fields). Pass the KEY to assemble_video, and call get_media_metadata(key) for exact durations before sizing clips.
- Inputs from the user: request_upload then finalize_upload (or upload_widget) for a local file, upload_asset for a URL, list_generations to reuse earlier work.
- Money: prices are per model in list_models; estimate_cost before anything expensive; confirm before choosing a model that costs several times more than an alternative.
- Seeing: images render inline, so look at every image before building on it. You cannot watch video here: when a clip finishes, tell the user what to check (face, hands, lips, unwanted text) and let them confirm before assembly, unless they asked for no check-ins.
- Words on screen are minimal and live inside the picture: a title, a step name or a price is a designed frame from a text-rendering image model (google/nano-banana-pro at any aspect; openai/gpt-image-2 only at 1:1, 2:3 or 3:2, the only aspects it renders here) with the exact string, animated with image-to-video or placed as an image clip; the assembler's text clip is the last resort for a plain line nothing else can carry. Never ask a generation model to render text you did not receive verbatim from the user.
- Captions never come from the assembler or a video prompt: when a piece has speech and the user wants captions, run the finished master through the subtitles tool on zapcap/subtitles with the language, a style as preset when the user wants a particular look (list_caption_styles shows them with previews; the default is clean plain text), position only when the style's own placement does not fit (a percentage of the height from 0 at the top to 80 at the bottom, around 70 for a 9:16 talking piece), and the authored script as referenceTranscript when one exists: one entry per cue with text, startTime and endTime in seconds, which keeps the script's spelling while word timing still comes from the audio. veed/subtitles is the fallback only: when ZapCap refuses the video (no audio track, longer than 30 minutes), when its job fails (one retry on VEED, never a second ZapCap run), when the captions are authored text on a piece with no speech (VEED burns them from srtContent), or when the user picked a VEED style. Never caption one piece with both. The clean master stays the master; the captioned file is the deliverable.
- minimax/hailuo-3-max: resolution is the string "768P" exactly, capitals, its only value (never 480P, and a lowercase 768p is rejected); duration 5 to 15; referenceImageUrls holds at most nine.
- Voices: eleven-labs/v4 for every voiceover (a voiceId from list_voices); minimax/speech-2.8 only when it fails; bytedance/seed-audio-1.0 for voice replication from a sample the user owns, a two-voice dialogue in one take, or spoken lines with sound effects.
- Talk to the user in model display names, never ids, and never narrate these mechanics.