draft-asset-prompts

Two distinct jobs live under this skill: drafting prompts from a locked concept before generation, and reconciling prompt files against what was actually kept after the user iterated live in the T2I/T2V tool. Figure out which one the user needs — if they mention pasting a generation-tool transcript, selecting/keeping specific images, or say something like "I updated clip X," that's reconciliation, not drafting.

Inside a content-pipeline project: if the project has a project.md (pipeline config — niche, format, budget) and context.md (decision log + glossary), read both first — context.md overrides on conflict. They carry project-level constraints (IP rules, format, asset-hosting conventions) this stage must honor, alongside the concept.txt + style_guide.md you already source from.

Drafting T2I prompts (before generation)

Source the prompt content from concept.txt (per-short: mechanic, narrative beat, setting, asset-slot breakdown) and style_guide.md (per-game: render style, palette + what each color means, camera language, character design, IP-safety constraints). Don't invent details these files don't cover — flag the gap and ask instead.

• One prompt block per asset slot, in the same order as concept.txt's slot list.
• Each shot's palette/UI language must match style_guide.md's meaning rules, not just look plausible — e.g. if a color signals a specific game state, the prompt needs to specify the state, not just the color (see "state-accuracy" below).
• If the game has a real dev project as canon, mirror the terminology and any real UI systems (e.g. BodyStatusUI.cs existing in the real project justified adding a Health HUD to a shot in a past short) rather than inventing new stats/mechanics wholesale.
• Note Gemini's content-policy behavior if the short involves a young/vulnerable-looking human character: even soft age-signaling words ("teen," "adolescent," "kid") can trigger refusals. Carry vulnerability through body language/expression/framing instead, and phrase the character prompt as an adult-coded frame (established precedent: "fragile young man").
• Compose for animatability. A still can look great yet be impossible to animate: if a shot packs many independently-moving components (clashing armies, a crowd, a field of players), the T2V stage won't be able to choreograph them (see "recompose it" under Flow/T2V drafting). Already at keyframe design, prefer a single subject, a telling detail crop, a wide shot where individuals read as texture, or a scene where dust/smoke/fire obscures the churn — don't lock a keyframe you can't move.

Drafting Flow/T2V animation prompts (after images are locked)

These come after t2i_prompts.txt is finalized against real kept images — animate the locked composition, don't redesign it.

Do this first — screen every keyframe for animatability. Before writing any motion, pass over each locked shot and check for multiple independently-moving components; recompose the ones that fail (see "recompose it, don't choreograph it" below) before drafting a single motion prompt. It's cheap to swap a keyframe now and expensive to burn clip generations on a shot that can't animate — so this screen is the first step of T2V drafting, not an afterthought.

• Motion should be small and continuous (drift, flicker, breathing, slow push-in), matched to each shot's dramatic weight — not big new camera moves or added elements.
• Any shot with legible on-screen UI/HUD text needs an explicit "keep this text static, sharp, and unchanged" instruction — generative video is prone to warping on-screen text specifically, more so than T2I is. Opacity is a separate axis from "static/unchanged" — say so explicitly. A "keep static" instruction alone did not prevent a HUD fading out in opacity over the clip's duration in one real case; the model apparently didn't infer that "static" also meant "constant opacity for the full clip." State the full-duration, full-opacity requirement as its own explicit line, don't assume it's implied.
• Map each clip's target duration from the locked script (Hook/Twist/Trap timing), so nothing needs re-cutting after generation.
• If a shot is built to loop (e.g. an "idle" shot holding a full script beat alone), say so explicitly and ask for continuous motion with no readable start/end point.
• Flag the known fallback up front rather than waiting for a failure: if a tool can't keep HUD text stable no matter how the prompt is phrased, the fix is animating a HUD-stripped background/character and compositing the static text back on top in the video pipeline (the same way captions get burned in), not endless prompt iteration.
• Check whether the pipeline keeps or strips each clip's native generated audio (e.g. check stitch for audio=False vs. audio-preserving code) before telling the user whether to worry about ambient sound/VFX audio the animation tool bakes in. Don't assume either way without checking — one real pipeline started by stripping clip audio and building the soundtrack entirely from narration/music/a hand-timed SFX manifest, then switched to keeping native clip audio by default after a direct listen-test comparison showed it sounded better and made the manifest redundant (see below).

