DEV Community: xiaodong Zhang

Geometry Locked, Material Variable: Building a Fabric-Swap Workflow for Garment Images

xiaodong Zhang — Wed, 26 Aug 2026 08:16:53 +0000

Changing a garment's fabric sounds like a simple image-editing request: “make this sweater silk.” In practice, it is a constrained transformation with two competing requirements:
1.the garment geometry must remain stable;
2.the surface appearance and fold behavior must change enough to communicate a different material.
The open-source fabric-on-body skill turns that tension into an Agent workflow. It takes a garment style image and a fabric swatch, then instructs an image-editing model to render a visual preview of the same design in the new material.
This is not virtual try-on, and it is not a cloth simulator. Its useful role is narrower: helping a team compare material directions before committing to physical samples.
Model the task as invariants and variables
A useful mental model is:
preview = locked_geometry(style_reference)
+ variable_material_appearance(fabric_swatch)

The style reference should control the invariants:
•silhouette and cut;
•body and sleeve length;
•neckline, cuffs, and hem construction;
•seam placement;
•camera angle, crop, and layout.
The swatch should control the variables:
•color and weave;
•reflectance and surface sheen;
•apparent thickness;
•drape stiffness;
•fold frequency and radius;
•transparency or pile.
If a prompt says only “replace the knit with silk,” the model still has to guess which pixels may move and what “silk” should look like under the scene lighting. The skill therefore adds an explicit geometry lock:
Keep the pattern identical: same cut, same body length, same sleeve length,
same collar/cuff/hem construction, same seam positions, layout and camera angle.
Replace only the material.

That sentence is not a geometric guarantee. It is a constraint expressed in natural language. A probabilistic image editor can still drift, so the workflow needs multiple candidates and a validation pass.
Translate material names into visible behavior
The strongest part of the skill is its material vocabulary. A model cannot touch a swatch or measure its tensile properties. It can only infer visible evidence. Good prompts convert a material label into renderable features.
Material Visible prompt attributes
Silk or satin Specular highlights along folds, fluid drape, continuous gradients
Chunky knit Visible yarn twist, matte fibre halo, heavy structured drape
Denim Diagonal twill, subtle slub, stiff drape, sharp fold creases
Corduroy Vertical wales, matte pile, medium-stiff drape
Chiffon Semi-transparency, fine ripples, soft transmitted light
Leather Broad low-frequency sheen, grain, stiff drape, wide creases
Fleece Dense short pile, fuzzy silhouette edge, little specular highlight

This suggests a general prompt-engineering rule: when a request contains a category label, expand it into observable attributes. “Silk” is semantic. “Narrow specular highlights on fold peaks with a fluid drape” is visual.
A minimal execution pattern
The skill uses the dLazy CLI and calls its hosted gpt-image-2 tool. The repository recommends installing skills through the skills CLI:
npx skills add https://github.com/dlazyai/ecommerce-skills --list
npx skills add https://github.com/dlazyai/ecommerce-skills \
--skill fabric-on-body

The Vercel skills CLI documents support for Codex, Claude Code, Cursor, and other agents. After installation, verify that your agent actually discovers the skill. The source repository uses a lowercase skill.md, while the published Agent Skills specification defines the canonical file as uppercase SKILL.md; the repository's ClawHub publishing flow explicitly renames it. That distinction can matter on case-sensitive systems.
A reduced generation call looks like this:
dlazy gpt-image-2 \
--prompt 'Fabric replacement. Image 1 is the garment pattern reference. \
Image 2 is the target fabric. Keep the pattern identical: same cut, body \
length, sleeve length, collar/cuff/hem construction, seam positions, layout \
and camera angle. Replace only the material. Render the target fabric through \
its visible weave, reflectance, drape stiffness and fold behavior. Neutral \
studio light, clean background, no text.' \
--images style-sheet.jpg fabric-swatch.jpg \
--size 1024x1024 \
--quality high \
--imageFormat jpeg \
--batch 2 \
--save output-style-fabric.jpg

Use --dry-run before a paid request. Prices, model availability, and latency are service state, not constants; inspect the current response rather than relying on numbers copied from an article.
Input quality is part of the algorithm
The skill's documented input constraints are 20 KB–15 MB, dimensions above 400×400, and JPG/JPEG/PNG/WebP. More important than those mechanical limits is image quality.
For the style image:
•use a front-facing flat lay or mannequin image;
•keep the silhouette fully visible;
•prefer a plain background;
•avoid complex prints when evaluating a new material.
For the swatch:
•shoot close enough to resolve the weave;
•use neutral light to avoid a color cast;
•include a gentle fold when drape matters;
•avoid environmental reflections that the model may interpret as material color.
Bad input does not merely produce a lower-resolution version of the right answer. It changes the inferred task. A distant swatch may collapse into a color chip. A warm-lit white fabric may become beige. A heavily printed style reference may compete with the requested surface.
Validate with measurable checks
Do not approve the output because it “looks realistic.” Compare it against both inputs.
Geometry check
•Is the silhouette aligned with the style reference?
•Are body length, sleeve length, and proportions unchanged?
•Are the neckline, cuffs, hem, seams, and closures still present?
•Did the crop or camera angle move?
Material check
•Does the hue match a neutrally lit swatch?
•Is the original texture fully removed?
•Are weave scale and directional texture plausible?
•Do highlights match the target reflectance?
•Are folds consistent with the intended stiffness?
Manufacturing plausibility check
•Is this fabric plausible for the design and construction?
•Did the model preserve ribbing or seams in a way that can actually be made?
•Is the image being used only for directional review, not as evidence of physical performance?
The final check is the most important. A photorealistic image can be physically wrong with great confidence.
Failure modes are more useful than a perfect demo
The source skill documents several predictable failures:
•silhouette drift when geometry is under-specified;
•color shift caused by the swatch lighting;
•the original texture surviving under the new texture;
•paper-like folds when drape stiffness is missing;
•lost ribbing, topstitching, or zippers;
•physically incompatible fabric/design combinations.
Each failure should be treated as a test case. For example, a regression set could pair the same style reference with satin, denim, corduroy, and chiffon. Instead of evaluating “beauty,” record whether each candidate passes explicit geometry and material checks.
Data flow and operational boundaries
The skill discloses that prompts and parameters go to api.dlazy.com, local assets are uploaded to files.dlazy.com, and generated results are hosted there. That is a normal hosted-generation architecture, but it matters for unreleased collections, supplier materials, and NDA-protected designs.
Before using it in a company workflow, verify:
•who may upload the source designs;
•the service's current storage and retention terms;
•whether generated assets can enter your product lifecycle system;
•who signs off on visual accuracy;
•when a physical sample becomes mandatory.
The skill file is instructions, not a local model. Installing it does not remove the hosted API dependency.
The right KPI: fewer bad sampling decisions
It is tempting to market this as “replace physical sampling.” That is the wrong claim and the wrong metric. A fabric photo does not encode hand feel, stretch recovery, shrinkage, sewing behavior, abrasion, or production tolerances.
A more defensible KPI is the percentage of weak material directions rejected before physical sampling. If a team uses visual previews to narrow eight ideas to three, then samples those three and measures real performance, the AI has compressed the decision loop without pretending to simulate the factory.
That is where fabric-on-body is most interesting: not as a magic image prompt, but as a small, auditable operating procedure around a probabilistic model.
Next steps
If you evaluate the skill, start with one clean style image and four materials with visibly different behavior. Run multiple candidates, score them against the same checklist, and keep the physical sample as the source of truth.
Would you trust a geometry-locked visual preview for internal material selection? Which measurement would you require before putting it into a production workflow?
Suggested cover prompt
Editorial technical illustration for a developer article. A flat-lay garment silhouette is locked by precise cyan geometry guides while its surface transitions across satin, denim, corduroy and chiffon quadrants. On the left, a clean garment style reference; on the right, macro fabric swatches; in the center, an AI transformation pipeline. Dark neutral background, crisp diagrammatic lighting, realistic textile detail, no logos, no text, 16:9.

The hardest part of AI garment extraction is the shoulder you never saw

xiaodong Zhang — Wed, 26 Aug 2026 05:25:43 +0000

This article was written with the help of AI. The spec analysis is mine, and every command below was run on my own machine before publishing.

The problem

