Skille eCommerce dla agentów AI: dlaczego wypuszczamy je open source

Skille dla agentów AI w eCommerce to spakowana wiedza domenowa: nie instrukcja, jak dowozić kod, tylko lista tego, co realnie trzeba sprawdzić w sklepie. Dlatego wypuściliśmy publicznie seedlight-skills, zestaw dziewięciu skilli na licencji MIT, do użycia z Claude Code, Cursorem i każdym innym agentem, który czyta instrukcje z pliku. W środku trzy grupy: katalog i feedy, sklep i widoczność, oraz zgodność, migracja i wdrożenie. Poniżej opisujemy, co dokładnie robi każda grupa, jak zainstalować pojedynczy skill w swoim repozytorium, jakie reguły bezpieczeństwa obowiązują w każdym z nich i dlaczego oddajemy to publicznie, zamiast trzymać jako przewagę. Jeśli szukasz krótszych promptów kopiuj-wklej do codziennej pracy, te zbieramy osobno w Bibliotece AI.

Większość skilli mówi, jak dowozić kod, nie co sprawdzić w sklepie

Publiczne zestawy skilli, które dziś krążą po GitHubie, w większości opisują cykl dostarczania oprogramowania: jak zaplanować zadanie, jak opisać pull request, jak zrobić review, kiedy scalić. To pożyteczna warstwa i nie mamy jej nic do zarzucenia. Problem jest w tym, czego w niej nie ma. Agent prowadzony taką instrukcją napisze poprawny kod, przejdzie testy i zamknie zadanie, a mimo to nie zauważy, że w feedzie brakuje GTIN w połowie ofert, że oceny w danych strukturalnych nie mają pokrycia w żadnej realnej recenzji albo że migracja bez mapy przekierowań skasuje widoczność, na którą sklep pracował trzy lata. To nie jest wina modelu ani programisty. To brak wiedzy domenowej, której nikt agentowi nie dał.

Ta wiedza jest przy tym nudna i nie da się jej wymyślić w trakcie zadania: limit długości tytułu w konkretnym kanale, sposób liczenia sumy kontrolnej w kodzie GTIN, lista pól, których brak spowoduje odrzucenie oferty, termin wejścia obowiązku regulacyjnego, kolejność kroków przy cutoverze. Człowiek zbiera to latami i trzyma w głowie albo w rozproszonych notatkach. Skill jest po prostu miejscem, w którym ta wiedza wreszcie leży poza czyjąś głową i da się ją podać agentowi w tej samej formie za każdym razem.

Skąd wzięliśmy format

Konwencję, w której skill to samodzielny katalog z plikiem SKILL.md, upowszechniły publiczne zestawy skilli, w tym open-mercato/skills (MIT), pokrywające generyczny cykl dostarczania oprogramowania: plan, pull request, review, merge. Nasz zestaw celowo idzie w drugą stronę i zamiast pilnować procesu, dowozi wiedzę o eCommerce. Te dwa podejścia się nie wykluczają, raczej uzupełniają: jedno pilnuje, jak zmiana wchodzi do repozytorium, drugie wie, co w tej zmianie sprawdzić, żeby kanał sprzedaży nie odrzucił pliku, a wyszukiwarka nie uznała danych strukturalnych za spam. U nas pracują razem w jednym projekcie.

Czym w praktyce jest skill

Skill to trzy rzeczy zapisane w jednym pliku: spakowana wiedza domenowa, procedura krok po kroku i reguły bezpieczeństwa. Technicznie każdy nasz skill to katalog skills/nazwa-skilla z plikiem SKILL.md, instalowany osobno i niezależny od pozostałych. Struktura pliku jest wszędzie taka sama: kiedy użyć, argumenty, wymagania wstępne, workflow, format raportu, reguły bezpieczeństwa i ograniczenia. Ta jednolitość ma banalny cel: po przeczytaniu jednego skilla wiesz, gdzie w pozostałych ośmiu szukać tego, co Cię interesuje.