Google Flow specifics (as of this skill's writing — verify against the actual current UI before asserting anything, since generative-video tool UIs change fast)

• Frames vs. Ingredients input mode: use Frames (single start image) for animating an already-locked, fully-composed shot. Ingredients is for combining multiple separate reference images into a new composition — wrong mode once the shot is already locked.
• End frame: leave blank for ordinary subtle-motion shots. Three legitimate uses for setting it: (a) a shot that needs to loop seamlessly (same image as start and end frame helps it return to the same state), (b) as a fallback if on-screen text keeps drifting despite the prompt instruction — a matching end frame is an explicit image-based constraint, stronger than a text instruction alone, and (c) deliberate state-to-state interpolation, when the user has two separately-generated T2I images of the same locked composition representing a before/after value of the same stat/UI element (e.g. a stat readout at a high value vs. the same readout at a low/broken value) — set the "before" image as start frame and the "after" as end frame, then describe the transition explicitly in the prompt (what visually changes, in what order, over what portion of the duration) rather than leaving it to the model to invent how the interpolation should look.
• Aspect ratio/resolution: set portrait/9:16 at generation time to match the pipeline's target export dimensions directly, rather than relying on a center-crop step to fix a mismatched source. Download the highest resolution available (even above the pipeline's target) — downscaling is clean, upscaling from below-target resolution blurs fine detail, which is worst-case on any shot with on-screen text.
• Per-generation duration cap: check what the tool's actual max single-generation length is (observed as ~8s in one case) before designing a multi-beat directional arc — a script beat longer than that cap can't be one generation. If it's longer, split the arc into two (or more) separate generations at a natural beat boundary, and use a still frame extracted from the end of the first generation as the start image for the next one (Frames mode) — this preserves visual continuity across the cut instead of jump-cutting between two independently-generated poses/framings. Concatenate the pieces into a single output file before it enters the rest of the build pipeline, so the pipeline itself only ever sees one file per clip slot and doesn't need to know the split happened.
• Model/quality tier selection: don't assert specific current model names/tiers/behaviors from training data — ask the user what's listed in their UI right now. As a general decision framework: bias toward the highest-quality tier for shots carrying on-screen text or other high-stakes locked detail; cheaper/faster tiers are more reasonable for simple atmosphere shots with no text and lower failure cost. Mixing tiers across a short's clips has a real tradeoff (cost savings vs. potentially visible inconsistency in motion quality between clips) — worth naming explicitly rather than picking silently. If a HUD-heavy or dramatically-specific clip keeps failing after 2-3 rounds of prompt fixes on a low/cheap tier, suggest trying a higher tier with the same (already-fixed) prompt before continuing to iterate on wording — one real case needed zero further prompt changes once the tier went up, meaning the failure was a model-capability ceiling, not a prompt-clarity problem. Don't burn many rounds re-wording a prompt that's already specific and correct.

Per-clip duration manifests

If the build pipeline supports it (check for a clip_durations.txt-style convention, or propose adding one), don't let a script's differentiated Hook/Twist/Trap timing silently degrade into an even split across clips — verify the actual stitching code respects per-clip durations, not just total duration.

A hand-timed SFX manifest (clip filename + SFX filename + offset) is a real option, but check whether it's actually needed before building one. It used to be the default approach for one pipeline (keep clip audio stripped, layer specific SFX in post, timed to each clip's start position from a clip_timings.json-style file) — but once that pipeline switched to keeping each clip's own native generated audio, the manifest became redundant work duplicating sound the clip already had, and was removed. Only reach for a manifest approach if the pipeline strips clip audio, or if native clip audio turns out unreliable/inconsistent enough (per-clip volume swings, missing sound on some clips) that manual control is worth the extra bookkeeping.

Vague motion instructions ("shift slightly," "subtle movement") let the model default to whatever's statistically common, which may be dramatically wrong for the scene. A generic instruction for creatures near a character produced them retreating/turning away instead of threatening, and a character meant to be frozen in fear read as merely calm/idle. If a shot has emotional/dramatic stakes (predator vs. prey, fear, tension), describe the specific body language that sells that state (crouched/ready-to-pounce, weight forward not back, trembling, braced posture) rather than a generic "subtle motion" instruction and hoping the model infers the right emotional read. Same applies to unwanted elements appearing (e.g. a stray text element popping up mid-clip that wasn't in the source image) — explicitly state that nothing beyond what's in the source image may appear, not just that the known HUD elements should stay static.

Even mundane ambient words can trigger unwanted literal side-effects, not just dramatic VFX terms. "Gentle breathing" (meant as a small life-sign cue for an otherwise-frozen character) produced a large, distracting breath-fog/mist effect covering much of the frame. Any word that names a natural phenomenon with a common visual signature (breathing -> fog, fire -> smoke, rain -> puddles) risks the model adding that signature even if it wasn't wanted or the scene doesn't call for it (e.g. no visible cold-breath cue was intended here). Describe the underlying physical motion mechanically ("small rise and fall of the chest") instead of the naturalistic label, and negate the likely unwanted side-effect explicitly.

A shot with multiple similar creatures/characters can spawn or split extras mid-clip even when the prompt never asked for new content. A source image locked at exactly 3 beasts generated a clip that grew to 4 beasts by ~1.5s and 5 by ~2.5s, with review showing one beast appearing to split into two distinct shapes rather than a clean new entrant. Catch this by sampling frames across the clip's duration (not just first/last frame) and counting each recurring element, not just eyeballing the whole clip once. If the shot has more than one of the same creature/prop, state the exact count explicitly and forbid spawning/splitting/duplicating as its own explicit instruction, the same way HUD-persistence and no-new-text got their own explicit lines — don't assume "keep it matching the source image" alone covers count stability.

