CLAUDE.md Karpathy'ego, wyjaśnione: jeden plik stojący za wyszukiwaniem Skills

W Google Trends, na całym świecie, za ostatnie siedem dni i według odczytu z 23 października 2026 r., „karpathy skills” pojawia się jako rosnące zapytanie w ramach zapytania bazowego „claude skills”. Każdy, kto podąży za tym wyszukiwaniem, trafia w to samo miejsce: github.com/multica-ai/andrej-karpathy-skills — repozytorium, które 23 października 2026 r. miało 222 612 gwiazdek na GitHubie. Jego opis w ogóle nie zawiera słowa skill. Brzmi on: „Pojedynczy plik CLAUDE.md poprawiający zachowanie Claude Code, oparty na obserwacjach Andreja Karpathy'ego dotyczących pułapek kodowania z LLM”.

Przepaść między zapytaniem a obiektem nie jest drobnym szczegółem technicznym. Umiejętność i plik CLAUDE.md to różne mechanizmy, które wykonują różną pracę, a niemal każde twierdzenie, jakie ludzie formułują na temat tego repozytorium, albo zależy od wiedzy, który to z nich, albo po cichu zakłada niewłaściwy. Wskazówki w środku to pojedynczy plik. Repozytorium wokół tego pliku zawiera także manifest wtyczki i folder w katalogu skills, co prawdopodobnie jest źródłem słowa w pasku wyszukiwania. Oddzielenie opakowania od zawartości jest tutaj pierwszym użytecznym posunięciem.

Liczby, wszystkie z GitHuba i odczytane 23 października 2026 r.: 222 612 gwiazdek, 22 321 forków, utworzone 27 stycznia 2026 r., ostatni push 20 kwietnia 2026 r., licencja MIT. Ta ostatnia para jest ciekawa. Do repozytorium nie trafił żaden push od około sześciu miesięcy, a liczba gwiazdek mimo to nadal rosła.

Plik wykonuje pracę; opakowanie wyjaśnia wyszukiwane hasło.

Otwórz repozytorium, a lista plików pozwoli łatwo dostrzec niezgodność. W katalogu głównym znajduje się CLAUDE.md, a obok niego CURSOR.md, EXAMPLES.md, folder .cursor/rules zawierający te same wytyczne w postaci reguły projektu Cursor, folder .claude-plugin oraz katalog skills/karpathy-guidelines. Zalecana w README ścieżka instalacji to marketplace wtyczek, a opisany wynik sprawia, że „umiejętność jest dostępna we wszystkich Twoich projektach”.

Więc wyszukiwane hasło nie jest tyle błędne, ile nieprecyzyjne. Jest folder skills. Jest plugin. Nie ma natomiast zestawu osobnych skills, z których każdy wykonuje inne zadanie — a to zwykle ludzie mają na myśli, mówiąc „skill pack”: folder zawierający SKILL.md i wszelkie pliki pomocnicze potrzebne danej możliwości, wywoływany do jednego zadania. Tutaj cała instrukcja to jeden dokument stałych wytycznych, a plugin istnieje po to, aby dostarczyć ten dokument do projektu.

To, czy ta różnica ma dla Ciebie znaczenie, zależy od tego, czego chciałeś od wyszukiwania. Jeśli szukałeś zestawu narzędzi, to nim nie jest. Jeśli chciałeś krótkiego zbioru zasad, który zmienia sposób działania agenta kodującego w całym projekcie, to dokładnie tym to jest — i warto zrozumieć, dlaczego ktoś napisałby to jako plik, a nie jako umiejętności.

Skargi, przeciwko którym go napisano

Wskazanym w README źródłem jest post Andreja Karpathy'ego na X, który README cytuje w związku z trzema skargami na to, jak modele piszą kod. Warto przeczytać je w całości, ponieważ cztery zasady odpowiadają im niemal jeden do jednego.

Po pierwsze: modele „przyjmują błędne założenia w twoim imieniu i po prostu brną w nie bez sprawdzenia” oraz „nie radzą sobie z własnym zamieszaniem, nie szukają wyjaśnień, nie ujawniają niespójności, nie przedstawiają kompromisów, nie przeciwstawiają się, gdy powinny”. Zwróć uwagę na to, co jest opisywane. To nie jest skarga na błędne odpowiedzi. To skarga na płynne błędne odpowiedzi wygłaszane bez wahania, w których niepewność, która powinna była wywołać pytanie, zamiast tego wywołała pewny siebie kod.

