Every build log I've published this summer describes a skill that reads something. The attribute audit reads a catalog. The review audit reads five star bands. The keyword expander reads a dropdown. This one is the first in the library that has to write something for two readers who want opposite things, and the honest version of this post is that the skill got one of those readers right and I'd now argue with how it handles the other.
The skill lives at ~/.codex/skills/amazon-machine-legible-infographic/. It is 981 words of SKILL.md and a 153-word reference file, dated May 31, 2026, which matters for reasons I'll get to. Its job is to take an ASIN or a source packet and produce a brief for one Amazon secondary image that a shopper can read at 280 pixels and an OCR pass can read at 2000, with every claim on the canvas traceable to a source. Optionally it generates the image.
The problem, and what it costs to do by hand
Two readers look at your infographic now. The shopper, with a thumb and about a second. And the machine layer, which includes Amazon's own assistant reading image text as context for which products belong in a consideration set, and increasingly a third-party agent doing the same thing off the rendered page. Nobody outside Amazon knows the weights on any of that, and anyone who quotes you a number invented it. What isn't in dispute is that on-image text is now extracted and used, and that the characteristics that make text fail for the shopper (hairline strokes, curved type, low contrast over a busy photo) are broadly the same ones that make extraction unreliable.
Done manually, briefing one machine-legible infographic properly takes a strategist about ninety minutes. Not the design, the brief. You have to pull the listing, transcribe the claims, decide which single buyer question this frame answers, find a source for every callout you're about to put in 60-point type, write the copy at a length that survives a sevenfold reduction, and specify a reading order that a model scanning the image top-to-bottom will get right. Most of that is transcription and lookup. The judgment is about fifteen minutes of it.
So the ninety minutes doesn't happen. What happens instead is a designer gets a benefit list and a brand deck, produces a four-icon grid with a headline like "Premium Quality You Can Trust," and the frame goes live making no claim either reader can use.
The build
Three files. No API key, no image service, no compositor.
The SKILL.md opens with the same autonomous browser capture block the review audit uses, with the same stop: if the listing is behind a CAPTCHA or a login wall, the skill halts and asks for screenshots or a source packet rather than going around the wall. Then it does the work in a fixed order, and the order is the product:
2. Identify the buyer question or AI-shopping visibility gap the image should answer.
3. Build a source-backed fact set for that image only.
4. Choose one image job:
- size/capacity clarity
- compatibility/fit clarity
- material/ingredient clarity
- use-case proof
- setup/care steps
- included components
- comparison/differentiation without competitor logos
5. Create an OCR-friendly copy map:
- headline
- 3-5 labels/callouts
- optional microcopy
- reading order
- source for each claim
Step four is the line I'd defend hardest. One image job. Handed a product and a canvas, a model will try to make the frame do everything, because everything is relevant and the canvas is large. The skill forces a choice from a closed list of seven jobs before any copy is written, and the list is a merchandising list, not a design list. There is no "brand story" job. There is no "lifestyle" job. Those are real frames, they just aren't this frame.
The copy map is where the two-reader constraint gets enforced. Every row carries the text, its purpose, its source, and a maximum character count. The reference file, ocr-friendly-image-rules.md, is short enough to quote in full on the text side:
- Use short direct phrases.
- Prefer plain sentence case or title case.
- Avoid curved, warped, rotated, vertical, or perspective-distorted text.
- Avoid very thin fonts, condensed fonts, outline-only text, and low contrast.
- Keep labels near the relevant product area.
- Use stable reading order: top-to-bottom, left-to-right, numbered steps,
or simple hub-and-spoke.
- Use one primary headline and 3-5 callouts.
And the visual rule that does more work than its length suggests: "Use icons only as support; text should carry the meaning." That sentence exists because the first thing every designer and every image model does with a benefit list is turn it into a row of icons with a two-word label under each. To a shopper at thumbnail scale an icon is a small grey shape. To an OCR pass it is nothing at all. The claim has to be words, in a weight that survives compression, or neither reader receives it.
The output template forces a fact table before anything else, and the column that matters is the last one:
| Fact | Source | Confidence | Use In Image? |
The whole point of a "Use In Image?" column with a source next to it is that the model has to say no to some facts. A fact with a Medium confidence and no source doesn't go on a 2000-pixel canvas in 80-point type, because a claim on an image is a claim on a live detail page, and the compliance categories are exactly the ones the reference file names: no certifications, badges, awards, review stars, prices, discounts, guarantees, or Amazon UI unless explicitly source-backed and allowed.
The generation constraint that isn't about quality
If you ask the skill to generate the image rather than just brief it, one paragraph governs how:
Use native Codex image generation only, including AI Image 2 when it is the image model exposed in Codex. Do not use OpenAI API, Gemini API, local image scripts, third-party image APIs, Figma, Canva, Photoshop, SVG, HTML, React, or a manual compositor for final image generation unless the user explicitly asks for a non-native production route.
That list is long on purpose. A model with a generation task and access to a shell will solve the task by whatever route produces an image, and the routes available to it include writing an HTML page and screenshotting it, calling an API it has a key for from some other project, or assembling the thing in SVG. All of those produce a 2000x2000 PNG. None of them produce the same PNG twice, and none of them produce an artifact whose provenance I can name when a client asks which model made it. Given what happened this summer with Imagen's API shutting down and a Chinese image model shipping with no version string at all, "which generator made this file" is a question I now want answered in the file, not reconstructed later.
The second half of the same section is the label I've written into every creative skill in the library:
If the generated asset has product or text fidelity issues, label it as concept work requiring production cleanup rather than production-ready final.
A generated infographic with a subtly redrawn label or a hallucinated certification mark looks fine at 280 pixels and is a compliance claim at zoom. The skill can't stop the model from making that mistake. It can stop the model from calling the result finished. AI generates direction, humans build finals. That line is the whole business model and it's written into the QA checklist as a checkbox.
What broke, read from the fossils
I don't keep run logs on this skill, so I'm not going to invent a dated war story. What I can do is read the file for the sentences that only exist because something went wrong, and there are two.
The first is the Use In Image? column itself. An early version had a fact table with sources and confidence but no explicit yes/no, and what came back was a copy map that used every fact in the table, because a fact in a table reads to a model like a fact that's been approved. The column made the omission a decision the model has to write down.
The second is the reading order requirement. Before it was explicit, the briefs described layouts that looked great described in prose and had no defined scan path. A human designer would have picked one. A model briefing a model doesn't, and an infographic with no reading order gets read in whatever order the extraction pass happens to tokenize it, which is not the order your argument was made in. "Stable reading order: top-to-bottom, left-to-right, numbered steps, or simple hub-and-spoke" is four options, and the skill has to pick one and name it in the brief.
What I'd change, and why the date matters
Here's the part I'd rather write than skip. The reference file says "one primary headline and 3-5 callouts." That line was written on May 31.
Since then I've spent most of July and August arguing, in print, that the standard secondary infographic fails because it distributes visual weight across four or five equal claims and therefore makes none. One winner at three to four times the size of everything else. Six callouts at equal weight is zero callouts. I believe that, I've watched it play out on real accounts, and my own skill file specifies a callout count that sits at the top of the range I'd now call the problem.
The two rules don't actually contradict, but the file doesn't say so, and a model reading it will produce a five-callout frame with a headline at roughly 1.5x, which is exactly the frame I audit brands out of. The fix is one sentence in the reference: the headline carries the frame's single claim at 3-4x the weight of any callout; callouts are supporting evidence, not co-equal claims. That sentence isn't in the file yet. It will be this week, and the point of saying so here is that a skill library is a snapshot of what you believed when you wrote it, and if your thinking moves faster than your maintenance, the skill will keep producing last quarter's position with this quarter's confidence.
There's a subtler version of the same tension. OCR genuinely does better with more text. A machine reader has infinite patience and perfect vision, and a frame dense with legible labels gives it more to extract. The shopper does not benefit from that at all. When the two readers disagree, the skill currently doesn't say who wins. It should: the shopper wins, because only one of the two readers buys anything. The machine layer gets the argument in the text fields (attributes, A+ body copy, alt text) where density costs nothing. The image gets one claim, big.
Cost, honestly
The workflow took an evening. The reference file took longer than the workflow, which is the fourth build log in a row where I've written that sentence, and I've stopped treating it as a coincidence. Per-run cost is a few dollars when it's briefing and a bit more when it's generating. There's no cron, no daemon, no unattended write path to anything. A human invokes it, a human reads the brief, a human decides whether the concept goes to a designer.
I'm not going to give you an hours-saved-per-month number across a nine-person team, because I don't have run logs and a made-up efficiency figure is exactly the thing I'd call out in somebody else's post. The narrow true version: ASIN to a sourced, single-job, reading-ordered brief with a copy map goes from about ninety minutes of a strategist's attention to a few minutes of it. The judgment about which of the seven jobs this SKU actually needs is unchanged and is the part I'm paid for. The justifying number sits on the other side: one infographic that ships with an unsourced "clinically tested" in 80-point type costs more than every minute the skill will ever save.
What you can replicate without any of my files
- Make the model choose one job from a closed list before it writes a word of copy. If you can't enumerate the jobs a frame can do, you're asking for invention, and invention isn't reviewable.
- Put a "Use In Image?" column next to every fact, with a source. The value is the facts the model has to say no to.
- Specify the reading order by name. A frame with no scan path gets read in the order the machine tokenizes it.
- Write "text carries the meaning, icons support" into the rule set. Every generator and every designer will turn a claim into an icon unless told not to.
- Name the generation route and forbid the alternatives explicitly. "Use X" is a preference; "do not use A, B, C, D, E, F, G" is a constraint.
- Ship the "concept requiring cleanup" label as a required output field. The model can't be prevented from redrawing a label. It can be prevented from calling the result final.
- Date your rules and re-read them when your thinking moves. My own file is three months behind my own published position. Yours is too.
The pattern across every one of these logs is the same and it's getting embarrassing to keep writing: the workflow is cheap, the constraint sentences are the product, and the expensive failures are the ones that come back beautifully formatted and confidently wrong about something nobody checked. This time the thing nobody checked was the author.