AI-KSK/minimax-h3-image-prompts

H3 Image Prompts

Write executable visual descriptions for MiniMax-H3-Image. Based on the MiniMax-H3-Image User Manual, serve text-to-image and image editing modes; do not split out new workflows for outfit change, pose change, etc.

Execution Order

1. Determine mode: No reference assets → text-to-image; images present with requests to modify, combine, or borrow content → image editing. If reference images are mentioned but not actually visible, write according to the user's stated purpose, do not pretend to see details in the image.
2. Extract hard requirements: purpose, number and identity of subjects, action, composition, dimensions, text, style, and what must not change. User corrections later override previous plans.
3. When multiple images exist, establish numbering and role assignments: Confirm the actual upload order, then map purposes as <Picture 1> through <Picture 16>. If needed, first give a brief "Image Number / Purpose / Retention Scope" table; when the user only wants the prompt, embed the mapping into the main text.
4. Write according to the two modes below; detail priority order: user hard requirements → reference image ownership → overall layout → local visual details → style embellishments.
5. Perform a final self-check, then deliver a prompt that can be pasted directly. Only output multiple versions when the user explicitly requests multiple plans.

By default, only write prompts; do not automatically generate images, modify workflows, or settings. When the user explicitly requests image generation, execute according to the chosen tool, and do not claim that the tool necessarily uses H3.

Common Writing Conventions

• Task first, style second: First state what to do, where to use it, the subject and its action, then the visual language.
• Whole first, parts later: First determine frame, number of subjects, positions, viewpoint, partitions and negative space, then write about clothing, objects, materials, etc.
• Use visible colors, light source direction, materials, textures, edges, perspective, and depth of field instead of vague terms like "high-end", "cinematic", "hyper-real". A few style names can be kept, but supplement with observable evidence.
• Do not impose a uniform "cinematic feel". When the user wants phone snapshots, MiniDV, pixel art, line drawings, match the corresponding information density, imaging artifacts, and medium; do not add conflicting film, HDR, CG, or sharpening requirements.
• Only add non-critical details necessary to complete the intent; do not autonomously change faces, people, add characters, add text, add brands, or alter composition. Areas the user explicitly allows the model to free-design can be crafted.
• Place key content early; remove repeated embellishments and contradictory constraints. Do not pad to the limit just to make prompts long; the 4096 token truncation mentioned in the official manual is a platform specification—do not treat 32000 characters as a guaranteed complete length.
• Chinese defaults to natural Chinese; give English only when the user requests it, or when the user explicitly disables local expansion and needs direct English output. When translating descriptions, preserve the Chinese characters, punctuation, case, and proper nouns that should actually appear in the image.
• Prohibit using Stable Diffusion weight tags, LoRA loading statements, or unconfirmed H3-specific syntax. Do not default to appending separate negative prompts; write necessary exclusions as clear constraints in the main text.

Mode 1: Text-to-Image

Use the order:

Task/Purpose → Frame & Layout → Subject & Action → Environment & Spatial Relationships → Light, Color, Material & Medium → Text or No-Text Requirement → Necessary Exclusions.

Write only constraints that still hold. For example, "full body" requires space for head and feet; a close-up portrait should not simultaneously require full body and feet. The subject's orientation, camera orientation, and left-right relationships must be jointly feasible.

• Realistic portraits: describe real skin, natural expressions, fabric, hair, ambient light, and believable depth of field; do not use "absolutely no AI look" as a substitute for specific descriptions or effect guarantees.
• Game/mechanical/product concepts: fix part counts, structural proportions, view correspondence, and materials; if no real dimensions are given, do not fabricate measurements, mark fabricated designs as conceptual.
• Posters/covers: first determine visual focus and text area. When the user wants a title, give the text and hierarchy character by character; when the user wants to typeset later, only leave space, do not let the model automatically generate placeholder characters.
• Grid/multi-view: write "2 rows x 3 columns (rows x columns)" and describe each cell; all views of the same object must maintain consistent identity, structure, clothing, and proportions.

Mode 2: Image Editing

Use the order:

Which image to edit → What each reference image provides → Modification target and location → Change operation and final state → Items to retain and their scope → Output composition/frame → Style matching and necessary exclusions.

Reference Image Role Assignment

• Number according to actual upload order, up to a maximum of 16. Empty boxes that are not enabled do not constitute reference images, nor are missing assets fabricated. The reference image count is an upper limit; do not ask the user to fill all 16 frames.
• Every image reference in the final pastable prompt must strictly use the literal tags <Picture 1>, <Picture 2>, etc. (including angle brackets, space, and number); keep these tags even if the entire text is in Chinese. Do not rewrite them as "图1", "图片一", or "Picture 1" without angle brackets in the prompt. Chinese explanations outside the prompt can use "图片1".
• If there is a base image (background image), specify its number; typically it is <Picture 1>, but if the user specifies another image as the base, obey and do not always treat the first image as the person image.
• Indicate exactly what each image provides: identity, clothing, pose, object, color, material, layout, or style. When borrowing color, clarify that shape, material, and person are not borrowed; when borrowing pose, do not copy the face and clothes of the person in the pose image.
• Local similarity goals should target observable features, such as facial structure, hairstyle, identity, clothing tailoring, texture, and accessories; do not guarantee 100% character consistency in advance.
• When there are gaps in numbering, verify against the actual order of images sent to the model. If encountering a 16-frame workflow requiring continuous input, remind the user to fill images 01 continuously; if necessary, explain renumbering correspondence, and do not autonomously change an already confirmed mapping.
• If more than 16 images exist, first ask the user to specify which 16 to keep or how to split into rounds; do not silently truncate. When splitting into rounds, explicitly state which existing images and reference images are used in each round.

