Prompt engineering advice has a credibility problem. A lot of it is folklore that gets repeated because it sounds plausible, and almost nobody publishes the control run.
So when I hit a skill whose troubleshooting table made two specific, testable claims, I ran both.
Both held. Here is the data.
Setup
The skill is creative-scene from an MIT-licensed e-commerce library. It is pure text-to-image — no source asset required, which makes it unusually clean for controlled testing since there is no input image to confound the result.
Model is banana-pro, 18 credits per image.
dlazy banana-pro \
--prompt "..." \
--aspectRatio 3:4 --imageSize 2K \
--save out.jpg
Its prompt structure is a five-slot formula:
[person], wearing [clothing], in [scene], [framing], [mood/grade]
Person, clothing, scene, framing, mood. Fill whichever are missing. Append photorealistic, some lens language, no text, no watermark.
That structure is what makes the tests below possible — you can hold four slots constant and move exactly one thing.
Test 1: does framing-term position matter?
The claim, from row one of the troubleshooting table:
Half-body result when you asked for full-body → the framing term was placed too late in the sentence.
This sounds like superstition. Token order affecting composition in a diffusion-adjacent pipeline is plausible in principle, but "move the word earlier" is exactly the kind of advice that propagates without evidence.
Control — framing term at the end:
A young Asian woman wearing a flowing red silk maxi dress standing in a
minimalist concrete gallery space, soft diffused daylight, neutral colour
grading, photorealistic, shot on 85mm, full-body framing.
Variant — framing term at the front:
Full-body framing, head to feet fully in frame. A young Asian woman wearing
a flowing red silk maxi dress, standing in a minimalist concrete gallery
space, soft diffused daylight, neutral colour grading, photorealistic,
shot on 85mm.
Same subject, same garment, same scene, same lighting, same lens language. Same --aspectRatio 3:4 --imageSize 1K. The only difference is where those words sit.
Result:
- Control → cropped above the knees. Half-body.
- Variant → complete figure, head to feet in frame.
The rule is real. Move your framing term to the front and add head to feet fully in frame as a belt-and-braces clause.
Test 2: how much do realism clauses actually buy?
Row two of the same table:
Looks like an illustration or CG → no realism constraint in the prompt.
Control — bare:
A young Asian woman wearing a burgundy velvet slip dress, standing in a
dimly lit jazz bar with warm amber lighting, half-body front view.
Variant — same, plus realism clauses:
... half-body front view, photorealistic photograph, real velvet fabric
texture with visible pile direction, natural skin pores and fine facial
detail, no illustration, no CGI, shot on 85mm, shallow depth of field,
no text, no watermark.
Result: clear separation. The control has the over-smoothed, waxy skin that reads as rendered. The variant resolves velvet pile direction, visible skin pores, individual hair strands.
Worth noting which clauses seem to do the work. photorealistic alone is weak — it is a style label the model can interpret loosely. The clauses that bite are the ones naming a physical property that only exists in photographs: visible pile direction, natural skin pores. Those are hard to fake with a smooth render.
The negative constraints (no illustration, no CGI) are cheap to include and appear to help, though I did not isolate them separately.
The chained-edit pattern
Separate from the two tests, this skill ships targeted-edit templates — swap model, swap pose, swap outfit — and they share one structural rule worth stealing regardless of which tool you use:
Every template ends with a "keep the rest unchanged" clause.
For successive edits, you feed each output into the next call's --images and change exactly one dimension per step. I ran a three-step chain from one base image:
# Step 1 — pose only
dlazy banana-pro --images base.jpg \
--prompt "Change the pose to side-standing with the torso twisted and hands
behind the back, keeping identical camera angle, facial structure, skin tone
and body type, and the same clothing, scene and lighting." \
--aspectRatio 3:4 --imageSize 2K --save edit1-pose.jpg
# Step 2 — top only, fed from step 1
dlazy banana-pro --images edit1-pose.jpg \
--prompt "Change the model's top to a black turtleneck slim-fit base layer,
keeping everything else exactly the same — face, hairstyle, skin tone, body
type, pose, camera angle, cafe background, lighting and colour grading." \
--aspectRatio 3:4 --imageSize 2K --save edit2-outfit.jpg
# Step 3 — hair only, fed from step 2
dlazy banana-pro --images edit2-outfit.jpg \
--prompt "Change the hairstyle to a low ponytail, keeping the person's
identity, facial features, expression, pose, clothing, background and
lighting completely unchanged." \
--aspectRatio 3:4 --imageSize 2K --save edit3-hair.jpg
Across all three steps the person, the scene, the lighting and the grading held. Only the named dimension moved each time.
The failure mode when you skip the lock clause is not subtle — the model treats the whole frame as fair game and you get a different person in a different room. Enumerating what must not move is the entire trick, and vague phrasing (keep the rest the same) works noticeably worse than an itemised list.
Language note
The documentation makes a claim I did not formally test but did observe informally: scene and mood descriptions work in either Chinese or English, but garment material and construction detail is more stable in English.
My working pattern ended up being: write scene and mood in whichever language flows, switch to English for the garment section to lock colour, fabric, cut and neckline. Anecdotal, but it matched my experience across a dozen or so generations.
Cost discipline
Text-to-image is a numbers game — you improve your odds by generating more, not by agonising over the prompt.
# explore
--imageSize 1K --batch 4
# finalise
--imageSize 2K --batch 1
At 18 credits per image this matters. Four 1K drafts to find the direction, then one 2K final, beats iterating at 2K and burning through your budget on rejects.
What I take from this
Two documented rules, two controlled tests, two confirmations. That is a better hit rate than I expected going in — I have tested claims from a sibling skill in the same library where the headline warning did not reproduce.
Which is the actual point. Documented prompt rules are testable. Most of them take one control run and one variant run to verify, which at 1K resolution is a rounding error in cost. If a rule matters enough that you are going to apply it to every generation for the next year, spend the 36 credits and find out whether it is real.
MIT licensed, 19 skills, works with Claude Code / Codex / Cursor:
npx skills add https://github.com/dlazyai/ecommerce-skills --all
Repo: github.com/dlazyai/ecommerce-skills
Has anyone isolated which realism clause does the heavy lifting? My money is on the physical-property ones over photorealistic itself, but I only tested them as a block.
Top comments (0)