wan2.7-image-standard Prompt Recipes: Copy-Paste Prompts for Layout and Text Rendering

How to use these prompt recipes

Every recipe in this guide follows the same shape: a short role line, a set of labeled slots, and a fixed tail that locks style and rendering behavior. You fill the slots, leave the scaffolding alone, and you get output that is comparable from run to run.

The template looks like this:

[subject] | [layout spec] | [text block] | [style tail]

Each pipe-separated segment answers one question. The subject names what is in the image. The layout spec says where things sit. The text block carries any copy that must be baked in. The style tail fixes the rendering look so it does not drift between runs.

When you adapt a recipe, change slot contents, not slot structure. If your subject needs three card blocks instead of two, edit the layout spec — do not delete the layout segment. Keeping the frame intact is what makes the recipe reusable and what makes failures debuggable: when something breaks, you know which segment to blame.

A workable loop is to copy the recipe, fill in your own content, generate, and compare against the previous run before changing anything else. If you rewrite two slots at once you lose the ability to tell which edit fixed or broke the render.

Recipe: controlling layout and composition

Layout is the most controllable part of a prompt, and the part most people leave vague. Vague layout language produces vague composition.

Recipe: the pinned grid

[subject] | centered subject inside a 3-column grid, equal gutters, elements aligned to grid lines, generous outer margins, no overlapping shapes | [text block] | flat vector style, high contrast, clean edges

The phrase 3-column grid, equal gutters does most of the work. It converts a compositional wish into a countable constraint. Replace the column count with whatever your layout needs — 2-column, 4-column, single centered column.

Hierarchy and whitespace

Hierarchy means the prompt states relative sizes explicitly:

[subject] | one dominant headline block occupying the upper third, two smaller supporting blocks beneath it, at least 30% of the canvas left empty

Whitespace requests are worth including verbatim. Without an explicit empty-space instruction, outputs tend to fill the frame. Treat left empty and spacious as different tools: the first is a constraint, the second is a mood.

What predictably fails

• Stacking many positional clauses in one run (top-left AND bottom-right AND centered) causes the model to compromise on all of them.
• Mixing layout language with style language in the same segment muddles both.
• Element names that imply each other (icon grid containing icons) add no information.

Keep the layout segment pure geometry. Style lives in the tail.

Recipe: getting text to render legibly

Baked-in text is the highest-variance part of image generation. The reliable levers are length, quoting, and placement — in that order.

Recipe: short quoted text

[subject] | headline area in the upper center, one line of text only | headline text: "Ship Faster" | clean sans-serif, solid fill, high contrast against background

The text content goes in double quotes and nowhere else. Quote marks signal "render this literally" far more consistently than describing the text in prose. Keep the quoted string to a few words; long sentences degrade into approximate letterforms.

Placement cues that help

Put the text region in the layout segment and the text itself in the text segment. This separation lets you move a headline without rewording it, which is a common iteration pair.

Useful placement phrasing:

• headline area in the upper third
• label beneath the main block
• single centered line, no wrapping

The phrase no wrapping is a genuine constraint and prevents the model from breaking a short phrase across two lines.

Length and wording discipline

Constraint the character count in your own head before writing the prompt. If a phrase will not fit on one visual line at your layout's scale, shorten it rather than asking the model to shrink it. Remove punctuation before removing words — stray commas and apostrophes are frequent sources of artifacts.

If text renders garbled, first shorten it, then simplify the style descriptor, then move the placement cue. Change only one of those per run.

Recipe: structured cards and panels

Multi-block layouts are where recipes pay off most, because repetition is what the prompt needs to describe precisely.

Recipe: repeated card row

[subject] | a row of 3 identical cards, equal width, equal spacing between cards, consistent inner padding on all four sides, card content top-aligned within each card, unified outer margin | [text block] | flat vector style, subtle border, high contrast

The load-bearing phrases are identical, equal width, equal spacing, and consistent inner padding. Each is a measurable property. The word identical matters more than the count: models will happily produce three differently sized cards unless told they must match.

Alignment axes

State which edge content aligns to. top-aligned within each card and left-aligned text with a single leading edge are both effective. Naming one alignment axis per block prevents the drift you see when content floats in each card independently.