Drugi: „naprawdę lubią komplikować kod i API, rozdymać abstrakcje, nie usuwają martwego kodu… tworzą rozdętą konstrukcję na ponad 1000 linii, gdy wystarczyłoby 100”. Ten przypadek jest znany każdemu, kto poprosił o funkcję, a dostał framework.

Trzeci jest subtelniejszy i, dla każdego przeglądającego diffy, najkosztowniejszy: nadal czasami zmieniają/usuwają komentarze i kod, których dostatecznie nie rozumieją, jako skutki uboczne, nawet jeśli są ortogonalne do zadania. Pojedyncza ortogonalna zmiana w jednym komentarzu jest sama w sobie mała. Pomnożona w całej bazie kodu sprawia, że kolejka przeglądów zapełnia się zmianami, o które nikt nie prosił, i że komentarz wyjaśniający obejście znika, zanim ktokolwiek dowie się, dlaczego to obejście istniało.

Cztery zasady i test, który każda z nich pozostawia

Plik koduje cztery zasady. Każda z nich ma krótki zestaw reguł, a dwie z nich podają jednowierszowy test, który można zastosować do diffa bez instalowania czegokolwiek. To w regułach ujawnia się charakter pliku.

Pomyśl, zanim zaczniesz kodować

Instrukcja w nagłówku brzmi: „Nie zakładaj. Nie ukrywaj zamieszania. Ujawniaj kompromisy”. Zgodnie z nią: wyrażaj założenia wprost i pytaj, zamiast zgadywać; przedstawiaj wiele interpretacji, gdy prośba jest niejednoznaczna; sprzeciwiaj się, gdy istnieje prostsze podejście; zatrzymaj się, gdy jesteś zdezorientowany, nazwij to, co niejasne, i poproś o wyjaśnienie. To jest wymierzone wprost w pierwszą skargę. Mechanizm nie polega na „zachowaniu większej ostrożności” — polega na zamienianiu cichych wyborów w widoczne, tak aby recenzent mógł się nie zgodzić, zanim powstanie kod, a nie dopiero po.

Prostota przede wszystkim

Zasada to minimalna ilość kodu, która rozwiązuje problem, bez niczego spekulacyjnego: żadnych funkcji wykraczających poza to, o co proszono, żadnych abstrakcji dla kodu jednorazowego użytku, żadnej elastyczności ani konfigurowalności, o którą nikt nie prosił, żadnej obsługi błędów w niemożliwych scenariuszach oraz „jeśli 200 linii mogłoby być 50, przepisz to”. Test to jedno pytanie — czy starszy inżynier powiedziałby, że to jest przekombinowane? — które jest kwestią oceny i to otwarcie.

Zmiany chirurgiczne

W tym miejscu plik dzieli instrukcję na dwie części, co jest w nim najbardziej przydatne. Podczas edytowania istniejącego kodu: nie ulepszaj sąsiedniego kodu, komentarzy ani formatowania; nie refaktoryzuj tego, co nie jest zepsute; dopasuj się do istniejącego stylu, nawet jeśli zrobiłbyś to inaczej; wspomnij o niepowiązanym martwym kodzie, zamiast go usuwać. Gdy Twoje własne zmiany tworzą sieroty: usuń importy, zmienne i funkcje, które Twoje zmiany uczyniły nieużywanymi, ale pozostaw wcześniej istniejący martwy kod w spokoju, chyba że poproszono inaczej. Test polega na tym, że każda zmieniona linia bezpośrednio wynika z żądania.

Realizacja ukierunkowana na cel

Zdefiniuj kryteria sukcesu i powtarzaj w pętli, aż zostanie to zweryfikowane. README pokazuje tę transformację jako pary. Zamiast „dodać walidację”, napisz testy dla nieprawidłowych danych wejściowych, a następnie spraw, aby przechodziły. Zamiast „naprawić błąd”, napisz test, który go odtwarza, a następnie spraw, aby przechodził. Zamiast „zrefaktoryzować X”, upewnij się, że testy przechodzą przed i po. W przypadku pracy wieloetapowej prosi o krótki plan, w którym każdy krok wskazuje własną weryfikację. README cytuje tu ponownie Karpathy’ego: „LLMs są wyjątkowo dobre w zapętlaniu, aż osiągną określone cele… Nie mów mu, co ma robić; podaj kryteria sukcesu i patrz, jak działa.”

Plik, umiejętność i wtyczka to trzy różne rzeczy