Changes and Retention

• Color change: Specify the part, new color, and boundaries; retain shape, material, texture, size, position, and illumination that should remain unchanged.
• Move: Only move the original object, state the new location, proportion, occlusion, and contact relationship, and fill the old location; do not generate a second copy.
• Duplicate: Retain the original object, indicate the number of new copies and each location.
• Replace: The old object disappears; the new object occupies the specified location, matching perspective, scale, occlusion, contact shadows, and ambient light.
• Delete: Clearly state which object to delete; describe what continuous background, ground, or texture should fill the original area.
• Outfit/pose/background change: List the scope of change, then lock what still needs to be retained (person and other image information). When pose, viewpoint, or frame changes, do not simultaneously require absolute invariance of body position, entire composition, and all pixels.
• Local text/data modification: Provide the complete replacement content, location, font size hierarchy, and retention scope; do not leave the original text truncated into fragments for the model to guess.
• Multi-round editing should clearly state "Using this round's Image N as base, modify what, continue to retain what" in each round. Do not use references like "as before", "same as last time" that cannot be executed out of context.

Text, Knowledge & Grid

• Place the complete text to be displayed character by character within quotation marks, specifying location, size relationship, and line breaks. When translating outer prompt language, do not translate the text that needs to be rendered.
• When no text is needed, write "No text, letters, or numbers are added to the image"; when the user requires retaining packaging or background text, write "Do not add new text, existing text remains", and do not conflict with retention items.
• All numbers, units, object mappings, time ranges, and panel annotations must come from user-provided materials or verified sources. First verify calculations and logic before asking the model to draw; do not rely on the image model for fact-checking.
• When data is insufficient, do not fabricate paper results, statistical significance, error bars, dimensions, or experimental groups; provide a templated placeholder and indicate what is missing. When the user allows example data, mark it as example/synthetic.
• When modifying a single cell in a grid, use precise addresses like "Row 2, Column 1" and lock the remaining cells. Do not use a layout that only says "2×3" without row and column specification.

Dimensions & Deployment Boundaries

• If the user provides dimensions, use them; if only a purpose is given, make a reasonable frame selection and explain the assumption in one sentence if needed. Do not repeatedly ask when there is no single correct parameter.
• Specifying aspect ratio in the prompt cannot replace the actual width and height in the workflow/API; only give separate setting suggestions when the user needs to manipulate parameters.
• Respect the user's existing workflow. If the editing pipeline already includes 4MP scaling, 32-multiple alignment, etc., do not arbitrarily modify when writing prompts, and do not add extra scaling, cropping, or preprocessing; when the actual pipeline is not confirmed, do not assume these nodes necessarily exist.
• Distinguish between official platform/API parameters in the manual and local implementations. In particular, "image editing forced expansion, 1-10 images per batch, upload format and size limits" must not be claimed as inevitable constraints of local ComfyUI. The local environment is determined by actual nodes and configuration.
• Do not actively switch INT8/BF16, samplers, steps, CFG, model precision, or VRAM mode just because you are writing a prompt. Do not guarantee that "6 steps" means a fixed number of seconds on any hardware.

Output Convention

Default output: an optional one-line reference image role assignment, then a plain text code block containing the complete prompt. When the user says "only give the prompt", give only the code block, without titles, explanations, parameter tables, or self-check reports. When the user requests JSON, three-part subject_definitions, or bilingual Chinese/English, follow the specified format; do not declare these formats as the manual's only requirement.

Editing prompts should directly give the complete executable version for the current round, not just fragmented patches that need to be inserted. Only briefly ask when missing information would change subject identity, image mapping, accurate text, or data; for general composition and style details, use reasonable defaults and continue.

Pre-Delivery Self-Check

• Is the mode correct, fulfilling the purpose of this round, not forcing a fixed scenario?
• Are reference images within the 1-16 range, in correct order, with clear purpose and retention scope for each?
• Does the final prompt use the complete <Picture n> tag for all image references, without degenerating to "图1" or "Picture 1"?
• Are change operations clear, and has deletion/movement been explained with original location filling?
• Is there no contradiction between frame change, pose change, and "remain unchanged"?
• Are user-given text, punctuation, line breaks, units, and data precisely retained, without autonomous fabrication?
• Are grid rows/columns and lens/view counts consistent, with no conflict in subject and structure counts?
• Have useless modifiers, unfilled placeholders, unconfirmed model syntax, and effect guarantees been removed?
• Was only the prompt the user requested delivered, without automatic image generation, workflow modification, or added preprocessing?

On-Demand Reading

• Manual Rules & Platform Boundaries: Check source, manual page numbers, parameter nature, and export completeness.
• Prompt Templates & Examples: Read when needing complete generation templates, editing templates, color references, three-image outfit/pose change, deletion/completion, or cell-specific modification. Rewrite for the current task; do not reuse identity, scene, or style from examples that the user did not request.