图 1 · 输入与输出（示例来自仓库 docs/clothing-extraction/）
You have 140 SKUs going live next week. What you have is supplier photos and on-model shots. What the listing needs is flat-lays: garment laid out, centred, front-facing, symmetric, no human in frame.
The classic answer is a photographer and a retoucher. The other classic answer is your designer spending twenty minutes per item in Photoshop, most of it not removing the model but inventing the parts of the garment the model was standing in front of.
That second half is the interesting problem, and it's the one most "AI background remover" tools don't touch at all.
TL;DR
• clothing-extraction is a skill spec (a Markdown file an agent reads) from dlazyai/ecommerce-skills, MIT licensed
• It fixes the extraction prompt into four segments, and the doc is explicit that segment two — the deletion list — must name every element individually
• It runs gpt-image-2 with --size 1024x1024 --quality high --batch 2~3
• The batch 2~3 is the tell: this is a generate-several-pick-one workflow, not a one-shot converter
• The occluded regions are inferred from symmetry and standard patterns, not recovered. Plan a human review step
Install

everything in the repo (19 skills)

npx skills add https://github.com/dlazyai/ecommerce-skills --all

or just what you need

npx skills add https://github.com/dlazyai/ecommerce-skills \
--skill clothing-extraction

or scope it to one agent

npx skills add https://github.com/dlazyai/ecommerce-skills --agent claude-code

The skill shells out to the dLazy CLI, pinned to @dlazy/cli@1.2.3. Auth is a device-code flow that works over SSH:
dlazy login # device-code flow, writes ~/.dlazy/config.json

or

dlazy auth set YOUR_API_KEY

or per-invocation

DLAZY_API_KEY=... dlazy gpt-image-2 ...

You can also skip the installer entirely and paste the contents of skill.md into an agent conversation. It's a spec, not a binary.
The actual call, straight from the doc:
dlazy gpt-image-2 \
--prompt '' \
--images docs/clothing-extraction/source-photo.jpg \
--size 1024x1024 --quality high --imageFormat png \
--batch 2 \
--save docs/clothing-extraction/output-dress.png

--dry-run prints the payload and the cost without executing. Use it first.
How the prompt is structured

图 2 · 四段式提取指令
This is the part worth stealing even if you never install the skill.
Segment Job
1 Name the single target garment, with enough detail to disambiguate it
2 List every element to remove, one by one
3 State the output form: laid flat, centred, front view, left-right symmetric, unoccluded
4 State the fidelity constraints: same colour, same knit texture, same neckline and armhole shape, same waist seam and hem length

Written out, a segment-two list for a street-style shot looks roughly like this:
[Segment 1 · target] Output only [the single item to keep: category + colour + key features].
[Segment 2 · remove] Remove the model, [every other element in frame: accessories/bag/shoes/props/background].
[Segment 3 · form] Laid flat and centred, front view, symmetric, fully unoccluded.
[Segment 4 · fidelity] Keep the garment 100% faithful: same [colour], [knit/fabric],
[neckline and sleeve], [waist seam and hem length].

Filled in against the example image that ships with the skill — a street shot of a model in a light-grey knit mini dress, wearing a pearl necklace, carrying a tote bag, in silver heels, with a fountain behind her:
Output only the light-grey textured sleeveless knit mini dress with the mock neckline,
laid flat and centred, front view, symmetric, fully unoccluded — remove the model,
the pearl necklace, the tote bag, the shoes, the fountain and the whole background.
Keep the garment 100% faithful: same light-grey colour, same knit texture,
same neckline and armhole shape, same waist seam and hem length.
Pure white seamless background, even soft studio light, subtle contact shadow.
No person, no props, no text.

Every removal target is a noun the model can act on. "Remove everything except the dress" is not — it hands the disambiguation problem back to the model, and the model makes a choice you never get to see.
The doc is blunt about this: write only remove the background and the necklace, bag and shoes stay in frame as part of the product.
For a full outfit, you loop: one pass per garment, one flat-lay out per pass.
Why segment two is the load-bearing one
Here is the argument for the sceptical reader, because there is a good sceptical reading here.
The obvious objection: this is just a prompt. When the next model ships, the prompt is obsolete, and maybe today's model doesn't need this much hand-holding anyway.
Half right. Segments three and four are model-dependent — they're compensating for current failure tendencies, and a better model needs less of them.
Segment two is not. Segment two solves referential ambiguity, and that isn't a capability problem, it's a language problem. Any time the input frame contains more than one object, someone has to say which one survives. A stronger model guesses better. It still guesses.
That's why the deletion list is the part of this spec I'd expect to still be true in two years.
Input constraints
Straight from the spec:
Constraint Value
File size 20 KB – 15 MB
Resolution > 400 × 400
Formats jpg / jpeg / png / webp

Plus three soft requirements that matter more than the hard ones: the garment should occupy a large share of the frame, the angle should be front-on or slightly off-axis, and the lighting should be even.
Also useful: the repo's CLI supports --dry-run for a cost estimate before you commit, and per-image cost lands somewhere in the 3–60 credit range depending on model and quality tier.
The repair table is the other thing worth stealing

图 3 · 症状 → 追加句
The spec ships a lookup table mapping each failure symptom to a sentence you append to the prompt. This is the part that turns a prompt into a debuggable artifact:
Symptom Append to the prompt
Accessories survived Nothing but the garment may remain in the frame.
Output still has body volume The garment must be laid completely flat — no body volume, no invisible mannequin effect.
Sleeves don't match Mirror-symmetric layout: both sleeves at the same angle and length, collar centred.
Print got rearranged Keep the print at its original position and scale relative to the garment body; do not tile or recentre it.
Colour drifted brighter Sample the colour from the source photo under neutral light; do not brighten or saturate.

Note what these have in common: every one is a constraint you forgot to state, not a model failure. That framing is doing real work.
What went wrong
[需人工补：把下面三条换成你自己跑出来的报错和修法，附截图。Dev.to 的信任度全在这一节。]
Three failure modes the spec itself flags, which map cleanly onto what you should be watching for:

Occlusion is inference, not recovery. Arms crossed, hand in pocket, a tote bag across the hip — the model returns a plausible standard-pattern seam. Plausible is not the same as correct. The spec says this itself, in its own input-rules table: occluded regions are inferred, not recovered, and need human confirmation when a key design feature is behind the obstruction. That's a fairly honest thing for a tool's docs to admit.
Prints don't survive reconstruction cleanly. When a pattern crosses a seam, the reconstructed flat-lay tends to shift it. "Pattern position accurate" is in the QA checklist for a reason. Graphic tees and placement prints are where you'll spend your review time.
"Symmetric" fights asymmetric design. Segment three asks for left-right symmetry. Wrap fronts, one-shoulder cuts, layered hems and sheer panels all disagree with that instruction, and the model resolves the conflict in favour of the instruction. For those pieces, rewrite segment three rather than accepting the default.
A full outfit is N runs, not one. The doc is explicit — one garment per pass, segment one names it, segment two lists everything else including the other garments. Asking for the dress, the bag and the shoes in a single call does not work. When not to use this

图 4 · 执行流程
• As-is on a listing's hero image. In most jurisdictions, advertising law expects product imagery to represent the actual product. A seam the model invented is not the product. Treat these as supporting images or as a base for retouching, and keep a real photo as the hero.
• Stripping someone else's branding. The spec draws this line itself, in its own "does not do" list: not for erasing another brand's marks and passing the garment off as your own. Worth repeating because the competitor-screenshot use case makes it very easy to drift there.
• Complex construction. Pleating, draping, transparency, heavy texture layering — the reconstruction step is where these lose their identity.
• Anything you won't review. The batch 2~3 default exists because you're expected to look at the candidates and choose. A pipeline that auto-publishes the first result is using this wrong.
Wrap-up
The reusable idea here is not the model choice. It's that a working image-editing prompt has four jobs — keep this, delete these, output in this form, preserve these properties — that the deletion list is the one that has to be exhaustive, and that every recurring failure gets its own append-this sentence rather than a rewrite.
Worth noting the skill is the exact inverse of another one in the same repo, flat-lay, which goes from flat-lay to on-model. Same four-segment shape, opposite direction. That symmetry is a decent sign the structure generalises.
One caveat on maturity: the repo is MIT licensed with 19 skills covering the whole chain from flat-lay through on-model to pre-launch QA, but it's sitting at 2 stars as of August 2026. This is early software. Read the spec, steal the structure, don't assume it's battle-tested.
Question for anyone who's done this at volume: how do you handle placement prints? I haven't found a segment-four phrasing that reliably pins a graphic to its original position across a seam, and I'd rather learn yours than keep guessing.

Disclosure: I work on dLazy, which is the CLI this skill calls. This post is about the prompt structure, not the product. Repo: https://github.com/dlazyai/ecommerce-skills