Scaling the recipe

To move from a row to a grid, change the geometry only:

a 2x2 grid of 4 identical panels, equal gutters horizontally and vertically, consistent inner padding

To reduce density, cut the block count instead of shrinking the padding. Fewer, well-padded blocks render more cleanly than many cramped ones.

A common failure mode is asking for different content in each card while also requesting identical structure. If the cards must differ in content but match in shape, say exactly that: identical card dimensions and spacing, varying text content per card.

Parameter and iteration tips

Prompt work is debugging work. The discipline that matters is single-variable iteration.

Change one thing

Write down the current prompt, make exactly one edit, generate, and compare. If the change helped, keep it and record it. If it did not, revert fully rather than layering a compensating phrase on top. Compensating phrases accumulate into prompts nobody can reason about.

Keep runs comparable

Hold your parameters fixed while iterating on prompt text. If you adjust layout phrasing and generation settings in the same pass, you cannot attribute the result. Pick a seed or setting baseline, vary prompts against it, and only then tune parameters against your winning prompt.

Reword, don't pile on

When a segment fails twice, reword it instead of adding qualifiers. centered failing becomes aligned to the horizontal center line, not centered, truly centered, make sure it is centered. Repetition of the same word reads as noise.

Log what you tried

Keep a short changelog per recipe: the edit made, the run identifier, and one line on the outcome. This is the difference between iterating and wandering. After a handful of runs you will see which slot is actually sensitive — usually it is layout or text, not the style tail.

Finally, resist the urge to tune style before structure works. Get the geometry and text right on a plain style tail, then refine the look.

Recipes with real generated outputs

Here the recipes are run end to end so you can judge results rather than take the advice on faith. Each entry below shows the prompt as submitted and the generated output alongside it.

Run 1: pinned grid with a quoted headline

announcement graphic | centered subject inside a 3-column grid, equal gutters, elements aligned to grid lines, generous outer margins | headline text: "Ship Faster" | flat vector style, high contrast, clean edges

What to look at: whether the headline sits on a single line, whether the gutters actually read as equal, and whether the outer margin survives. Compare the margin against the recipe's stated intent — generous is the first thing to erode across runs.

Run 2: three-card row

feature overview | a row of 3 identical cards, equal width, equal spacing between cards, consistent inner padding, card content top-aligned | feature labels: "Build", "Ship", "Measure" | flat vector style, subtle border

What to look at: card width consistency and whether the three labels share a baseline. Short single-word labels are the most forgiving case; this run establishes the ceiling before you attempt longer copy.

Run 3: hierarchy with whitespace

section header | one dominant headline block in the upper third, one smaller supporting block beneath, at least 30% of canvas left empty | headline text: "Release Notes" | minimal flat style

What to look at: whether the empty region is contiguous or scattered. Scattered whitespace means the layout instruction was understood loosely, and is your cue to restate the empty region as a single named area.

Each output is the reference point for its recipe, not a guarantee. When your filled-in version underperforms the reference, the difference is usually in the slot you changed — go back and compare that segment word for word.

Turning recipes into a repeatable workflow

A recipe that lives in a chat window is not an asset. To get value repeatedly, store recipes where your team can find, compare, and version them.

Store recipes as files

Keep each recipe as a small structured file with slots separated from the fixed frame, plus a note on what the recipe is for and which outputs it produced. Slot-separated storage means content updates never touch the frame, which is exactly the invariant these recipes depend on.

Version the frame, not just the content

When you change the fixed tail — style wording, rendering descriptors — record it. Frame changes affect every future use of the recipe, so they deserve a version bump and a one-line rationale.

Attach outputs to versions

Keep a reference output next to each version. Reviewers and future contributors can then see expected quality without re-running everything. This is the same principle as the runs above: output beside prompt, always.

Route through one interface

Run every recipe through the same API surface so generation settings, logging, and identifiers stay uniform. If different recipes go through different tooling, comparisons stop meaning anything within a week. In practice that means keeping prompt submission centralized rather than distributing ad hoc scripts across machines.

Start with one or two recipes you actually reuse, wire them into your pipeline through a single interface, and let the collection grow only as real needs appear. A small, well-versioned recipe set beats a sprawling prompt library nobody trusts.