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.
Top comments (0)