Two prompt rules that sound like superstition. I A/B tested both — they hold

xiaodong Zhang — Tue, 25 Aug 2026 08:10:47 +0000

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.

When the product is 5% of the frame, the prompt problem inverts

xiaodong Zhang — Tue, 25 Aug 2026 08:04:25 +0000

I wrote previously about a skill that dresses a model in a flat-lay garment. Same library has a sibling for accessories — shoes, bags, watches, glasses, hats, scarves, necklaces, earrings, belts, gloves.

I assumed it would be the same problem with a different noun. It is not, and the reason is worth a post.

The frame-share problem

A sweater occupies most of the image. The model cannot really lose track of what the subject is.

A pair of sunglasses occupies maybe 5% of the frame. At that scale the model has enormous latitude, and it uses it — tilting them, oversizing them, floating them somewhere near the face, or smearing them into the hair.

So the documentation puts one sentence in bold above everything else:

The selection region is the decisive parameter.

Not the model. Not the resolution. Not the quality tier. Where the thing goes.

Anatomy strings, not bounding boxes

The interesting design choice is that you do not draw a box. You describe the anatomical attachment in prose, and each category has a canonical phrasing:

Category	The sentence
Glasses	seated on the nose bridge and hooked over both ears
Watch	on the left wrist, dial facing the camera
Necklace	clasp at the nape, pendant resting on the collarbone
Earring	on the visible earlobe, at correct scale
Hat	brim angle following the head tilt
Scarf	wrapped twice, fringe over the chest
Shoes	soles contacting the ground with correct perspective and grounded shadows
Bag	held in hand or on the shoulder, strap compressing the fabric

These read like stage directions because that is effectively what they are. soles contacting the ground with correct perspective and grounded shadows encodes three separate constraints — contact, perspective, and shadow — in one clause, and dropping any of them produces the classic floating-shoe artifact.

Full call:

dlazy gpt-image-2 \
  --prompt "On-model accessory product photography. Image 1 is a pair of
   tortoise-brown rectangular acetate sunglasses with gradient brown lens
   tint and metal hinges. Image 2 is the model and scene reference.
   Place the sunglasses from image 1 on the face of the person in image 2,
   seated on the nose bridge and hooked over both ears, with natural
   perspective matching the head angle, correct real-world scale relative
   to the face width, realistic lens reflections and a soft contact shadow.
   Preserve 100% fidelity of the frame shape, tortoise acetate grain, hinge
   and temple design, and the exact lens tint.
   Change nothing else — face, hair, coat, background, color grading and
   crop must remain identical to image 2.
   Photorealistic, no text, no watermark." \
  --images product-sunglasses.jpg model-reference.jpg \
  --size 1024x1536 --quality high --batch 3 \
  --save out/SKU001.jpg

The lock clause is not optional

Note that second-to-last sentence. It is doing critical work.

Change nothing else — face, hair, clothing, background, color grading
and crop must remain identical to image 2.

Because the product is tiny, the model has spare capacity and will happily spend it repainting the face. You end up with correctly-placed sunglasses on a person who is subtly not the same person.

The anatomy string and the lock clause are a pair. Ship them together every time. And when the lock fails, the fix is to stop being general — replace "everything else" with an itemised list of the specific things that must not move.

Reference selection is stricter than for garments

Three hard requirements, all more demanding than the garment equivalent:

1. The wearing area must be visible and unobstructed. Glasses need a clear face. A watch needs a bare wrist — a shirt cuff kills it. Shoes need feet not hidden under a long skirt.

2. The model must not already be wearing the same category. Otherwise you get two pairs of sunglasses. If you cannot avoid it, add an explicit replace the existing sunglasses clause.

3. Light direction should roughly match the product shot. Metal and lenses generate reflections, and reflections lit from the wrong side read as fake immediately.

I generated my reference images deliberately against these rules — a face shot specified as no glasses, hair tucked behind the ears, and a wrist shot specified as sleeve rolled up above the wrist, no watch on either wrist. Worth doing if you are producing references rather than sourcing them.

Multi-view for complex geometry

Simple items (glasses, necklaces) work from one view. Complex ones do not.

Shoe → side profile plus sole
Bag → front plus interior

The skill takes up to 5 reference images, so [product-view-1, product-view-2, reference] maps to image 1 / image 2 / image 3. Feeding a second angle is the documented fix for garbled bag interiors — the model cannot infer the inside of a bag it has only seen closed.

Symptom mapping

Same design as its sibling skill: enumerated failure modes, each with a specific append.

Symptom	Cause	Append
Glasses crooked or floating	Missing anatomy string	The section-3 phrase for that category
Shoes not grounded	No contact clause	Ground contact + grounded shadow
Wrong size	No scale anchor	A width ratio against a body part
Two pairs of glasses	Reference already wore some	`replace the existing …`
Face changed	Lock clause too vague	Itemise the untouchable elements
Metal looks like plastic	Quality tier	`--quality medium` → `high`
Bag interior garbled	Insufficient geometry	Supply additional views

The --quality one is worth internalising: use high for metal, lenses and leather; medium is fine for fabric accessories. At 60 vs 33 credits that distinction is worth making deliberately rather than defaulting.

Parameters

--images — product first, reference last. Order maps positionally to image N, silently.
--size — 1024x1536 for half/full-body wear shots, 1024x1024 for wrist or earring close-ups.
--batch 2–4 — placement varies run to run more than it does for garments, precisely because the target region is small.
--dry-run — always, before a loop.

QC dimensions specific to this

Five things to check, and they are not the same five you check on a garment:

Placement — is it anatomically right
Proportion — is the scale plausible
Reflection plausibility — does the light direction match
Duplicates — did a second pair appear
Was the face altered

That last one is the sneaky failure. The accessory can be perfect while the model's face has quietly shifted. If you are producing a series against one locked model, this breaks the series and it is easy to miss when you are looking at the product.

Takeaway

The generalisable lesson: as the edit region shrinks relative to the frame, prompt precision has to increase, not decrease.

Intuition says a small edit is an easy edit. In practice a small target gives the model more freedom to be wrong, and more spare capacity to wander into regions you never asked it to touch. Two sentences fix both — one saying exactly where the thing attaches, one saying nothing else may move.

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

The docs said unnamed items get dropped. I ran the A/B and couldn't reproduce it

xiaodong Zhang — Tue, 25 Aug 2026 07:57:21 +0000

There is an open-source skill in a library I have been working through called image-fusion. It takes up to 8 separate product photos — a top, trousers, a coat, boots, a scarf, whatever — and composites all of them onto one model to produce a single complete-look e-commerce shot.

Its documentation contains one rule stated more emphatically than any other:

每张图对应一个明确的穿着位置，不点名的单品会被忽略。
Each image maps to one explicit wear position. Items not named will be ignored.

That is a strong, falsifiable claim. So I falsified it. Or tried to.

The mechanism, as documented

The prompt is supposed to roll-call every garment, mapping each input image index to a body location:

图1 的米白色罗纹高领毛衣作为内搭上装；
图2 的驼色羊毛阔腿长裤作为下装；
图3 的炭灰色长款大衣作为外套敞开穿在最外层；
图4 的黑色皮质踝靴穿在脚上；
图5 的锈橙色羊毛围巾绕在颈部垂在胸前。

图N maps positionally to the Nth entry in --images, so upload order matters:

dlazy seedream-5.0 \
  --prompt "$PROMPT" \
  --images i1-top.jpg i2-pants.jpg i3-coat.jpg i4-boots.jpg i5-scarf.jpg \
  --size 3:4 --resolution 2k \
  --save out/look-01.jpg

Model is seedream-5.0 — roughly 5 credits per image, up to 10 reference images. Notably cheaper than the gpt-image-2 used by sibling skills in the same library (60 credits at high quality), which matters when you are generating outfit variations at volume.

The five-item version works exactly as advertised:

All five garments present
Layering correct — coat open, turtleneck visible underneath
No colour contamination between the five items

Fine. Now the actual question.

The experiment

I built two prompts over the same 8 input images, in the same order.

Group A — no roll-call. Deliberately lazy:

电商搭配商拍图。模特穿着这些单品，青年亚洲女模特，正面站姿，
全身入画，纯浅灰色摄影棚背景，柔和顶光。真实照片质感，无文字无水印。

That is it. "The model is wearing these items." No index mapping, no wear positions.

