Clauses, sub-sections, and nothing left to interpretation. Your prompt can work the same way.
Capitalised rules, MUST constraints, labelled sections and JSON character sheets
Your prompt is probably a wall of commas. That format made sense when the text encoder could only see 77 tokens and every word had to fight for space. On current models it is the single biggest thing standing between you and a character who looks the same in two consecutive images.
Here is a test you can run in the next two minutes. Generate the same character twice, in two different poses, using your usual comma-separated prompt. Then look at the fingernails, the earrings, and the exact shade of the jacket. They will not match. They almost never do, and for a long time the accepted answer was that this is simply what these tools are like.
It is not what they are like anymore. The models got better at reading structure, and most people's prompting never updated to take advantage of it. Max Woolf, who writes at minimaxir, documented a set of experiments on Google's Nano Banana image models that make the point uncomfortably clear: the same request, rewritten as a structured document instead of a sentence, holds its details.
Start with the smallest change, because it is the one nobody believes until they try it. Writing a rule in capitals makes the model follow it more reliably. Not "please keep the hair red" but a line that reads as an instruction with weight behind it.
Woolf pushes this further with explicit constraint words. Prefixing a requirement with MUST, or the stronger MUST EXACTLY, measurably tightens compliance. His example is a line telling the model that all of the kittens MUST follow the given descriptions EXACTLY, and the difference in output is not subtle.
This feels like superstition. It is not. These models were trained on enormous quantities of technical documentation, specifications, legal text and code comments, and in all of that material capitalisation and words like MUST carry real semantic weight. RFC documents use MUST as a defined term. You are not shouting at the model. You are writing in a register it has seen used for binding requirements ten million times.
The second change is structural. When you want several distinct things done, write them as a dashed markdown list rather than stringing them together with commas and "and".
Woolf's editing examples are single-line list items of the form "- Put a strawberry in the left eye socket". One instruction, one line, one dash. A comma-separated sentence asks the model to parse where one instruction ends and the next begins. A list has already answered that question, and the parsing budget it saves goes into execution instead.
Anyone who has watched a model apply two of the four things they asked for, seemingly at random, is watching a segmentation failure rather than a capability failure. The list fixes segmentation.
Once the list habit is in place, group the lists under headings. A working structure looks roughly like this:
The labels do work beyond tidiness. A prompt with a heading called Lighting tells the model that the lines beneath it are lighting instructions and should not be read as, say, wardrobe. Unlabelled prose leaves every phrase competing to attach itself to the nearest noun, which is how "golden dress, soft light" becomes a dress that glows.
This is the technique that will look absurd until it solves your hardest problem. Instead of describing a character in a sentence, define them as a structured object with named attributes, and reuse that object across every render.
The granularity Woolf documents goes much further than most people would think to write down: hair volume, fingernail length, calf size. He built composite character definitions running to roughly 2,600 tokens each. That is an enormous amount of text to spend on one person, and it buys the thing that comma prompting cannot: the fingernails match in shot two.
Consistency comes from specification. Anything you leave unspecified gets re-rolled every generation, and the details you never think to name are exactly the ones that quietly drift. A character sheet is just the discipline of naming them once.
You do not need 2,600 tokens to start. Take the character you draw most often and write fifteen fields: hair colour, hair length, hair volume, eye colour, eyebrow shape, skin tone, build, height impression, three fixed wardrobe items, two accessories, and one distinguishing mark. Save it. Paste it into every prompt featuring her. That alone will outperform your current approach.
Most people's negative handling is a pile of vague words. Woolf's finding is that precise prohibitions work better than general ones, and the example is as plain as it gets: "Do not include any text or watermarks" rather than a scattering of words like "text, watermark, letters, signature".
A full sentence naming the thing you do not want is easier to comply with than a bag of related nouns, because the bag of nouns is ambiguous about whether you are describing something to avoid or something to include. Say the whole sentence.
One more technique, and it is the one that most changes the feel of an image. Referencing a specific publication context, Woolf's example is a Pulitzer Prize-winning New York Times cover, improves composition and professionalism more than stacking quality adjectives does.
The reason is that "masterpiece, best quality, 8k, highly detailed" describes nothing. No photograph in the training data was captioned that way by the people who made it. A named publication context, on the other hand, carries an entire implied specification: the framing conventions, the colour treatment, the subject distance, the restraint. You are pointing at a body of work instead of listing adjectives that mean "good".
All of this costs tokens, which raises the obvious objection. The context window Woolf reports for the model is 32,768 tokens. Your 2,600-token character sheet uses about eight percent of it. Two full character sheets, a composition block, a lighting block and a restrictions block still leave most of the window empty.
The habit of writing terse prompts is a holdover from 77-token CLIP encoders, where every word genuinely competed for space and people trimmed articles and prepositions to fit. That constraint is gone on the newer models, and the compression reflex it created is now actively costing you quality.
Worth saying clearly, because a technique article that admits no limits is selling something. Structured prompting is overhead, and overhead is only worth paying when it buys you something.
If you are exploring, do not do this. Early exploration is a search problem, and the whole point is to let the model surprise you. Locking a 2,600-token specification in place before you know what you want is how you spend an afternoon producing forty variations of an idea you had not finished having. Type something short and strange and see what comes back.
Structure earns its cost in exactly two situations: when you need the same character to survive multiple renders, and when a specific detail keeps coming out wrong. Recurring characters, sequential images, anything with a client attached, anything where a mismatch would be noticed. For a one-off portrait you will never make again, a good sentence is genuinely fine.
These findings also come from documented experiments on one family of models. Treat the specific behaviours as strong starting hypotheses for whatever you run rather than universal laws, and check them on your own setup before you rebuild your whole workflow around them.
Take your most-used prompt and do four things to it. Break the comma wall into a dashed list. Group those lines under Character, Composition, Lighting and Restrictions. Capitalise the two rules that keep getting ignored and put MUST in front of them. Replace your negative word-salad with one plain sentence.
Run it against the old version with the same seed. That comparison, on your own model with your own subject, is worth more than any claim made here.
Once the structure is working, fill the blocks with better material: pull your light vocabulary from the lighting guide, your camera block from the lens language guide, and your wardrobe block from the fabric and clothing texture guide. Then file the finished blocks into the system from the prompt library guide, because a character sheet you cannot find again is a character sheet you will rewrite.