Różnica wobec prompta wklejanego w okno czatu jest praktyczna, nie ideologiczna. Prompt zwraca tekst, który musisz sam przenieść do swojego pliku i sam ocenić. Skill uruchamia procedurę: agent wie, jakie dane musi mieć na wejściu, w jakiej kolejności pracuje, czego nie wolno mu ruszyć i jak ma wyglądać raport na końcu. Jeśli nie pracowałeś jeszcze z agentem w terminalu, zacznij od przewodnika po Claude Code w eCommerce, bo skille zakładają dokładnie taki tryb pracy: na plikach, nie w oknie rozmowy.

Dziewięć skilli w trzech grupach

Podział idzie za tym, w którym momencie pracy nad sklepem skill jest potrzebny. Tabela to skrót; szczegóły każdej grupy są pod nią.

Skille nie mają zależności między sobą: możesz wziąć jeden i zignorować osiem pozostałych.

Katalog i feedy

sl-catalog-audit przechodzi eksport katalogu i szuka rzeczy, które później blokują sprzedaż: duplikatów, kodów GTIN, które nie przechodzą sumy kontrolnej, braków w polach wymaganych, niespójnych wariantów, zepsutego kodowania i problemów z obrazami. sl-catalog-normalize sprowadza dane do jednego formatu: jednostki, kolory, wymiary, slugi, atrybuty i mapowanie kategorii. sl-feed-build buduje i waliduje feed pod konkretny kanał (Google Merchant, Amazon, Allegro, Kaufland) i wyłapuje oferty, które kanał odrzuci, jeszcze zanim plik pójdzie dalej, razem z limitami długości tytułu, które są w każdym kanale inne (Allegro 75 znaków, Amazon około 200). Ręczną odmianę tej pracy opisaliśmy krok po kroku w tekście o czyszczeniu katalogu CSV; skill zamyka ten sam proces w powtarzalną procedurę z raportem.

Sklep i widoczność

sl-structured-data-audit sprawdza schema.org (Product, Offer, AggregateRating, FAQ) i pilnuje dwóch rzeczy, które łatwo przeoczyć: czy JSON-LD mówi to samo, co widzi użytkownik na stronie, i czy oceny mają pokrycie w realnych recenzjach, bo ich brak to ryzyko kary za spam danych strukturalnych, nie drobna nieścisłość. sl-ai-visibility-audit patrzy na gotowość sklepu na widoczność w odpowiedziach AI: czy treść jest w ogóle dostępna dla botów, czy fakty o produkcie i marce siedzą w HTML, a nie tylko w JavaScripcie, czy strony da się cytować i czy informacje o marce są spójne między miejscami, w których występują. sl-checkout-audit przechodzi checkout w dziesięciu punktach skalibrowanych pod rynek polski: BLIK, płatności odroczone, automaty paczkowe.

Zgodność, migracja, wdrożenie

sl-compliance-2026 przechodzi obowiązki przypadające na 2026 rok: funkcję odstąpienia od umowy z Dyrektywy (UE) 2023/2673 (stosowanie od 19 czerwca 2026), PPWR od 12 sierpnia 2026 razem z rejestracją EPR, KSeF wyłącznie dla Polski, GPSR, AI Act, Omnibus cenowy i VAT OSS. Ważne zastrzeżenie: skill patrzy na platformę, a nie na dokumenty, i to, które z tych obowiązków dotyczą Twojego sklepu, zależy od tego, co sprzedajesz, komu i na jakie rynki wysyłasz. To narzędzie do przygotowania zakresu prac, nie zamiennik prawnika. sl-migration-plan układa migrację tak, żeby nie stracić sprzedaży: mapa przekierowań 301, parytet funkcji dnia pierwszego, cutover i plan wycofania. sl-ship-check jest bramką jakości przed wdrożeniem i kończy się jedną decyzją: GO albo NO-GO.

Jak zainstalować