A keyframe packed with many independently-moving components (clashing armies, a crowd, players on a field, a stampeding herd) is a losing battle for T2V — don't choreograph it, recompose it. Before writing motion for any shot, check whether the frame has multiple subjects that would each need their own coherent movement. Generative video can't reliably direct many independent agents at once — it morphs, merges, spawns, and desyncs them (the count-stability failure above, at scale). Instead of micromanaging each one in the prompt, flag it to the user before generating and prefer a composition that sidesteps the problem:

• Narrow to one subject. Close up on a single soldier's face, one clashing pair, one player — let the individual carry the scene the mass was meant to convey.
• Crop to a telling detail. Horse legs churning mud, boots pounding the field, a hand white-knuckling a hilt — small, controllable motion that implies the larger action.
• If scale itself is the point, zoom out far enough that individuals stop mattering. From distant/high framing the mass reads as texture and silhouette, not trackable agents, so per-unit incoherence becomes invisible.
• Or bury the churn in atmosphere. Dust, smoke, fire, fog, motion blur — let the eye read chaos and energy while the model animates the haze, not fifty coherent bodies. Fix this at keyframe/composition time by picking the alternative shot, not by fighting it in the animation prompt — a frame designed to be un-animatable won't be rescued by wording.

When prompting a specific VFX (gunfire, explosions, magic, etc.), name the failure mode explicitly, don't just name the effect. A term like "muzzle flash" can be ambiguous enough that a T2V model generates something else in the same rough category (e.g. it produced a bomb-smoke explosion instead of a quick gunshot flash) — describe the effect's concrete physical properties (duration, size, color, whether anything lingers/expands) and explicitly negate the likely wrong interpretation ("NOT an explosion, NOT smoke, NOT a lingering burst") rather than assuming the model will infer the distinction from the label alone.

A user can ask for new content to be added directly at the animation stage rather than regenerating the source T2I image (e.g. adding a threatening creature to a shot after the static image is already locked) — this is a legitimate shortcut when it's cheaper/faster than a full T2I regeneration, but it means the final video's first frame will show more than the static source image does. Document this divergence explicitly in the T2I prompt file's history note for that clip (not just the animation prompt file) — otherwise a future reader comparing the static image against the finished video will think something's wrong, when it was actually a deliberate choice.

VFX (visual) vs. SFX (audio) is a real split, not the same decision -- but if the pipeline keeps clip-native audio, the T2V tool's own generated sound may already cover it. If the user wants something like gunfire, an explosion, or a flash that's meant to be seen, that's VFX and belongs in the Flow/T2V prompt itself regardless. Whether the sound needs separate handling depends on the pipeline: if clip audio gets stripped, it goes through a post-production SFX manifest (offsets are placeholder guesses until the real clip exists — flag that they need re-syncing to the actual footage's real flash/action timing before final render); if clip-native audio is kept, check what the generated clip's own audio sounds like first, since Flow/Veo often generates plausible matching sound (a gunfire flash tends to come with a bang) and a separate manifest on top would just double up.

Reconciling prompt files against actual kept generations

This is the harder, more error-prone half — live iteration in a T2I/T2V tool routinely diverges from the original locked prompt, and silently "fixing" the prompt file to match what was planned instead of what was kept creates a false record.

• Ask per-clip, don't assume. Confirm which image/clip the user is actually keeping before touching any prompt text — a design decision (e.g. a palette rule) can change mid-session, and different clips may or may not have picked up that change.
• Look at the actual image, not just the user's description of it. Read the file and check it against the prompt's intent directly — this catches problems the user's own summary might miss (a past case: a "trust breakdown" shot's kept image showed a high, healthy trust percentage, which the user hadn't flagged until asked to look again).
• Check state-accuracy, not just style-accuracy. A generated image can nail the art style/palette while still contradicting the narrative beat it's supposed to sell (e.g. a UI readout showing the opposite of the mechanic state the shot exists to demonstrate) — verify what any on-screen numbers/labels actually say against what the beat requires.
• When a generation reveals a real design decision (not just an accepted rendering quirk), check whether it should propagate to style_guide.md/design.md and, if a real dev project is canon for the game, whether it belongs there too — don't let a locked-file rule silently go stale relative to what's actually being produced. Confirm with the user before reversing an established rule (e.g. a signal-color convention); a prompt bug isn't the same as a considered design pivot.
• Record the iteration history in the prompt file itself, not just in conversation — a short NOTE (history): v1 ... v2 ... block per clip that changed, explaining what was wrong and what fixed it. This is cheap and makes the file self-documenting for the next session, which starts with zero memory of the live back-and-forth.
• Shot-slot numbering should equal final playback order. If the locked script needs a different clip order than the shots were originally numbered in, renumber the shot files/prompt entries directly rather than introducing a separate ordering/manifest mechanism — most build pipelines assume filename order is playback order, and matching that keeps the pipeline simple. Renumbering means updating the shot's identity everywhere it's referenced (concept.txt, t2i_prompts.txt, flow_prompts.txt, script.txt) — do all of them in the same pass, don't leave a stale reference.