The Skill That Doesn't Do Anything: An Amazon Listing Pipeline Build Log

Every skill I've written up here does a job. The attribute fill-rate skill reads a table. The review audit goes and gets the evidence. The autocomplete expander reads a dropdown. The infographic skill writes for two readers. The rollout skill takes an approved stack and moves it across a colour family.

The one I want to talk about this week does not do a job. It sits at ~/.codex/skills/amazon-listing-pipeline, it is 10,639 bytes and roughly 1,455 words, I finished it on Monday, and its entire contribution is deciding what happens, in what order, and when to stop. Everything it actually produces is produced by something else.

That turns out to be a completely different engineering problem, and it introduced a failure mode none of the single-purpose skills had.

The problem: the package, not the asset

When a brand hands us a new product or a neglected ASIN, the deliverable is never one thing. It's a stack of documents that have to agree with each other:

• a product fact base (what is actually true, and where each fact came from)
• keyword and use-case research
• title and bullet direction
• an A+ copy brief
• an image stack brief
• a Q&A bank
• an attribute fill-rate report
• an AI shopping visibility audit
• a next-tests list

Done properly by people, that's two of us across most of a week, and a large share of that week is not thinking. It's transcription and reconciliation — copying specs out of a listing into a document, checking the bullet claim against the spec sheet, making sure the number in the image brief matches the number in the Q&A bank matches the number on the packaging.

I'm not going to hand you an hours-saved-per-month figure across the team. I don't keep run logs, and a made-up efficiency number is exactly the thing I'd call out in somebody else's post. The narrow true version: the assembly collapses and the judgment doesn't. Deciding which claim is safe to put on an image, which question deserves a frame, and whether a brand should ship any of this before January is unchanged, and it's the paid part.

The build: an orchestrator, not a tool

The file has no image generation in it, no copywriting rules, no OCR guidance. It has:

1. An input contract (source packet, or an ASIN/listing URL, plus optional review exports, spec sheets, packaging photos, competitor ASINs).
2. A capture step.
3. A twelve-step workflow producing eleven named files into one dated run folder.
4. A handoff table naming four other skills — amazon-image-stack-new, amazon-premium-one-pager-new, productpinion-main-image-lab, amazon-machine-legible-infographic — and the conditions under which each gets called.
5. Two gates that stop the run.

The capture step is deliberately narrow. Verbatim from the file:

Capture only visible information available through a normal browsing session. Do not bypass CAPTCHA, login prompts, bot checks, paywalls, access controls, or Amazon restrictions.

And when it does capture, every fact gets tagged as browser capture, user upload, export, or inference. That tag is not decoration. It's the thing that stops the rest of the chain from treating an inference as a spec — which matters more here than in any skill I've built, for a reason I'll get to.

The other rule worth quoting, because it's the one that makes an orchestrator different from a shortcut:

If product image references are insufficient for production fidelity, stop image generation, save the strategy artifacts, and list the exact missing references needed.

This is the first skill in my library with a stop condition in the middle of a run. Every other skill either completes or errors. This one is allowed to complete eight of twelve steps, refuse the last four, and write down why.

What the gate caught on a real run

A run from May 31 on a 24-pack of A19 LED bulbs (ASIN B0CZL9T5NQ). Fifteen files in the run folder, timestamps from 10:41 to 11:25. Production image mode was requested. The images/ folder is empty.

Here's what the pipeline wrote in image-production-report.md instead, verbatim:

Initial image generation stopped before final asset creation because only 679 px Amazon-gallery images were available.

679 pixels. That's the failure, and it's a failure the pipeline created for itself: the capture step pulls source images from the live Amazon gallery, which is the correct resolution for reading a listing and roughly a fifth of what you need for producing one. Same artifact, two incompatible requirements, and nothing in the first version of the file noticed the conflict.

More interesting is the "Assets Not Generated" table, because two of the three refusals are not about resolution at all:

Read the middle one again. Mirrored bullet wording. The pipeline was asked to build a listing package, it read the existing listing as its source, and it caught itself about to promote a claim whose only evidence was the listing it was rewriting.

That is the structural hazard of a chain that starts by reading a page and ends by writing one: the source document and the output document are the same document. Run it twice and an unsupported claim becomes an established fact with a provenance trail behind it, laundered one step at a time, and every artifact downstream will agree with every other artifact because they all inherited the same bad row. Ten documents that are internally consistent and wrong look exactly like ten documents that are right.

Two sentences in the file are all that stand between those two outcomes:

Separate "review theme" from "product fact".

Do not invent dimensions, materials, compatibility, certifications, ingredients, compliance attributes, medical claims, prices, awards, reviews, guarantees, or origin claims.