Instalacja jest celowo prymitywna, bo im mniej mechaniki, tym mniej rzeczy do zepsucia. Klonujesz repozytorium, kopiujesz katalog wybranego skilla do .claude/skills w swoim repozytorium (albo do ~/.claude/skills, jeśli chcesz mieć go we wszystkich projektach) i wywołujesz go po nazwie z argumentami opisanymi w pliku. W innych narzędziach zmienia się tylko ścieżka docelowa: pliki to zwykły markdown z frontmatterem, więc czyta je każdy agent, który potrafi wziąć instrukcję z pliku.

Jedna rada z praktyki: pierwsze uruchomienie zrób na kopii realnych danych, nie na przykładzie z dokumentacji. Skill pokaże wtedy nie tylko, co potrafi, ale też jak wygląda Twój katalog albo Twoja karta produktu naprawdę, a to zwykle ciekawsza część raportu.

Reguły bezpieczeństwa, czyli czego agentowi nie wolno

Najbardziej niedoceniana część skilla to nie lista kroków, a lista zakazów. Agent zostawiony z samym celem bywa pomocny w najgorszy możliwy sposób: uzupełni brakujący GTIN prawdopodobnie brzmiącą cyfrą, nadpisze oryginalny plik, wyśle feed do kanału, bo przecież o to chodziło. Dlatego we wszystkich dziewięciu skillach obowiązują te same reguły:

• Praca na kopii danych. Skill nie nadpisuje oryginalnych plików bez wyraźnego potwierdzenia.
• Zero zmyślania. Brakujące dane oznaczane są jako BRAK, sprzeczne jako KONFLIKT. Luki nie zasypuje się wartością, która wygląda wiarygodnie.
• Człowiek zatwierdza to, co nieodwracalne: wdrożenie na produkcję, migrację danych, wysyłkę do kanału sprzedaży, kasowanie.
• Dane klienta zostają u klienta. Skill nie wysyła katalogu ani danych osobowych na zewnątrz.
• Raport zamiast cichej roboty. Każdy skill kończy się raportem: co sprawdzono, co zmieniono, co wymaga decyzji człowieka.

Dlaczego wypuszczamy to publicznie

Trzy powody, wszystkie prozaiczne. Pierwszy: taki format ma sens tylko wtedy, gdy jest wspólny. Skille zamknięte w naszym repozytorium byłyby kolejną wewnętrzną dokumentacją, a jako pliki, które ktoś może skopiować, zmienić i odesłać z poprawką, zaczynają żyć własnym życiem. Drugi: wiedza domenowa w eCommerce starzeje się szybko. Limity kanałów się zmieniają, terminy regulacyjne się przesuwają, wymagania feedów ewoluują. Publiczne repozytorium daje szansę, że ktoś, kto zobaczy nieaktualny limit przed nami, po prostu go poprawi. Trzeci, powiedziany wprost: jeśli ktoś zastanawia się, jak pracujemy, nasze procedury powiedzą mu o tym więcej niż jakakolwiek prezentacja.

Pull requesty i zgłoszenia są mile widziane, szczególnie te nudne: inny limit w kanale, którego nie znamy, zmieniony termin obowiązku, punkt kontrolny, który u Ciebie wypada inaczej niż u nas. Trzymamy przy tym jedną zasadę porządkującą: jeden skill to jedno zadanie, instalowalne samodzielnie.

Agent AI nie zastąpi wiedzy o Twoim sklepie, ale przestaje wymagać, żeby ktoś tę wiedzę powtarzał przy każdym zadaniu. To cała stawka w tych dziewięciu plikach: zamiast tłumaczyć od nowa, co sprawdzić w feedzie i czego nie wolno ruszyć przed wdrożeniem, podajesz procedurę i dostajesz raport z listą rzeczy do decyzji. Tę samą robotę wykonujemy u klientów w fazie AI Automation, tylko w zamkniętym obiegu z ich danymi i systemami. Repozytorium jest publiczne, licencja to MIT, a najbardziej przydatna informacja zwrotna to ta, że coś w nim nie działa u Ciebie tak, jak opisaliśmy.