Warto być precyzyjnym co do samych mechanizmów, ponieważ praktyczne zachowanie bywa różne. CLAUDE.md to plik z instrukcjami projektu: tekst, który Claude Code odczytuje jako stały kontekst dla repozytorium, obecny niezależnie od tego, czy ktoś poprosił o niego w tej turze. Skill to folder z plikiem SKILL.md, który opisuje, kiedy dana możliwość powinna zostać użyta, ładowany wtedy, gdy zadanie tego wymaga, a nie wcześniej. Plugin to pakiet dystrybucyjny instalowany przez marketplace, który może zawierać skille, polecenia i inne komponenty. Te rozróżnienia dotyczą tego, kiedy instrukcje trafiają do kontekstu i kto o tym decyduje, a nie jakości.

CLAUDE.md jest w tym sensie najmniej subtelny z trzech. Jest zawsze włączony w tym projekcie, ma zastosowanie do każdego zadania w nim i zajmuje kontekst w każdej turze, niezależnie od tego, czy praca polega na poprawieniu literówki w jednej linii, czy na migracji. Własny README tego pliku przyznaje ten koszt w sekcji zatytułowanej Tradeoff Note: wytyczne skłaniają się ku ostrożności zamiast szybkości, a w przypadku trywialnych zadań — prostych poprawek literówek, oczywistych jednolinijkowców — należy kierować się osądem. Mówi się w nim, że celem jest ograniczanie kosztownych błędów w nietrywialnej pracy, a nie spowalnianie prostych zadań.

To rzetelny opis tego, co może zrobić stały plik instrukcji. Nie może dodać możliwości, której model nie ma. Może jedynie zwiększyć lub zmniejszyć prawdopodobieństwo wystąpienia istniejącego zachowania modelu. Dlatego plik jest napisany w formie ograniczeń — nie rób tego, zapytaj przed tamtym — a nie zachęty, by być lepszym.

Co mierzą 222 612 gwiazdy

Mierzą uwagę. To nie jest lekceważenie i nie jest to nic: repozytorium utworzone w styczniu 2026 r. i ostatnio wypchnięte w kwietniu osiągnęło 222,612 gwiazdek i 22,321 forków do 23 października 2026 r. na GitHubie, według stanu odczytanego tego dnia, co oznacza, że było szeroko udostępniane i forkowane przez osoby, które chciały mieć własną kopię. Liczba gwiazdek to rozsądne przybliżenie tego, ile osób uznało coś za warte zapisania w zakładkach.

To nie jest zastępczy miernik efektu, a repozytorium nie udaje, że jest inaczej. Czego nigdzie w nim nie opublikowano: żadnego benchmarku porównującego wyniki z plikiem i bez niego, żadnej metodologii pomiaru, czy działa, ani żadnego porównania z grupą kontrolną. Nie ma porównania przed i po na rzeczywistej bazie kodu, badania z recenzentami ani wskaźnika incydentów. Taki plik to hipoteza dotycząca zachowania modelu, elegancko sformułowana, i nikt nie przeprowadził próby.

To, co zamiast tego oferuje README, to sekcja zatytułowana „Jak poznać, że to działa”, w której wymieniono cztery rzeczy, które możesz zaobserwować: mniej niepotrzebnych zmian w diffach, mniej przepisywania z powodu nadmiernej komplikacji, pytania doprecyzowujące pojawiające się przed implementacją, a nie po błędach, oraz czyste, minimalne pull requesty. To rozsądne sygnały. Są też dokładnie tym, co napisałbyś, gdybyś niczego nie zmierzył, i pochodzą z samodzielnych deklaracji osoby stosującej ten plik. Czytaj je jako listę kontrolną, według której należy oceniać ten plik we własnym repozytorium, a nie jako dowód, że już przeszedł weryfikację.

Co tak naprawdę wpisujesz, aby to zainstalować

README opisuje dwie ścieżki. Zalecana działa w Claude Code: dodaj marketplace, a następnie zainstaluj wtyczkę; dzięki temu wytyczne są dostępne w projektach, a nie osobno w każdym repozytorium. Druga ścieżka jest na poziomie projektu: pobierz surowy plik CLAUDE.md do nowego repozytorium albo dopisz go do istniejącego. W repozytorium znajduje się też reguła projektu dla Cursor, więc te same wytyczne obowiązują po otwarciu folderu w Cursor — ten szczegół wskazuje, że plik napisano tak, by był przenośny między narzędziami czytającymi plik instrukcji na poziomie projektu, a nie przywiązany do mechanizmu ładowania jednego dostawcy.