Plus the Fact | Source | Confidence | Notes table in the fact base template, which forces every downstream step to inherit a confidence rating rather than a bare string. That table is the cheapest thing in the skill and the only reason the LED run refused two images instead of confidently generating a certification mark for a claim nobody had substantiated.

What broke: the folder split

The other break is dumber and I'd rather write it down than tidy it away.

The output folder rule in the file reads:

~/Documents/aspi/amazon-research/ai-shopping/[ASIN or product-slug] - [YYYY-MM-DD]/

An OR in a naming rule is a fork. Here's what's actually on disk:

B0CZL9T5NQ - 2026-05-31/                            (files 10:49 – 10:56)
B0CZL9T5NQ-dalattin-24-pack-led-bulbs-2026-05-31/   (files 11:08 – 11:25)

B0BJ5VTPKZ - 2026-06-04/                            (files 13:42 – 13:53)
B0BJ5VTPKZ-rtic-32qt-ultra-light-cooler-2026-06-04/ (files 13:27 – 13:34)

Two runs, two ASINs, four folders. Both times the model resolved the OR one way, then resolved it the other way on continuation, and split one piece of work across two directories nineteen minutes apart.

The cost isn't disk space. Both B0CZL9T5NQ folders contain a file called ai-shopping-visibility-audit.md. They are different lengths and different versions. In six weeks nobody will be able to say which one is the deliverable, and there is a real chance somebody briefs a shot list off the earlier, thinner one because it's the folder that sorts first.

This is the same class of error as the coordinates problem in the autocomplete skill and the screenshot-frame problem in the rollout skill: the model did exactly what the file allowed, and the file allowed two things. The fix is not cleverness. It's removing the OR — one canonical folder name, ASIN-only, plus a run-manifest.md written first that lists the intended output files, so a resumed run has something to check itself against rather than a naming decision to re-make.

That fix is owed this week. I'd rather publish the skill with the bug named than quietly patch it and describe the tidy version.

The third thing, which isn't a bug

An orchestrator produces a feeling of completeness that a single-purpose skill never does.

When the attribute skill returns a table, you know what you're looking at: one output, one job, easy to distrust. When this thing returns eleven cross-referenced documents in a dated folder with a fact base at the front and a test plan at the back, it looks like a deliverable. It looks like the thing two people spent a week on. Every document agrees with every other document — which, as established above, is a property of the chain and not evidence of anything.

I don't have a rule in the file that fixes this, because I don't think it's a file problem. It's a reading problem, and mine. The practical guard I use: read the fact base last, not first. Read the outputs, form your view of the product, then go back to the Fact | Source | Confidence table and check whether the three things your view depends on are marked browser capture or inference. On the LED run, two of them were mirrored bullets.

Cost

An evening to write the orchestrator, on top of the four skills it calls, which took considerably longer. A few dollars of model spend per run. No cron, no daemon, no unattended write path — a human invokes it, a human reads the eleven files, a human decides what goes on a listing. The gates are advisory to me, not to Amazon.

The constraint sentences took longer than the workflow. That is now the fifth build log in a row where I've written that sentence, and I stopped treating it as a coincidence a while ago.

Six things to copy if you're building one

1. Write the stop conditions before the steps. An orchestrator without a mid-run stop is a machine for producing confident output from thin input. Mine has two: a fidelity gate before image production, and a missing-source list instead of an error.
2. Kill every OR in a path or a filename. Anywhere the file offers a choice, a resumed run will make the other one. Naming is not a style question in an automated pipeline; it's the only index you'll have in six weeks.
3. Write a run manifest first. The list of intended outputs, written before any of them exist, is what makes a partial run recoverable and a duplicate run detectable.
4. Tag every fact with where it came from, in the artifact. Not in the chat, not in the operator's memory — in the file, in a column, so it survives into every downstream document.
5. Watch for the source and the output being the same document. If your chain reads a listing to write a listing, reads a page to write a page, reads a spec sheet you don't control to write claims you're responsible for, then you need an explicit rule refusing to treat the input's assertions as evidence. Nothing about the output will look wrong when this fails.
6. Separate capture resolution from production resolution at the input stage. If the same asset serves both, one of the two jobs is silently getting a fifth of what it needs.

The close

The pattern across every one of these build logs has been the same: the workflow is the cheap part, the constraint sentences are the product, and the expensive failures come back beautifully formatted.

The orchestrator adds one line to that. A chain doesn't add capability — every capability in it already existed in a file I'd written months earlier. What a chain adds is confidence, and confidence is the one output you have to budget for, because nothing in eleven agreeing documents will ever tell you that all eleven inherited the same wrong row from the first one.

The most valuable thing the pipeline did on its first real run was refuse to make three images.