Group B — full roll-call. Every item named with its position, plus explicit layering order and a colour-contamination guard, plus the documented failure clause: "八件单品缺一不可，少任何一件都视为失败" (all eight are mandatory; missing any one is a failure).

Same images, same order, same model, same size, same resolution.

Result

Group A: all 8 items present.

Group B: all 8 items present.

I had also run a 5-item version of the same test earlier. Same outcome — the un-roll-called prompt produced all five garments.

I could not reproduce the documented failure mode. Not once, across two separate item counts.

So is the rule wrong?

No — and this is the part I think is worth the post.

The two outputs are not identical. They differ in ways that have nothing to do with item count:

Dimension	Group A (no roll-call)	Group B (roll-call)
Items present	8	8
Layering	Turtleneck and placket barely visible under the coat	Coat hangs open, inner collar and placket clearly shown
Belt position	Sits high, mostly hidden by the coat	Correct, aligned with the trouser waist
Controllability	Whatever the model decides	Exactly what the prompt specifies

Group A did not drop anything. It made its own choices about how things were worn — and its choices were worse.

Which reframes the rule. Roll-calling is not a completeness mechanism. It is a control mechanism.

You are not writing 图3 的大衣敞开穿在最外层、露出里面的高领毛衣 to stop the coat from vanishing. You are writing it because otherwise the model buttons the coat and hides the garment you are actually trying to sell.

For an e-commerce use case that distinction is not academic. The whole point of a full-look shot is that a shopper can see every item in it.

What I would keep from the documentation anyway

Even having failed to reproduce the headline warning, three of its adjacent rules held up in testing and are worth following:

Layering must be ordered explicitly. Two garments at the same body location without a stated order means the model picks one. This one I did observe.

叠穿顺序由内到外：高领毛衣 → 大衣，大衣不系扣，
内搭领口和前襟必须清晰可见。

Colour contamination is real when hues are close. Hard-coding each item's colour is cheap insurance:

这五件单品相互独立，颜色不得相互污染：毛衣米白色、长裤驼色、
大衣炭灰色、靴子黑色、围巾锈橙色。

Do not put two items of the same category in one call. The model either picks one or blends them. This is a documented boundary and I see no reason to test it — the failure is obvious and the fix is trivial (split into two looks).

Batch consistency

If you are generating a set of looks rather than one, the skill's advice is to freeze four things and vary only the item list:

Model — same reference photo, or a fixed description
Pose and framing
Background and lighting
Composition and headroom

Copy those four sentences byte-for-byte between calls. Only the garment roll-call changes. Same principle as a frozen spec segment in batch pipelines — if you edit the invariant part mid-set, the set stops being a set.

I ran a second look with four items against an identical frozen block and the two outputs sit together correctly as a pair.

Practical notes

--size 3:4 for full-body looks, 1:1 for square main images. Vertical dominates e-commerce.
--resolution 2k is enough for a listing. 3k/4k for print.
--batch 2~4 — multi-item composition has real run-to-run variance, so generate a few and pick.
Upload in wearing order: top → bottom → outer → shoes → bag → accessories. Keeps 图N readable when you are editing the prompt later.
Do not feed images that already have a person wearing the item. The original body comes along for the ride.

Takeaway

The documented rule was "roll-call or lose items." My testing says the actual rule is "roll-call or lose control."

That is a less dramatic claim, but a more useful one — because it tells you when you can skip it. Throwing four unrelated items at it for a quick internal mock-up? Probably fine without. Producing a listing image where the coat has to be open so the sweater underneath is visible? Write every line.

If anyone has managed to reproduce the actual drop behaviour — higher item counts, closer categories, a different model version — I would genuinely like to see it. Eight was my ceiling because that is the documented cap.

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

Batch-generating 100 product images is easy. Making them look like one set is not

xiaodong Zhang — Tue, 25 Aug 2026 07:47:59 +0000

Most people assume the hard part of batch image generation is the volume. A hundred products means a hundred calls, which sounds tedious.

It is not the hard part. A loop solves that and machines do not get bored.

The hard part is that those hundred images have to look like one photographer shot them on one day in one studio. Same background. Light from the same direction. Same camera angle. Products at the same scale in frame. Shadows falling the same way.

Miss by a little and the storefront reads as cheap.

The pattern

The skill I have been testing (batch-image, from an MIT-licensed library) solves this with one structural idea:

prompt = [SPEC SEGMENT — byte-identical across the entire batch]
       + [VARIABLE SEGMENT — rewritten per SKU]

The mental model that made it click for me: you are building a studio, not writing prompts. Backdrop paper, key light, fill light, camera on a tripod at 45°, everything taped to the floor. Once it is built you never touch it. Products get carried in, shot, carried out.

The spec segment is the studio.

Variable segment — different every call:

电商商拍图。图1 是商品：米白色罗纹高领针织毛衣，修身版型。
商品的颜色、材质纹理、款式细节必须与图1完全一致。

Spec segment — never changes, not one character:

放置在同一套统一视觉里：纯米白色摄影棚背景，柔和顶光加左侧补光，
45 度视角，画面下方留出统一的商品投影，构图与留白在整组图中保持一致。
深色商品需加右侧轮廓光勾边，避免与背景糊在一起。
商品在画面中的占比统一为约 65%，边距一致。
真实商业产品摄影，无文字无水印。

Does it hold?

I picked six products chosen to be as awkward as possible — light, dark, reflective, textile:

cream ribbed sweater · black leather ankle boots · black leather chain bag · silver steel watch · black wool bucket hat · rust wool scarf

Then ran the spec segment six times without touching a character, swapping only the variable part.

It holds. Background reads identically across all six. Light comes from upper-left in every frame. Shadows fall lower-right. Products occupy roughly the same share of frame with even margins.

The interesting case is the three black items. They do not blend into the off-white background — because of one clause I had put in the spec segment on the documentation's advice:

深色商品需加右侧轮廓光勾边，避免与背景糊在一起。
(dark products need a rim light on the right edge so they don't
 merge with the background)

That single sentence is doing real work. Without it, dark leather against off-white loses its silhouette.

The negative control

The docs carry a heavy warning: change one character of the spec segment and the entire batch must be re-run.

Easy to test. I regenerated two of the six with a different spec — dark grey concrete background, strong side-backlight, straight-on eye-level camera — and mixed them back into the contact sheet.

You can pick them out instantly. There is no ambiguity, no "if you look closely." Two different studios in one grid.

Which is why freezing matters operationally: any edit to the spec invalidates everything generated before it. That is a strong argument for the workflow order below.

Orchestration

dlazy runs one task per invocation, so concurrency comes from the shell. The documented sweet spot is 4–6 lanes; higher risks rate limiting.

Manifest is a three-column CSV:

sku,image,desc
SKU001,products/sweater.jpg,米白色罗纹高领针织毛衣，修身版型
SKU002,products/boots.jpg,黑色皮质粗跟踝靴，侧拉链设计

Worker with retry and backoff:

SPEC='...'   # the frozen block
export SPEC

run_one() {
  IFS=, read -r SKU IMG DESC <<< "$1"
  for attempt in 1 2 3; do
    dlazy seedream-5.0 \
      --prompt "电商商拍图。图1 是商品：${DESC}。商品的颜色、材质纹理、款式细节必须与图1完全一致。${SPEC}" \
      --images "$IMG" --size 1:1 --resolution 2k \
      --save "out/${SKU}.jpg" >/dev/null 2>&1 && break
    sleep $((attempt * 10))
  done
  [ -f "out/${SKU}.jpg" ] && echo "${SKU},ok" || echo "${SKU},fail"
}
export -f run_one

xargs -P 5 -I{} bash -c 'run_one "{}"' < manifest.csv | tee report.csv
awk -F, '{c[$2]++} END{for(k in c) print k, c[k]}' report.csv

For large SKU counts, submit with --no-wait, collect the generateIds, and poll:

GID=$(dlazy seedream-5.0 --no-wait ... \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["result"]["task"]["generateId"])')
echo "$SKU,$GID" >> tasks.csv
# later
while IFS=, read -r SKU GID; do dlazy status "$GID" --wait; done < tasks.csv

The gotcha nobody documents

Building English prompts for this, every call failed:

{
  "code": "too_big",
  "maximum": 500,
  "path": ["prompt"],
  "message": "expected string to have <=500 characters"
}

There is a hard 500-character cap on the prompt, and English burns through characters far faster than Chinese does. My first spec segment — written as a natural, comfortably-worded paragraph — blew straight past it.

Trimmed version, 418 characters, output quality unaffected:

Unified visual set: off-white studio background, soft top light with left
fill, 45-degree angle, consistent shadow below, identical composition and
margins across the set. Dark products get a right rim light. Product fills
~65% of frame. Real product photography, no text, no watermark.

Terse instructions work fine. Polite full sentences just eat budget you do not have.

Worth knowing: this cap belongs to the image models. I later ran a ~1,000-character prompt against claude-sonnet-5 in the same CLI with no complaint. So do not go trimming prompts for text models on the assumption the limit is global.

Workflow order, and why it is not optional

Because any spec edit forces a full re-run, the sequence matters more than usual:

Get one SKU working end to end. Confirms the prompt direction.
Sample five. Pick edge cases deliberately: darkest, lightest, most reflective, largest, smallest. My six-product set was chosen exactly this way, which is how the rim-light clause got validated before full volume.
Price it. --dry-run prints parameters and a credit estimate without executing.
Then run everything.

Skipping to step 4 does not get you 100 images. It gets you the same mistake made 100 times, and then you fix the spec and pay for it again.

Cost notes

seedream-5.0, ~5 credits per image. 100 SKUs lands around 500 credits.

Batch scenarios reportedly drop per-image compute to ~70%
2k is enough for a listing; 4k only for print
Do not use --batch N — it multiplies cost, and your volume already comes from SKU count
If a handful of SKUs need extreme fidelity, re-run only those on gpt-image-2 (~6× cost). Never mix two models inside one batch, or you have just broken the consistency you paid for

Troubleshooting, condensed

Symptom	Cause	Fix
Batch looks inconsistent	Spec edited mid-run	Freeze it, re-run the batch
Dark product merges with background	No rim light	Add the rim-light clause, re-run
Product scale fluctuates	Scale unconstrained	Add "~65% of frame, consistent margins"
Shadow directions vary	Shadow unconstrained	Add "shadow falls to the lower right"
Mass failures partway	Concurrency too high	Drop to 4–5 lanes, add backoff

Note that the first four all end in "and re-run the batch." That is the whole argument for one-then-five-then-everything.

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

If you are running this at real volume I would be curious whether anyone has wired the failure queue into a re-run with an escalated model automatically, rather than eyeballing the report.

Turning a flat-lay photo into an on-model shot with two prompt segments

xiaodong Zhang — Tue, 25 Aug 2026 07:38:44 +0000

If you sell clothing online you need on-model photography, and on-model photography means booking a model, renting a space, and waiting on retouching. Three to five days per round.

flat-lay — from an MIT-licensed skill library I have been working through — collapses that to about 60 seconds. You give it a flat-lay garment photo and a pose reference, and it dresses the person in the garment.

The interesting part for a developer audience is not that it works. It is that the prompt has a rigid two-part structure, and once you see it you start recognising the same shape in a lot of image-editing tasks.

The structure

Every call is built from two things that pull in opposite directions:

Preserve — everything about the garment must survive unchanged:

Preserve 100% fidelity of the garment color, knit texture, oversized
drop-shoulder silhouette, collar, cuff and hem details, and the placement
of the woven label.

Adopt — everything about the scene must come from the reference:

Keep the exact pose, camera angle, crop, body proportions, lighting and
background from image 2.

That is the whole skill. One clause locks the product, the other locks the context, and the model resolves the middle.

Full call:

dlazy gpt-image-2 \
  --prompt "E-commerce on-model product photography. Image 1 is a flat-lay of
   an olive green cable-knit crewneck sweater with a chunky diamond cable
   pattern, ribbed collar and cuffs, and a woven label on the left cuff.
   Image 2 is the pose and scene reference. Dress the model from image 2 in
   the garment from image 1, replacing the clothing they currently wear.
   Preserve 100% fidelity of ... Keep the exact pose, camera angle, crop ...
   Photorealistic catalog styling, sharp fabric detail, soft natural light,
   no text or watermark." \
  --images garment-flatlay.jpg pose-reference.jpg \
  --size 1024x1536 --quality high --imageFormat jpeg --batch 3 \
  --save out/SKU001.jpg

Model is gpt-image-2 — multi-image editing, up to 5 reference images, 60 credits at --quality high.

`--images` order is load-bearing

This tripped me up and it is worth flagging because the failure is silent.

The positional order of --images maps to image 1, image 2, image 3 in the prompt text. There is no key, no label, no validation. Swap the order and the model dresses your flat-lay in a person.

# single garment
--images garment.jpg reference.jpg          # image 1, image 2

# full look
--images top.jpg bottom.jpg reference.jpg   # image 1, image 2, image 3

The convention is: product first, reference last. Keep it consistent across a project or your prompt text quietly stops matching your arguments.

Specificity is the whole quality lever

The single highest-leverage thing in this prompt is the garment description, and the gap between lazy and specific is not subtle.

# weak
a green sweater

# strong
an olive green cable-knit crewneck sweater with a chunky diamond cable
pattern, oversized drop-shoulder fit, ribbed collar and cuffs, and a
woven label on the left cuff

Same model, same reference, same parameters. Materially different output. Every additional structural noun — drop-shoulder, ribbed, diamond cable — is a constraint the model can hold onto rather than invent.

English is recommended over Chinese for the garment section specifically. Scene and mood work in either.

Symptom-driven add-ons

What I found genuinely well-designed is that the failure modes are enumerated, and each maps to a specific sentence you append. Not "try rewording it" — an actual mapping.

Symptom	Append
Colour drifted	`Match the garment color to image 1 exactly — same hue, saturation and brightness`
Texture went mushy	`visible knit loops / weave grain / pile direction`, fiber sheen, soft fold shadows
Broken hands, warped collar	`five fingers per hand, symmetric shoulders, no extra limbs`
Face or background changed	`Change only the garment region` + itemise what must stay identical

That last one is the important one. Because the garment occupies most of the frame in this skill, the model tends to treat the whole image as editable. Region-locking is cheap and prevents the most annoying class of failure — a perfect sweater on a subtly different person.

Input constraints worth validating before you spend credits

20KB–15MB, above 400×400, jpg/jpeg/png/webp
Reject: garments occluded by arms or props, images containing both a top and a bottom (split into two files and use full-look mode), anything blurry or blown out

That second one bit me. An "outfit" photo with a top and trousers in one frame is not one input — the model picks one or blends them. Two files, three images total, roll-call each.

Reference selection drives everything downstream

The reference image controls pose, camera angle, crop, lighting and background. Choosing badly is not recoverable in post.

Fidelity first → frontal standing pose, plain background, crop matched to the category (half-body for tops, full-body for dresses)
Mood first → street or interior scenes, at the cost of some fit drift
Batch consistency → freeze one reference and one model, swap only the garment

That last mode is what makes this usable at scale. Dozens of SKUs against a single locked reference produce a visually coherent catalogue. Specifying a locked model adds roughly a minute per call.

Parameters

Flag	Value	Why
`--size`	`1024x1536`	3:4 vertical, the e-commerce standard. `1024x1024` for detail shots
`--quality`	`high`	`medium` visibly softens knit texture
`--imageFormat`	`jpeg`
`--batch`	`2–4`	Run-to-run variance is real; generate a few and pick
`--dry-run`		Prints parameters and a credit estimate without executing

Always --dry-run first. At 60 credits per image, a typo in a batch loop is expensive.

QC before you ship

Four things to check on every output: colour drift, texture blur, print displacement, hand and collar artifacts.

The library has a dedicated skill for this (detect-task, ~3 credits per image) that checks eight fixed dimensions and hands back an English fix line you can append to the original prompt. I have written about it separately — including the part where it caught a hand defect in an image I had already published as an example.

Which is the real argument for automated QC. Not that the model is unreliable — it is that you stop seeing your own output after the third look.

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

I ran AI quality control on my own published work. It found what I missed

xiaodong Zhang — Tue, 25 Aug 2026 07:13:06 +0000

I have been writing a series of articles about an open-source skill library for e-commerce image generation. Nineteen skills, all of which produce images.

Except one.

detect-task produces no image. It produces a verdict. You hand it a generated image, it runs eight fixed checks, and it tells you whether the thing is fit to ship.

I decided to test it the uncomfortable way: by pointing it at images I had already published in earlier articles as examples of things going right.

It did not go well for me. Which is why it is worth writing about.

What it actually does

Eight fixed checks, every time:

#	Check	Looks at
①	Product distortion	Silhouette, knit texture, print, logo placement
②	Unnatural face	Feature proportions, skin texture, gaze
③	Hand anomalies	Finger count and shape
④	Body structure	Shoulder line, limb count and orientation
⑤	Garbled text	Any text in frame
⑥	Light/shadow conflict	Shadow direction vs light source
⑦	Edge fusion artifacts	Cutout edges, ghosting, blurred patches
⑧	Platform compliance	Non-compliant elements

Output is four sections: risk level, per-check verdict with evidence, a launch recommendation, and — this is the part that matters — 1–3 English sentences you can append directly to your original generation prompt.

That last section is the whole design. The model finds the fault and hands you the patch. You paste it back, re-run, done.

Roughly 3 credits per image. About a second per call.

Running it

It is a thin CLI wrapper over a hosted API. Install and auth:

npm i -g @dlazy/cli@1.2.3
dlazy login   # device-code flow, works over SSH

The call itself is unremarkable:

dlazy claude-sonnet-5 \
  --prompt "$(cat qc-prompt.txt)" \
  --images candidate.jpg

First gotcha: the result is text, so it lives at result.data.texts[0] — not urls like every image skill in the library. If you copy-paste an extractor from a sibling skill you get an empty string and no error.

dlazy claude-sonnet-5 --prompt "$(cat qc-prompt.txt)" --images candidate.jpg 2>/dev/null \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["result"]["data"]["texts"][0])'

Note the 2>/dev/null. The CLI writes progress to stderr, and if you leave it merged your JSON parse dies on line 1 column 1. I lost a couple of minutes to that one.

Test 1: the image I thought was fine

I had used this image previously to demonstrate what happens without realism constraints in the prompt. My own assessment at the time: "skin looks a bit too smooth, mild CG feel." That was the extent of it.

The report disagreed about why it was flawed:

⑤ Garbled text — Hit. Background signage (upper right, vertical banner
with Japanese/Kanji-style characters) shows illegible/garbled character
strokes; framed photo on left wall also has indecipherable small text.

I went back and zoomed in. There is a signboard in the upper right whose strokes dissolve into mush, and unreadable text in a picture frame on the left wall.

I had looked at that image several times. I never saw either, because my attention never left the subject.

Test 2: the image I had captioned as a success

This one stings more. It opened my previous article as proof that all five prompt slots had landed correctly, complete with a caption praising it.

Three hits. The one that mattered:

③ Hand anomalies — Hit. The hand nearest the viewer shows an ambiguous
finger count/overlap near the knuckles, and the fingers wrapped around
the cup handle lack clear separation or joint definition.

Cropped it, scaled 200%, and — yes. The knuckles run together and the ring and little fingers lose their boundary.

An image I had studied, published, and held up as an example. On a real product listing, a buyer pinch-zooming on their phone finds that in about two seconds.

Test 3: control group

A product-only shot, no person in frame. Zero hits, low risk, approved.

The spread across all three lines up exactly with the documented sampling policy:

First batch on a new spec → inspect 100%
Validated spec → 10–20% random
Images containing people → raise to 30%
Product-only shots → 5% is enough

Hands and faces are where this fails. My results reproduced that precisely.

Closing the loop

Took the fix lines verbatim from section 4, appended them to the original generation prompt:

Both hands fully visible and anatomically correct with five distinct
fingers each. No text anywhere in the image. Blend all edges seamlessly;
no cut-out halo, no ghosting, no blurred patches.

Re-ran. Re-inspected. Clean — every check passed, approved for launch.

Loop closes. Nice story, good article, ship it.

Except.

The part that actually matters

I inspected that same re-run image a second time, with an English QC prompt instead of a Chinese one, because I was building an English version of the article.

Different answer.

③ Hand anomalies — Hit. The hand wrapped around the glass shows ambiguous
finger separation near the knuckles; finger count is difficult to confirm
cleanly due to overlapping shading, risking a "melted fingers" perception
on close inspection.

So I zoomed in on the re-run image. The second pass was right. The first pass had missed it.

Same image. Same check. Two runs. Opposite verdicts.

This is not a bug report — it is the documented behaviour, stated plainly in the skill's own limitations section:

It does not replace human final review — it both false-positives and misses things.

But there is a difference between reading that sentence and watching it happen to you on an image you were about to ship. If I had inspected once and trusted the green light, the defective hand goes live.

The practical rule I took away: the re-inspection step in the documented workflow is necessary but not sufficient. A pass is evidence, not proof. For anything customer-facing, a human still looks.

One more finding

In an earlier article on the batch-generation skill I hit a hard cap:

{
  "code": "too_big",
  "maximum": 500,
  "path": ["prompt"],
  "message": "expected string to have <=500 characters"
}

500 characters on the prompt. English burns through that fast — my first natural-sounding spec paragraph blew past it immediately.

That cap does not apply here. My English QC prompt is around 1,000 characters and runs fine. The limit belongs to the image models, not to claude-sonnet-5. So you can write a properly detailed QC prompt without compressing it into telegraph style.

Worth knowing before you spend twenty minutes trimming a prompt that never needed trimming.

Operational notes

Freeze the QC prompt. Use one copy project-wide. Edit it mid-project and reports from before and after are no longer comparable — same principle as a frozen spec segment in batch generation.

Demand your output language explicitly. One of my runs came back entirely in English despite a Chinese prompt asking for Chinese. This is row one of the skill's own troubleshooting table. A line marked as highest-priority fixed it.

The economics are trivially good. One high-quality image render costs 60 credits. Inspection costs 3. Spending 3 to avoid shipping a broken 60-credit asset is not a difficult calculation — the check pays for itself at a 5% catch rate.

Would I use it

Yes, with the obvious caveat.

As a first-pass filter that costs 3 credits and one second, it is excellent. It caught two real defects in images I had personally reviewed and published. That is a meaningful hit rate against a human baseline of me, paying attention.

As a gate you trust unattended, no. The non-determinism is real and I have a concrete example of it letting a defect through.

Treat it as a cheap, fast, fallible reviewer that never gets bored — which is exactly the thing humans are worst at being.

The library is 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 else run into non-determinism like this in vision-model QC pipelines? I am curious whether multi-sample voting — running the same check 3× and taking a majority — is worth the 9 credits. Drop a comment if you have tried it.

Where the money actually goes when you generate at scale

xiaodong Zhang — Mon, 24 Aug 2026 07:24:36 +0000

After a few months of running generation through an agent, the surprising thing wasn't the cost per call. It was how much of the spend went to work I didn't need to do.

Almost every fix below is about ordering and verification, not about paying less per call.

1. Iterate on the cheap tier. Always.

The largest available saving, and the most commonly skipped.

Most model families ship a fast or lite variant. They exist for exactly this: when you're deciding composition, framing or timing, you're making a decision, not producing a deliverable.

The number of drafts you discard is much larger than the number of finals you keep. Optimising the discarded ones is where the leverage is.

The failure mode is exploring on the expensive model because it produces nicer images. It does — and you're paying production prices for drafts you're about to throw away.

2. Front-load the local tools

A significant part of any video pipeline needs no model at all: transcription, scene detection, silence cutting, word-boundary alignment, and every validator.

Two consequences. First, they're free, so run them liberally. Second, and bigger:

Reduce before the model sees it. A 90-minute transcript folded to phrase level is a fraction of the input. The model doesn't need the full haystack — and producing the needle is usually a local operation.

3. Pilot every batch

Run three. Inspect. Then run the rest.

Batch work is the one place where cost is genuinely predictable — one input, one output, roughly linear. So a three-item pilot gives a real projection: measure actual consumption, multiply, add 20%.

But the real value is qualitative. Whatever is wrong with your prompt is wrong in every item. Finding out on three costs three.

4. Calibrate before generating narration

Speech rate is not a number you can look up. It varies by voice, language, punctuation, and the specific text.

tts_pacing_calibrate   # chars-per-second from one sample, project total runtime

Measure on one sample, project the runtime, adjust script or speed, then generate. A full narration pass that doesn't fit the edit is a complete write-off — and entirely avoidable.

Worth being honest about the failure mode here: there's a temptation to solve a script problem with a speed parameter. It doesn't work. It converts "too long" into "sounds rushed."

5. Validate every render, not just the final

This one saves money in a less obvious way.

The validators cost nothing, so the question isn't whether to run them but when. Run them on every render, including intermediates — because:

A defect caught at the intermediate stage costs one regeneration. The same defect caught after assembly costs the assembly too.

6. Reference images instead of adjectives

Describing a look in words takes several attempts to converge. Supplying one reference image often gets there in one.

Every failed attempt is a full-price generation. Three rounds of warmer, softer, less contrast costs three generations and still lands somewhere approximate.