Jeden zgrzyt, wart zaznaczenia, ponieważ na niego trafisz, jeśli będziesz ściśle postępować zgodnie z README. Polecenie marketplace wskazuje nazwę forrestchang/andrej-karpathy-skills, natomiast adres URL repozytorium na górze strony to multica-ai/andrej-karpathy-skills. Oba ciągi występują w tym samym README odczytanym 23 października 2026 r. Widzę tę niezgodność i nie potrafię powiedzieć, skąd się bierze, więc szczera rada jest taka, aby spróbować drugiej ścieżki, jeśli jedna zawiedzie, i uznać jeden z tych dwóch ciągów za nieaktualny.

Inna rzecz, na którą warto zwrócić uwagę na stronie głównej: repozytorium jest utrzymywane przez multica-ai, a otwierający README blok cytatu reklamuje Multicę jako „platformę open source do uruchamiania i zarządzania agentami kodującymi z umiejętnościami wielokrotnego użytku”. To uzasadnione ujawnienie, a zarazem wskazówka, dlaczego pakowanie wygląda tak, jak wygląda. Projekt zainteresowany umiejętnościami wielokrotnego użytku prawdopodobnie dostarcza własne wytyczne jako coś instalowalnego — i tym właśnie jest wtyczka.

Używanie go bez przejmowania jego założeń

Sekcja dostosowywania to część, którą większość czytelników pomija. Plik jest zaprojektowany do łączenia z instrukcjami specyficznymi dla projektu, a nie do zastępowania ich, a podane w nim przykłady są konkretne: używaj trybu strict TypeScript, wszystkie punkty końcowe API muszą mieć testy, stosuj istniejące wzorce obsługi błędów w określonym pliku. To nie jest ozdoba. To różnica między ogólnym zbiorem zasad a zestawem instrukcji, który wie, gdzie znajduje się Twój kod.

Istnieje praktyczny powód, aby scalać, a nie nakładać warstwami. Jeśli wkleisz plik w niezmienionej postaci, a Twój projekt ma własne konwencje, oba zestawy instrukcji mogą się ze sobą kłócić, a model godzący tę sprzeczność to dokładnie ta dezorientacja, którą pierwsza zasada stara się wyeliminować. Zapisanie własnych konwencji w tym samym pliku, tym samym głosem, utrzymuje powierzchnię instrukcji na tyle małą, by można ją było audytować.

I powinieneś go audytować. To krótki dokument instrukcji behawioralnych, który będzie dotyczył każdego żądania w repozytorium. Właściwe pytanie nie brzmi, czy 222 612 osób może się mylić — takie ujęcie niczego nie rozstrzyga — lecz czy każda reguła odpowiada awarii, którą faktycznie widziałeś. Jeśli twoje diffy nigdy nie zawierały przypadkowych przepisań komentarzy, sekcja „Surgical Changes” kosztuje cię kontekst bez powodu. Usuń ją. Plik jest na licencji MIT i ma być edytowany.

O poziom niżej nic z tego nie zmienia, który model odpowiada. Plik CLAUDE.md kształtuje sposób obsługi żądania, gdy już dotrze ono do modelu; nie mówi nic o modelu, który je otrzymuje. Ta druga decyzja należy do tego, co znajduje się przed modelem. Jednym ze sposobów zorganizowania tego jest pojedynczy punkt końcowy kompatybilny z OpenAI, obsługujący ponad 200 modeli pod jednym kluczem, z automatycznym przełączaniem awaryjnym między dostawcami i cenami katalogowymi dostawców przekazywanymi bez marży (0%). Hostujemy modele; nie tworzymy Claude Code i nic z Twojego repozytorium nie jest dla nas widoczne.

Wyszukiwarka będzie nadal mówić „skills”, bo to słowo, które ludzie mają na określenie czegoś, co instalujesz, żeby agent zachowywał się inaczej, a opakowanie tego repozytorium też go używa. Artefaktem jest plik: jeden dokument stałych instrukcji, napisany w odpowiedzi na trzy konkretne zarzuty, z czterema zasadami i zestawem testów, które możesz zastosować ręcznie. Oceń go po tym, czy te zarzuty brzmią jak Twoje repozytorium. To lepsze pytanie niż liczba gwiazdek, która zawsze mierzyła tylko, ile osób miało taką samą reakcję jak Ty przed chwilą.