The problem started as a question I couldn't answer fast enough for a client: "Which of our attributes are actually missing, and which of the missing ones matter?"
Simple question. Brutal to answer by hand. A cabinet-hardware brand had 40-odd active ASINs, a rank slide on three of their best sellers, and no obvious cause — hero images were fine, reviews were fine, price was fine. My gut said the problem was invisible: thin backend attribute data in a category where Amazon's AI layer now filters on exactly that. But "my gut says check the attributes" is not a deliverable. Someone has to open the category listing report, line it up against the full category attribute taxonomy, and mark every field as populated, missing, weak, or not-applicable — per SKU. Then figure out which gaps a shopper or Rufus actually cares about, and draft real values without inventing anything Amazon will later flag.
Done properly by a human, that's 30-60 minutes per SKU. Across a catalog, it's a week of tedium nobody wants, so it never gets done. It's the exact shape of work I've started handing to Claude Code: high-volume, rule-heavy, judgment-light on the mechanics but easy to get dangerously wrong on the claims.
So I built a skill for it. This is the build log — the stack, the actual guardrails, the two things that broke, and what it costs to run.
Why this is worth automating in 2026 specifically
Two years ago, thin attributes cost you a filter chip on the left rail and not much else. That's changed, and it's the reason this went from "nice to have" to "revenue leak."
Amazon's search stack moved from lexical matching to semantic understanding — COSMO and Rufus reason about products, they don't just match keyword strings. And Rufus uses your structured attributes to filter the candidate set before the conversational ranking even happens. Miss the attributes for "will this fit a face-frame cabinet," and you're not ranked low for that question — you're not in the room when it's asked. Field data from Kenji ROI that I covered on July 7 put numbers on it: ASINs under 65% attribute completeness dropped an average of 4.2 organic positions in 21 days as the Listing Quality signal moved from advisory to enforcement. And current audits across brand catalogs keep landing at 30-40% attribute completion (SellerSprite's 2026 audit work and others report the same band). That's not a rounding error. That's most of the catalog invisible to the fastest-growing discovery path.
I'm not going to re-argue that case here — I made it in full in the listing quality enforcement post. The point for this build log is narrower: the diagnosis is now expensive to do by hand and expensive to skip. That's the sweet spot for an agent.
The build
It's a Claude Code skill — not a standalone app, not a cron job, not a hosted service. A skill is just a folder with an instruction file and a reference file that Claude Code loads on demand when I invoke it. That matters, because the whole thing is maybe 200 lines of instructions and one taxonomy reference. There's no model running at "runtime" on a schedule. I run it when I need it, against one ASIN or a batch.
The stack:
- Claude Code as the runner (Sonnet-tier model — this is rule-following work, not frontier reasoning).
- Browser / computer-use capture to pull the visible listing facts from a normal browsing session.
- A category attribute taxonomy as a reference file — the list of fields Amazon expects for the category (dimensions, material, compatibility, included components, power source, certifications, age range, country of origin, and the high-priority "answers a buyer question" fields).
- Optional Seller Central inputs — the category listing report or a flat file. This is the important fork, and I'll come back to it.
The core workflow the skill follows:
1. Capture listing evidence first (browser session, visible facts only).
Save it to disk BEFORE analysis: source-listing-capture.md + screenshots.
2. Decide the audit MODE:
- "Backend fill-rate" if a Seller Central export / flat file exists
- "Visible-data completeness" if only the public listing is available
3. Build a product fact base from listing + export + spec sheet + packaging + brand site.
4. Pull the expected attribute set for the category from the reference file.
5. Classify every attribute:
Populated | Missing | Weak/ambiguous | Unsupported | Not applicable
6. Draft missing values — but ONLY from source-backed facts.
7. Leave unsupported values blank, with a note on what source is needed.
8. Calculate fill-rate (backend) or a completeness estimate (visible).
9. Emit a Markdown report + a flat-file-ready CSV.
The CSV it produces is the actual deliverable — columns are attribute_name, current_value, draft_value, status, source, confidence, notes. That's the thing a cataloger can review and push. The Markdown report is for me and the client: an executive summary, a coverage table, and a ranked list of highest-value gaps.
Here's a real one. On June 24 I ran it against a live listing — DecoBasics 1/2-inch overlay matte black cabinet hinges, ASIN B08NV6S93X, #4 in Cabinet & Furniture Hinges at the time. The listing was good: overlay size, finish, self-closing, pack math, screws-included, steel construction — all clearly populated. What the audit surfaced was the edge-case compatibility layer sitting at zero coverage across every surface:
- Inset cabinet doors — will these work? Coverage: 0. Not answered in title, bullets, description, images, or attributes.
- Will these fit my existing screw holes? — Coverage: 0. One of the highest-friction install questions in the category. Silent.
- Do I need a hinge jig or special tools? — Coverage: 0.
- Are they adjustable after installation? — Coverage: 0.
- Frameless vs face-frame — populated but weak; the listing said what it is without ever saying what it's not for, which is where returns come from.
None of that is visible when you eyeball a listing and think "looks complete." It only shows up when something mechanically walks every expected attribute and every natural-language buyer question against the actual surfaces and scores the gap. That's the entire value of the tool: it doesn't get impressed by a pretty listing.
What broke
Two things, and both are the interesting part.
1. The first version confidently made things up. Early on, I pointed it at a supplement listing and it cheerfully drafted a "third-party tested" attribute and a country of origin — neither of which was anywhere in the source. It wasn't lying maliciously; it was pattern-completing. A model that has read a million supplement listings knows what usually goes in those fields, so it fills them in. On Amazon, a confidently-wrong certification or compliance attribute isn't a small error — it's a suppression risk and, in regulated categories, a real liability.
The fix was to make the guardrail the load-bearing part of the skill, not an afterthought. The claim rules now read, verbatim:
- Never invent dimensions, materials, compatibility, certifications, ingredients,
compliance attributes, medical claims, safety claims, age ranges, country of
origin, warranty, or included components.
- Do not infer regulated attributes from marketing language.
- If a value is likely but not proven, mark it `Needs source` and DO NOT put it
in the CSV draft value field.
That last line is the whole trick. A "likely" value and a "proven" value get sorted into different buckets, and only proven ones ever reach the column a human might push live. The confidence column and the source column exist so nothing lands in the catalog without a traceable origin. The lesson I keep relearning building these: for an agent that writes to a system of record, the constraint isn't a safety wrapper around the feature — the constraint IS the feature. A tool that fills 100% of fields fast is worthless if 15% of them are hallucinated. A tool that fills the 60% it can prove and flags the rest with what's needed is the one you can actually run.
2. It couldn't tell "I don't have the data" from "the data is missing." This is subtler and it nearly made the tool misleading. If you feed it only a public listing URL, it can see what's visible — but it cannot see the backend. A field can be fully populated in Seller Central and simply not rendered on the detail page. So a "visible completeness" number gets mistaken for a "backend fill-rate" number, and you go tell a client they're at 55% when their backend might be at 80%. That's a worse outcome than not running it — it's a confident wrong diagnosis.
The fix was the mode split baked into step 2. If there's a Seller Central export or flat file, it runs Backend fill-rate and reports a true number. If there's only public data, it runs Visible-data completeness and every output says so, in the header and in the caveat. Same skill, two honesty levels, never blurred. And when browser capture gets blocked by a login wall or a bot check, it's instructed to stop and ask for screenshots or an export rather than guess or try to bypass anything. An agent that knows the boundary of its own evidence is worth ten that confidently paper over it.
Time and cost
The honest accounting, because build logs that only report wins are useless.
Build time: an evening. Maybe three hours, most of it spent on the two failures above — the happy path was quick, the guardrails were the work. It's a skill, so there's no infrastructure, no deploy, no server to keep alive.
Run cost: a few dollars of model usage per ASIN on a Sonnet-tier model, plus the browser-capture step. Batch a catalog and it's still lunch money. There's no runtime cost when I'm not running it — nothing is sitting on a schedule.
What it replaces: 30-60 minutes of skilled human attention per SKU to do it properly — and "properly" is the catch, because the manual version is so tedious it usually gets done badly or not at all. On the DecoBasics run, the audit took a couple of minutes and surfaced ten ranked gaps I'd have needed a careful hour to find by hand, if I'd had the patience to find all of them, which I wouldn't have.
I want to be careful about what I'm claiming, because I've seen too many "AI saved my client six figures" build logs with invented numbers. I'm not going to hand you a rank-recovery figure for this client — attribution on a 60-day organic move with a dozen variables is exactly the kind of thing I'd call out as fake if someone else posted it. What I can tell you is real: the tool exists, it runs on live ASINs, it surfaces the specific zero-coverage attribute gaps that a good-looking listing hides, and the cost to run it is trivial next to the cost of one enforcement-driven rank slide on a hero SKU. The industry impact numbers I cited up top — 4.2 positions on sub-65% completeness, 30-40% catalog completion in the wild — are the case for why you'd want the diagnosis. The tool is just how you get it in minutes instead of a week.
What an operator could replicate
You don't need my skill folder. You need the pattern, and it's replicable this week if you run any catalog:
- Pick the one question you can't answer fast. Mine was "which missing attributes matter." Yours might be "which listings are below the completeness threshold" or "which SKUs contradict their own spec sheet." The narrower the question, the better the tool.
- Make the taxonomy explicit. The agent is only as good as the list of expected fields you hand it. Pull your category's attribute template and put it in a reference file. Don't make the model guess what "complete" means.
- Write the guardrails before the feature. For anything that could touch your live catalog, the first rule is never invent regulated or factual attributes, and the second is mark unproven values as needing a source and keep them out of the push-ready column. Build that before you build the part that drafts values.
- Separate "I can't see it" from "it's not there." If your inputs can't distinguish visible data from backend data, make the tool say which one it's looking at, every time. A confident wrong number is worse than a humble right one.
- Keep a human on the write. The output is a reviewed CSV, not an auto-push. The agent finds and drafts; a person approves what goes live. That gate is cheap and it's the difference between a tool you trust and a tool that eventually embarrasses you.
The bigger point: the leaks that are killing catalogs in 2026 aren't the visible stuff you can eyeball. They're the structured plumbing the AI layer reads and the human eye skips. That's precisely the work an agent is good at — walking every field, every SKU, without getting bored or impressed. Build the boring auditor. It'll find money your last creative refresh didn't.