One good reference image replaces a paragraph of adjectives, and it's more reliable.

7. Keep a manifest

Not obviously a cost measure. It is one.

input | prompt | model | generateId | output path | status

Without this you re-derive that information by hand, and when a run dies partway you restart from the beginning instead of from where it stopped.

A manifest is a checkpoint, and checkpoints are what make long jobs survivable.

The one I'd leave off the list

I'd stop short of recommending you optimise the model choice itself beyond the fast/full split.

Chasing per-model price differences produces small savings, a lot of context-switching, and pushes you toward models you don't know well.

Knowing one model deeply is worth more than a marginal rate — you get what you wanted in fewer attempts, and attempts are the actual cost.

The pattern underneath

Look at the list again. Almost none of it is "spend less per call."

It's: decide cheaply, verify early, checkpoint often, and don't re-derive what you already knew.

Which is the same list you'd write for any expensive batch process. The models are new; the discipline isn't.

curl -s https://files.dlazy.com/cdn/cli | bash
dlazy -h            # tool list
dlazy <tool> -h     # flags — read this before the first paid call

That second command is the cheapest habit on this page. Flag sets differ more than you'd expect between tools, and a wrong guess costs a generation.

Front-load the free work — turning a 90-minute recording into short clips

xiaodong Zhang — Mon, 24 Aug 2026 07:23:48 +0000

The obvious way to cut a 90-minute recording into short clips is to hand the whole thing to a model and ask it to find the good parts.

I tried that. It's expensive and the output degrades as it goes.

Why the obvious way fails

90 minutes of transcript is an enormous amount of context, and long context degrades judgement. The model starts confusing similar passages, loses track of what it already flagged, and its picks get worse the further in it goes.

So you pay the most for the least reliable output. Worst possible shape.

Most of this work doesn't need a model

Here's what I didn't expect: the majority of the pipeline is local analysis that costs nothing per call.

video_downloader     # pull source from YouTube/TikTok/Reels/Shorts
transcribe           # word-level ASR, with on-disk caching
transcript_pack      # fold word-level into phrase-level markdown
scene_detect         # content-aware shot boundaries via ffmpeg
snap_to_words        # align cut points to word edges, 30-200ms padding
silence_cutter       # detect and concat-cut around silence

Two of these deserve attention.

`transcript_pack` is the one that makes it viable

Word-level transcript for 90 minutes is huge and mostly noise — a timestamp on every token. Folded to phrase level it becomes something a model can read in one pass.

This is the pattern that makes agent pipelines affordable:

Reduce before the model sees it.

The same principle shows up everywhere once you look for it. Grepping ERROR lines out of a log before pasting it. Extracting changed functions instead of the whole diff. In every case the model doesn't need the haystack — it needs the needle, and finding the needle is often a local operation.

`snap_to_words` looks like a detail and isn't

Cutting on a scene boundary is visually correct and frequently lands mid-word, which sounds broken.

Snapping to word edges with a small padding window is the difference between a clip that sounds edited and one that sounds clipped. The 30–200ms padding exists because a cut placed exactly on a word boundary still clips the consonant.

This is the kind of thing that only gets built by someone who shipped a batch of clips and then read the complaints.

The order that works

1. Transcribe, then pack to phrase level.
2. From the packed transcript, pick candidate segments by topic.
   ← the only step where model judgement earns its cost
3. Run scene detection; snap chosen cut points to word boundaries.
4. Cut silence out of the selected windows.
5. Render, then run audio-pop and A/V sync checks.

Exactly one step involves paid judgement. Everything else is local.

Checkpoint the selection, not the render

Write the chosen segments — timestamps and reasons — to a file before rendering.

The selection is the expensive artefact. Rendering can be repeated cheaply; deciding what's worth keeping cannot. If the render fails, or you want a different aspect ratio next week, you want to start from the decisions rather than re-derive them.

This generalises to any batch job: parallelise the work, serialise the checkpoints.

A detail that tells you the intent

transcribe caches to disk and skips when the output JSON is newer than the source.

That's a small implementation choice with a large implication: this tool expects to be re-run. Which means the pipeline is designed to be iterated on, not executed once. Re-running after a tweak costs nothing.

Tools tell you how they expect to be used, if you read the small decisions.

If you want to try it:

curl -s https://files.dlazy.com/cdn/cli | bash
dlazy -h

Start with a 10-minute recording rather than a 90-minute one. The pipeline shape is identical and you'll find out where your assumptions are wrong for a tenth of the wall-clock time.

Your coding agent can't see the video it just made

xiaodong Zhang — Mon, 24 Aug 2026 07:23:03 +0000

I spent a week letting an agent produce short video clips end to end. It reported success on every run. Roughly one in five was broken.

Not subtly broken. One had a two-second frozen frame in the middle. One had narration drifting a full second off picture by the end. Two had audible clicks at every splice point.

The agent had no idea. From its position, every step returned exit code zero.

The structural problem

An agent orchestrating video generation is working blind. It can:

call a generation model and get a file back
assemble an edit list
run ffmpeg
confirm each command exited cleanly

What it cannot do is watch the output. So "the third clip froze" is not a state it can reach.

This is different from how agents fail at code. A failing test is a signal the agent can read. A frozen frame is not — it's a property of pixels the agent never inspects.

Which means: without something to close the loop, you are the only quality gate. And that caps your throughput at what you can personally sit through.

What actually closes it

The thing that changed this for me was finding that the dlazy CLI ships validators that run locally against the rendered file — no model call, no generation cost:

validate_freeze            # frozen-frame intervals
validate_av_sync           # video ≈ audio ≈ subtitle duration coherence
validate_audio_pops        # pops at cut boundaries
validate_cut_boundaries    # per-cut pHash sampling on the render

Each maps to a failure mode that survives casual review:

validate_freeze — generated video stalls more often than people admit. A two-second freeze is easy to miss on a distracted first watch and impossible to miss once published.

validate_av_sync — a three-way duration check. Drift accumulates. 200ms off at the start is a second off at the end, and by then your narration is describing the previous shot.

validate_audio_pops — the thing that makes assembled audio sound amateur. Nearly invisible until it's on decent speakers.

validate_cut_boundaries — perceptual-hash sampling to catch cuts that landed somewhere other than intended. Off-by-one-frame errors in an edit list produce exactly this.

Why "local" is the load-bearing word

These don't call a model. Running them is effectively free.

That sounds like a minor cost note. It isn't — it changes when you run them.

A check that costs something gets run on the final version, if at all. A check that costs nothing gets run on every render — including the ugly intermediates, which is when the error is cheapest to fix.

Generalise it: the value of a check is a function of how often you're willing to run it, and that's mostly a function of what it costs. Cheap checks get run. Expensive checks get skipped exactly when you're under pressure, which is exactly when you need them.

Wiring it into the loop

The prompt shape that works:

After rendering, run the freeze, A/V sync and audio-pop checks.
If any fail, regenerate only the affected segment and re-check.
Report which checks ran and what they returned.

That last line is non-negotiable. An agent that says "done" without stating what it verified has told you nothing.

Once this is in place the loop actually closes: generate → validate → regenerate what failed → report. You review the summary, not the footage.

The honest limitation

These catch mechanical failures. Freezes, drift, pops, misaligned cuts.

They cannot tell you the video is boring, off-brand, or says the wrong thing.

That distinction is useful rather than disappointing — it tells you where to put your attention. Let the validators own the mechanical layer completely, and spend your review time on judgement, which is the part they can't touch.

The test for any tool in this space

Ask what it does after generation.

Most AI video tooling stops at the model call and hands you a file. That's fine for one clip. At any volume, the interesting engineering is entirely in the verification layer — and its presence or absence tells you whether someone actually shipped video at scale with this thing, or just demoed it.

Install is one line if you want to try it:

curl -s https://files.dlazy.com/cdn/cli | bash

Then dlazy -h for the tool list. I'd start with a throwaway clip and deliberately break it — generate something, then run the validators and confirm they actually complain. A check you haven't seen fail isn't a check you trust yet.

Batch Image Generation with Codex and dLazy: Build the Pipeline, Not a Prompt Loop

xiaodong Zhang — Fri, 21 Aug 2026 03:09:23 +0000

One product identity, four coordinated campaign settings
Generating one good product image is a creative task. Generating 100 good product images that look like they belong to the same catalog is a systems problem.
That is the useful idea behind dLazy's batch-image skill. It gives Codex an operator playbook: read a SKU manifest, keep one visual specification frozen, call the dLazy CLI once per SKU, save results under deterministic names, retry failures, and produce a report you can audit.
The key design choice: SKU count drives the batch. The CLI's --batch flag stays at 1, because increasing it creates extra generations for every SKU and multiplies spend.
The architecture in one screen

