eCommerce skills for AI agents: why we open-sourced ours

eCommerce skills for AI agents are packaged domain knowledge: not an instruction on how to ship code, but a list of what actually needs checking in a store. That is why we published seedlight-skills, a set of nine MIT-licensed skills for Claude Code, Cursor and any other agent that reads its instructions from a file. Inside are three groups: catalog and feeds, store and visibility, and compliance, migration and deployment. Below we cover what each group does, how to install a single skill in your repository, which safety rules apply across all of them, and why we are giving this away instead of keeping it as an edge. If you are after shorter copy-and-paste prompts for everyday work, those live separately in our AI Library.

Most skills describe how to ship code, not what to check in a store

The public skill sets circulating on GitHub today mostly describe the software delivery cycle: how to plan a task, how to write a pull request, how to review, when to merge. That is a useful layer and we have nothing against it. The problem is what it leaves out. An agent guided by those instructions will write correct code, pass the tests and close the ticket, and still fail to notice that half the offers in the feed have no GTIN, that the ratings in your structured data are not backed by a single real review, or that a migration without a redirect map wipes out visibility the store spent three years earning. That is not the model failing, nor the developer. It is domain knowledge nobody gave the agent.

That knowledge is also boring, and it cannot be improvised mid-task: the title length limit in a specific channel, how the check digit in a GTIN is calculated, which missing fields will get an offer rejected, when a regulatory obligation starts to apply, the order of steps during a cutover. People accumulate it over years and keep it in their heads or in scattered notes. A skill is simply the place where that knowledge finally sits outside someone else’s head and can be handed to an agent in the same form every time.

Where the format comes from

The convention where a skill is a self-contained folder with a SKILL.md file was popularised by public skill sets, among them open-mercato/skills (MIT), which cover the generic software delivery cycle: plan, pull request, review, merge. Our set deliberately goes the other way: instead of guarding the process, it carries eCommerce knowledge. The two approaches do not compete, they complement each other. One watches how a change enters the repository; the other knows what to check inside that change so a sales channel does not reject the file and a search engine does not read the structured data as spam. In our projects they run side by side.

What a skill actually is

A skill is three things written into one file: packaged domain knowledge, a step-by-step procedure, and safety rules. Technically each of ours is a skills/skill-name folder with a SKILL.md file, installed on its own and independent of the rest. The file structure is identical everywhere: when to use it, arguments, prerequisites, workflow, report format, safety rules and limitations. That uniformity has a mundane purpose: once you have read one skill, you know where to look in the other eight.

The difference from a prompt pasted into a chat window is practical, not ideological. A prompt returns text you then have to move into your own file and judge yourself. A skill runs a procedure: the agent knows what input it needs, in what order to work, what it must not touch, and what the report at the end should look like. If you have not worked with an agent in the terminal yet, start with our guide to Claude Code in eCommerce, because these skills assume exactly that mode of work: on files, not in a chat window.

Nine skills in three groups

The split follows the moment in your work on a store when a skill is needed. The table is the short version; the detail for each group follows underneath.

The skills have no dependencies between them: take one and ignore the other eight.

Catalog and feeds

sl-catalog-audit walks a catalog export looking for what blocks sales later: duplicates, GTIN codes that fail their check digit, missing required fields, inconsistent variants, broken encoding and image problems. sl-catalog-normalize reduces the data to one format: units, colours, dimensions, slugs, attributes and category mapping. sl-feed-build builds and validates a feed for a specific channel (Google Merchant, Amazon, Allegro, Kaufland) and catches the offers the channel will reject before the file goes out, along with title length limits that differ per channel (Allegro 75 characters, Amazon around 200). The manual version of this work we covered step by step in the piece on cleaning a catalog CSV; the skill wraps the same process into a repeatable procedure with a report.

Store and visibility

sl-structured-data-audit checks schema.org (Product, Offer, AggregateRating, FAQ) and watches two things that are easy to miss: whether the JSON-LD says the same thing the user sees on the page, and whether ratings are backed by real reviews, because ratings without them are a structured data spam penalty risk, not a small inaccuracy. sl-ai-visibility-audit looks at how ready a store is to appear in AI answers: whether the content is reachable by bots at all, whether product and brand facts sit in the HTML rather than only in JavaScript, whether pages are quotable, and whether brand information is consistent across the places it appears. sl-checkout-audit walks checkout in ten points calibrated for the Polish market: BLIK, deferred payments, parcel lockers.

Compliance, migration, deployment

sl-compliance-2026 walks the obligations landing in 2026: the withdrawal function from Directive (EU) 2023/2673 (applying from 19 June 2026), PPWR from 12 August 2026 together with EPR registration, KSeF for Poland only, GPSR, the AI Act, Omnibus pricing rules and VAT OSS. One important caveat: the skill looks at the platform rather than the paperwork, and which of these duties apply to your store depends on what you sell, to whom, and which markets you ship to. It is a tool for scoping work, not a substitute for a lawyer. sl-migration-plan lays out a migration so you do not lose sales: the 301 redirect map, feature parity on day one, cutover and a rollback plan. sl-ship-check is the quality gate before a deploy and ends in a single decision: GO or NO-GO.

How to install it

Installation is deliberately primitive, because less machinery means fewer things to break. You clone the repository, copy the folder of the skill you want into .claude/skills in your repository (or into ~/.claude/skills if you want it in every project), and call it by name with the arguments described in the file. In other tools only the target path changes: the files are plain markdown with frontmatter, so any agent that can take instructions from a file will read them.

One piece of practical advice: run it for the first time on a copy of real data, not on the example from the documentation. That way the skill shows you not only what it can do, but also what your catalog or your product page really looks like, which is usually the more interesting part of the report.

Safety rules, or what the agent must not do

The most underrated part of a skill is not the list of steps but the list of prohibitions. An agent left with nothing but a goal can be helpful in the worst possible way: it will fill a missing GTIN with a plausible-looking digit, overwrite the original file, push the feed to the channel, because that was the point after all. So the same rules apply across all nine skills:

• Work on a copy of the data. A skill does not overwrite original files without explicit confirmation.
• No invention. Missing data is marked MISSING, contradictory data CONFLICT. Gaps are never filled with a value that merely looks credible.
• A human approves anything irreversible: production deploys, data migrations, pushing to a sales channel, deletions.
• Customer data stays with the customer. A skill does not send the catalog or personal data anywhere.
• A report instead of silent work. Every skill ends with a report: what was checked, what changed, what needs a human decision.

Why we are releasing this publicly

Three reasons, all mundane. First: a format like this only makes sense when it is shared. Skills locked inside our repository would be one more piece of internal documentation; as files anyone can copy, change and send back with a fix, they start to live their own life. Second: domain knowledge in eCommerce ages fast. Channel limits change, regulatory dates move, feed requirements evolve. A public repository gives us a chance that whoever spots an outdated limit before we do will simply correct it. Third, said plainly: if someone is wondering how we work, our procedures will tell them more than any deck.

Pull requests and issues are welcome, especially the boring ones: a channel limit we do not know about, a changed deadline, a checkpoint that lands differently in your store than in ours. We keep one organising rule: one skill is one task, installable on its own.

An AI agent will not replace knowledge about your store, but it stops requiring someone to repeat that knowledge on every task. That is the whole bet in these nine files: instead of explaining again what to check in a feed and what not to touch before a deploy, you hand over a procedure and get back a report with a list of decisions to make. We do the same work for clients in the AI Automation stage, only in a closed loop with their data and systems. The repository is public, the licence is MIT, and the most useful feedback we can get is that something in it does not behave in your store the way we described.