Batch-image execution pipeline from manifest to QA
Codex does not run the image model locally. The installed skill teaches Codex the workflow; the dLazy CLI sends prompts and image inputs to the hosted API; seedream-5.0 generates the asset; and --save downloads it to your project.
The skill states that prompts and parameters are sent to api.dlazy.com, local media inputs are uploaded to files.dlazy.com, and generated URLs are hosted there. Treat that as a normal cloud-processing boundary: do not submit assets you are not authorized to upload.
Install the skill and CLI
Ask Codex to install the skill from the repository path:
Install this Codex skill:
https://github.com/dlazyai/ecommerce-skills/tree/main/skills/batch-image
Codex skills use a required SKILL.md. If a downloaded repository uses lowercase skill.md, normalize the filename during installation. You can review the original batch-image skill and the official Codex skills documentation before running it.
Use the pinned CLI version declared by the skill:
npx @dlazy/cli@1.2.3 seedream-5.0 -h

or: npm install -g @dlazy/cli@1.2.3

dlazy auth set
Get the API key from the dLazy dashboard. Do not paste it into a manifest, prompt, repository, or article draft.
Start with one SKU
The model command is dlazy seedream-5.0. The skill recommends 2k, one consistent aspect ratio, and a deterministic output path.
dlazy seedream-5.0 \
--prompt 'Commercial ecommerce photo. Image 1 is the product: black polished leather derby shoe with a chunky lace-up sole. Preserve its color, material texture, silhouette, and construction. Place it in one fixed visual system: warm-white studio, soft top light plus left fill, 45-degree view, consistent lower-right shadow and whitespace. No text or watermark.' \
--images docs/batch-image/sku-b-shoes.jpg \
--size 1:1 --resolution 2k \
--save docs/batch-image/out/SKU002.jpg
Do this before you automate. A bad spec multiplied by 100 is still a bad spec—just more expensive.
Separate the prompt into variables and invariants
Every SKU gets a variable block: category, color, material, and structural details. Every run gets the same invariant block: background, lighting, camera angle, product occupancy, shadow direction, color grade, and output style.
VARIABLE — changes per SKU
Image 1 is the product: [category + color + material + structural details].
Preserve its color, texture, silhouette, and construction.

SPEC — byte-for-byte identical across the run
Warm-white studio; soft top light plus left fill; 45-degree view;
consistent product scale, margins, and lower-right shadow;
commercial product photography; no text; no watermark.
If you change the spec halfway through, you no longer have one batch. You have two visual systems.
Drive the run from a manifest
SKU001,docs/batch-image/sku-a-sweater.jpg,olive cable-knit crewneck sweater with a relaxed dropped shoulder
SKU002,docs/batch-image/sku-b-shoes.jpg,black polished leather derby shoe with a chunky lace-up sole
The reference implementation in the skill uses five parallel workers, three attempts with increasing delays, SKU-based filenames, and report.csv. Keep concurrency around four or five if rate limits appear.
mkdir -p docs/batch-image/out
SPEC='Warm-white studio, soft top light plus left fill, 45-degree view, consistent product scale, margins and lower-right shadow. Commercial product photography, no text, no watermark.'

run_one() {
IFS=, read -r SKU IMG DESC <<< "$1"
for attempt in 1 2 3; do
dlazy seedream-5.0 \
--prompt "Image 1 is the product: ${DESC}. Preserve its identity. ${SPEC}" \
--images "$IMG" --size 1:1 --resolution 2k --batch 1 \
--save "docs/batch-image/out/${SKU}.jpg" >/dev/null 2>&1 && break
sleep $((attempt * 10))
done
if [ -f "docs/batch-image/out/${SKU}.jpg" ]; then echo "${SKU},ok"; else echo "${SKU},fail"; fi
}
export -f run_one; export SPEC
xargs -P 5 -I{} bash -c 'run_one "{}"' < manifest.csv | tee docs/batch-image/report.csv
For large catalogs, add --no-wait, capture each generateId, then poll with dlazy status --wait. The asynchronous path prevents a terminal session from blocking on every job.
Estimate before you fan out
Use --dry-run to inspect the payload and estimated cost before executing:
dlazy seedream-5.0 --dry-run --prompt '...' --images a.jpg --size 1:1
wc -l < manifest.csv
The repository's example lists seedream-5.0 at 5 credits for a 1:1, 2K output, so 100 SKUs are illustrated as roughly 500 credits. Pricing can change; treat the CLI's current estimate as the source of truth. Reserve 4K for print work. The skill says gpt-image-2 costs about six times more, so use it selectively for fidelity failures rather than mixing models inside the initial batch.
QA is part of the pipeline
The recommended rollout is deliberately boring: one SKU, then five edge cases, then the full manifest. Sample dark, light, reflective, large, and small products. After the run, inspect the report and randomly review 10% of outputs.
Check identity, texture, color, product scale, margins, lighting, shadow direction, artifacts, text, and watermarks. If one subgroup needs gpt-image-2, rerun only those SKUs and record the exception in the report.
Failure modes worth engineering for
unauthorized: set the key with dlazy auth set and resume.
insufficient_balance: add credits before retrying.
Local file not found: validate manifest paths before launch.
Server or async failure: retry with backoff and preserve the failed SKU list.
Visual drift: freeze the invariant spec and rerun the entire affected batch.
Rate limiting: reduce concurrency to four or five.
Production checklist
1.Validate every input path and SKU identifier.
2.Lock one aspect ratio and 2k resolution for the batch.
3.Freeze the invariant prompt block.
4.Approve one SKU, then five boundary SKUs.
5.Run --dry-run and calculate the catalog total.
6.Execute with bounded concurrency, retries, and deterministic filenames.
7.Review report.csv; rerun only failed items.
8.Sample at least 10% for visual QA.
The scalable unit here is not a clever prompt. It is a reproducible job: manifest in, assets and report out. That is what makes batch-image useful inside Codex.

DEV Community: xiaodong Zhang

Geometry Locked, Material Variable: Building a Fabric-Swap Workflow for Garment Images

The hardest part of AI garment extraction is the shoulder you never saw

everything in the repo (19 skills)

or just what you need

or scope it to one agent

or

or per-invocation

Two prompt rules that sound like superstition. I A/B tested both — they hold

Setup

Test 1: does framing-term position matter?

Test 2: how much do realism clauses actually buy?

The chained-edit pattern

Language note

Cost discipline

What I take from this

When the product is 5% of the frame, the prompt problem inverts

The frame-share problem

Anatomy strings, not bounding boxes

The lock clause is not optional

Reference selection is stricter than for garments

Multi-view for complex geometry

Symptom mapping

Parameters

QC dimensions specific to this

Takeaway

The docs said unnamed items get dropped. I ran the A/B and couldn't reproduce it

The mechanism, as documented

The experiment

Result

So is the rule wrong?

What I would keep from the documentation anyway

Batch consistency

Practical notes

Takeaway

Batch-generating 100 product images is easy. Making them look like one set is not

The pattern

Does it hold?

The negative control

Orchestration

The gotcha nobody documents

Workflow order, and why it is not optional

Cost notes

Troubleshooting, condensed

Turning a flat-lay photo into an on-model shot with two prompt segments

The structure

--images order is load-bearing

Specificity is the whole quality lever

Symptom-driven add-ons

Input constraints worth validating before you spend credits

Reference selection drives everything downstream

Parameters

QC before you ship

I ran AI quality control on my own published work. It found what I missed

What it actually does

Running it

Test 1: the image I thought was fine

Test 2: the image I had captioned as a success

Test 3: control group

Closing the loop

The part that actually matters

One more finding

Operational notes

Would I use it

Where the money actually goes when you generate at scale

1. Iterate on the cheap tier. Always.

2. Front-load the local tools

3. Pilot every batch

4. Calibrate before generating narration

5. Validate every render, not just the final

6. Reference images instead of adjectives

7. Keep a manifest

The one I'd leave off the list

The pattern underneath

Front-load the free work — turning a 90-minute recording into short clips

Why the obvious way fails

Most of this work doesn't need a model

transcript_pack is the one that makes it viable

snap_to_words looks like a detail and isn't

The order that works

`--images` order is load-bearing

`transcript_pack` is the one that makes it viable

`snap_to_words` looks like a detail and isn't