---
title: "Repo Matta Pococka to dyscyplina inżynierska w Markdownskills"
source: "https://medium.com/@creativeaininja/matt-pococks-skills-repo-is-engineering-discipline-in-markdown-bbcc18a04ff5"
author:
  - "[[Kristopher Dunham]]"
published: 2026-06-07
created: 2026-06-15
description: "Historia tylko dla członków"
tags:
  - "clippings"
---
*Działa to, ponieważ przekształca typowe tryby awarii agentów kodujących w workflow, których agent nie może pominąć.*

![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*1sf-XpWL5z1XSmjUrNIP9A.png)

Większość bibliotek umiejętności agentów na GitHubie to ten sam artykuł w formie markdown. Ogólne porady owijają w YAML na froncie, dodają komendę slash na wierzch i wysyłają je. Agent je czyta i staje się nieco bardziej uprzejmy. Kod się nie zmienia.

Matt Pocock jest inny, a różnica jest warta szczegółowego rozłożenia na części. Repozytorium przekroczyło 100 000 gwiazd, co jest naprawdę rzadkością w przypadku zbioru plików Markdown, z niewielką ilością zwykłych maszyn startowych za nim. Ludzie to znaleźli, powiedzieli innym i rozprzestrzeniło się od dewelopera do dewelopera. Taki wzrost zwykle oznacza, że repozytorium trafiło w czuły punkt u deweloperów, którzy już odczuwali ból.`mattpocock/skills`

Oto teza, od razu: te umiejętności nie czynią modelu mądrzejszym. Sprawiają, że jest mniej lekkomyślnie. O to właśnie chodzi i warto go zachować podczas czytania reszty.

To jest rozbiórka tego, co faktycznie znajduje się w tych aktach. Nie chodzi o instrukcje instalacji. Nie chodzi o ramy. Rzeczywista treść proceduralna, którą agent czyta, gdy umiejętność się aktywuje. Skupię się na czterech umiejętnościach, bo to oni wykonują największą pracę:,,, i. Jeśli instalujesz tylko cztery umiejętności z tego repozytorium, zainstaluj te.`SKILL.md` `grill-with-docs` `tdd` `diagnose` `improve-codebase-architecture`

Zakładam, że masz jakąś znajomość pracy: że używałeś Claude Code lub Cursora w prawdziwej pracy, że wiesz, czym jest prompt systemowy i że odczułeś ból wypuszczenia agenta na dużą bazę kodu. Figura porusza się na tym poziomie.

## Czym właściwie jest repozytorium

Hasło Pococka brzmi: "Umiejętności dla prawdziwych inżynierów. Prosto z mojego katalogu.claude." To sformułowanie robi więcej roboty, niż się wydaje.

Część "prosto z mojego katalogu.claude" to ciekawa obietnica. To nie są umiejętności, które napisał do repozytorium. To umiejętności, które wykorzystuje przy pracy dla własnych klientów, lekko zredagowane dla odbiorców. Większość publicznych bibliotek umiejętności jest odtworzona przez inżynierię wsteczną. Ktoś czyta wpis na blogu o inżynierii promptów, pisze SKILL.md, który kodyfikuje porady i je promuje. W efekcie ta umiejętność działa w demach i rozpada się na prawdziwych bazach kodu, ponieważ nikt jej wcześniej nie używał.

Można rozpoznać Pococki, bo kodują tryby awarii, o których dowiadujesz się tylko po samodzielnym uderzeniu. Umiejętność jest paranoiczna wobec rozmnażania w sposób, który napisałby tylko ktoś, kto spalił wieczór na widmowym robaku. Umiejętność poświęca więcej słów ostrzegających przed poziomym cięciem niż opisującym refaktoryzację czerwono-zieloną. Umiejętność ta odrzuca metrykę własnego intelektualnego przodka (głębię jako stosunek Ousterhouta) na rzecz czegoś bardziej użytecznego. Nic z tego nie pochodzi z wpisów na blogu. To wynika z pracy.`diagnose` `tdd` `improve-codebase-architecture`

Druga cecha: shipuje te żenujące części. Jest umiejętność zwana umiejętnością, której celem jest sprawić, by agent przestał być tak gadatliwy, bo Pocock miał dość czytania "Oczywiście! Chętnie w tym pomogę. Oto co zrobię..." przed każdą odpowiedzią. Umiejętność deklaruje około 75% redukcji tokenów przez usunięcie tego wypełniacza. Nie piszesz umiejętności nazwanej tylko dlatego, że brzmi profesjonalnie. Piszesz to, bo problem jest prawdziwy.`caveman` `caveman`

## Umiejętność 1:, czyli dlaczego agenci budują niewłaściwe rzeczygrill-with-docs

Sam Pocock wskazuje to jako prawdopodobnie najpotężniejszą umiejętność w repozytorium. Ma rację, a powód jest strukturalny.

Domyślny tryb awarii agenta kodującego nie polega na tym, że pisze błędny kod. Chodzi o to, że pisze poprawny kod dla niewłaściwego problemu. Pytasz o "konta użytkownika z logowaniem e-mail", a agent tworzy działający system uwierzytelniania, który używa sesji zamiast JWT, usuwa konta na żądanie zamiast ich miękkiego usuwania i zwraca błędy w formacie, który nie pasuje do żadnego innego kodu. Każda linia przechodzi przez kontroler typów. Cała ta funkcja jest błędna.

`grill-with-docs` Istnieje po to, by to uniemożliwić.

Gdy umiejętność się aktywuje, agent ma zakaz kodowania. Jego jedynym zadaniem jest przeprowadzenie rozmowy kwalifikacyjnej. SKILL.md mówi prostym językiem: "Przeprowadź ze mną wywiady nieustannie na każdy temat tego planu, aż osiągniemy wspólne porozumienie. Przechodź każdą gałąź drzewa projektowego, rozwiązując zależności między decyzjami jedna po drugiej. Na każde pytanie podaj swoją rekomendowaną odpowiedź. Zadawaj pytania jedno po drugim, czekając na opinie na każde pytanie, zanim przejdziesz dalej."

To ostatnie zdanie naprawdę się sprawdza. Agenci uwielbiają zasypywać cię dwudziestoma pytaniami w jednej wiadomości. Odpowiadasz na łatwe trzy, ignorujesz resztę, a agent zaczyna przypuszczać o siedemnastu, które pominąłeś. Wersja Pococka wymusza serializację. Jedno pytanie. Twoja odpowiedź. Następne pytanie.

Głębszy ruch to to, co umiejętność robi z twoimi odpowiedziami. Zapisuje je do pliku wywołanego na końcu repozytorium oraz do architektonicznych rekordów decyzji (ADR) pod. Nie jako wysyp partii na końcu. Inline, gdy decyzje się krystalizują. SKILL.md jest w tym wprost: gdy termin zostanie rozwiązany, zaktualizuj to od razu. Nie rób ich na porcje. Łap je na bieżąco.`CONTEXT.md` `docs/adr/` `CONTEXT.md`

![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*0V4fzKrpQjHPS2ax9e1X-Q.png)

To ma znaczenie, ponieważ przy następnym rozpoczęciu sesji agent już czyta i wie, co oznacza "Order" w twojej domenie, dlaczego wybrałeś Postgres do modelu zapisu oraz jaką terminologię używa Twój zespół. Rozmowa nie musi się odbywać dwa razy. Budujesz wspólny język z agentem, który utrzymuje się przez sesje, tak jak stworzyłbyś go z nowym pracownikiem przez pierwsze trzy tygodnie.`CONTEXT.md`

Umiejętność jest też zdecydowana na temat tego, kiedy napisać ADR, co większość inżynierów niedostatecznie dokumentuje. Zasada Pococka: stwórz ADR tylko wtedy, gdy wszystkie trzy są prawdziwe:

1. **Trudno cofnąć.** Koszt zmiany zdania później jest znaczący.
2. **Zaskakujące bez kontekstu.** Przyszły czytelnik będzie się zastanawiał: "dlaczego zrobili to w ten sposób?"
3. **To efekt prawdziwego kompromisu.** Były prawdziwe alternatywy i wybrałeś jedną z konkretnych powodów.

Jeśli któregoś z tych trzech brakuje, pomiń ADR. To właściwa zasada. ADR są cenne właśnie dlatego, że są rzadkie. Repozytorium z 200 ADR ma ten sam problem co repozytorium z zerem.

Warto zwrócić uwagę na jedno ostre zachowanie: gdy używasz terminu sprzecznego z czymś już w, umiejętność nakazuje agentowi natychmiastowe przerwanie. Coś w stylu: "Twój słownik definiuje 'anulowanie' jako X, ale wydaje się, że masz na myśli Y. Który to właściwie?" Większość agentów po cichu przetłumaczy twój niejasny język na to, co uważa za najbliższe. Ta umiejętność sprawia, że za każdym razem zatrzymują się i zadają pytania.`CONTEXT.md`

## Umiejętność 2:, czyli Jak agenci źle wykonują testytdd

Prawie każdy agent zgodzi się pisać testy. Prawie żaden z nich nie napisze dobrych testów. To jest luka, którą trzeba zamknąć.`tdd`

Podstawowa zasada umiejętności jest jasno przedstawiona na początku: "Testy powinny weryfikować zachowanie za pomocą publicznych interfejsów, a nie szczegółów implementacji. Kod może się całkowicie zmieniać; Testy nie powinny."

To brzmi oczywistie. To nie jest naturalne zachowanie agentów.

Pozostawiony w spokoju agent pisze testy, które wyglądają na szczegółowe, ale w rzeczywistości obciążają strukturę wewnętrzną. To będzie wyśmiewać bazę danych. Będzie szpiegował prywatne metody, by potwierdzić, że zostały wezwane. On będzie asygnował na kształt pośrednich struktur danych, które istnieją tylko dzięki obecnej implementacji. Zestaw testów przechodzi. Następnie refaktoryzujesz jedną wewnętrzną funkcję i czterdzieści testów zmienia kolor na czerwony, mimo że zachowanie systemu się nie zmieniło.

SKILL.md Pococka nazywa to wprost: "Złe testy są powiązane z implementacją. Imitują wewnętrznych współpracowników, testują prywatne metody lub weryfikują za pomocą zewnętrznych środków (np. zapytując bezpośrednio bazę danych zamiast korzystać z interfejsu)."

Diagnoza, którą ci podaje, to jedno zdanie i warto ją zapamiętać: "Twój test psuje się podczas refaktoryzacji, ale zachowanie się nie zmieniło. Jeśli zmienisz nazwę funkcji wewnętrznej i testy się nie powiedzą, te testy były testem implementacji, a nie zachowania."

Tak to wygląda w praktyce. Agent pozostawiony sam sobie pisze test po lewej stronie. Umiejętność ta kieruje go w stronę testu po prawej:`tdd`

```c
// Implementation-coupled (brittle)
test("checkout", () => {
  const cart = new Cart();
  cart._items.push({ id: 1, price: 10 }); // reaches into private state
  const spy = jest.spyOn(cart, "_calculateTax"); // asserts on internals
  cart.checkout();
  expect(spy).toHaveBeenCalled();
});
```
```c
// Behavior-focused (survives refactors)
test("user can checkout with a valid cart", () => {
  const cart = new Cart();
  cart.add({ id: 1, price: 10 });
  const receipt = cart.checkout();
  expect(receipt.total).toBe(11); // asserts on the observable outcome
});
```

Test po lewej stronie psuje się w momencie, gdy zmieniasz nazwę lub strukturę przechowywania przedmiotów, mimo że checkout nadal działa idealnie. Test po prawej się psuje tylko wtedy, gdy wypłacenie faktycznie się zepsuje. To jest cały rozróżnienie i to właśnie agenci domyślnie się mylą.`_calculateTax`

Druga połowa umiejętności polega na tym, jak agent rozłoży swoje tempo. Pocock nazywa się specyficznym antywzorem "poziomym cięciem". To dzieje się, gdy agent decyduje się być dokładnym i najpierw napisać wszystkie testy, a potem wszystkie implementacje:

```c
WRONG (horizontal):
RED: test1, test2, test3, test4, test5
GREEN: impl1, impl2, impl3, impl4, impl5
```
```c
RIGHT (vertical):
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
RED→GREEN: test3→impl3
```

Powód, dla którego poziome cięcie zawodzi, ma świetną nazwę w SKILL.md: "Wyprzedzasz reflektory, zobowiązując się do testowej struktury zanim zrozumiesz implementację."

![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*sghUrzoX_eV7jRL0tgcYUg.png)

Dokładnie tak. Gdy agent pisze pięć testów zanim pojawi się jakikolwiek kod, przewiduje, co implementacja będzie musiała ujawnić. Te prognozy są dopasowane wzorcami z danych treningowych, a nie wynikają z Twojego konkretnego problemu. Następnie pisze implementacje spełniające testy, nawet gdy testy wymagają niewłaściwego kształtu. Kończysz z funkcjonującą funkcją, której kontrakt został ustalone przez poprzedniego modela, a nie przez ciebie.

Pionowe cięcie rozwiązuje to, sprawiając, że każdy test reaguje na to, co ujawnił poprzedni cykl. Test pierwszy czegoś cię uczy. Implementacja pierwsza wychodzi na wydanie. Test drugi jest ukierunkowany na to, czego się właśnie nauczyłeś. Agent pozostaje w świetle reflektorów.

Umiejętność ta wyraźnie określa, co sprawia, że nazwa testu jest dobra. Dobry test brzmi jak specyfikacja: "użytkownik może dokonać zamówienia z ważnym koszykiem" mówi dokładnie, jaka funkcja istnieje. Porównaj to ze stylem domyślnym agenta, gdzie testy nazywane są na przykład. Pierwsza opisuje zachowanie. Druga opisuje implementację. Pocock chce pierwszego.`test_checkout_handler_returns_200_when_cart_items_have_quantity_greater_than_zero_and_user_is_authenticated`

Ta umiejętność uważam za najbardziej niedocenianą. Większość inżynierów skupia się na umiejętnościach operacyjnych, bo są bardziej dramatyczne. to ta, która zwraca się przez lata, zmniejszając długoterminowe koszty utrzymania każdej funkcji, którą wysyłasz.`diagnose` `grill-with-docs` `tdd`

## Umiejętność 3:, czyli Debugowanie jako maszyna stanówdiagnose

`diagnose` to umiejętność, która sprawia, że agenti kodowania przestają być frustrujący, ale naprawdę przydatni, gdy coś jest zepsute.

Domyślne zachowanie debugowania przez agentów jest dobrze znane i upokorzenie. Zgłaszasz błąd. Agent czyta plik, zgaduje, co się stało, coś edytuje, uruchamia testy. Jeśli przejdą, ogłasza zwycięstwo. Jeśli się nie zda, zgaduje ponownie. Po pięciu czy sześciu rundach tego nie masz pojęcia, co było naprawdę nie tak, nie masz pojęcia, czy błąd został naprawiony, a kod zgromadził trzy drobne zmiany, których indywidualne uzasadnienie zostało już zapomniane.

`diagnose` zastępuje to maszyną stanów: reprodukuj → minimalizuje → hipotezuje → instrument, → naprawia → test regresji.

![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*RW48VbDykaDCSQ79pqI2zA.png)

Cała umiejętność opiera się na jednej zasadzie, którą SKILL.md wypowiada z niezwykłą siłą. Jeśli masz szybki, deterministyczny, możliwy do działania agentowi sygnał pass/fail dla błędu, znajdziesz przyczynę. Podzielenie, testowanie hipotez i instrumentacja po prostu konsumują ten sygnał. Jeśli go nie masz, żadne wpatrywanie się w kod cię nie uratuje. Wkładaj tu nieproporcjonalnie dużo wysiłku.

To cała umiejętność w trzech zdaniach. Wszystko inne jest mechaniczne.

Co to oznacza w praktyce: agent nie może modyfikować żadnego kodu produkcyjnego, dopóki nie będzie mógł odtworzyć błędu na polecenie. Nie "Myślę, że widzę, co jest nie tak, pozwól, że spróbuję coś naprawić." Nie "wygląda na to, że to może być stan rasowy, dodam mutex." Po pierwsze, zbuduj reprodukcję. Niezdający test, skrypt curl, jednolinijkowe powtórzenie w REPL. Coś, co agent może uruchomić, by za każdym razem pojawił się błąd.

To brzmi oczywistie. To najczęściej łamana zasada w debugowaniu przez agentów, a to naruszenie sprawia, że trzydziestominutowy błąd staje się trzygodzinny.

Umiejętność wyraźnie opisuje sytuację, gdy rozmnażanie nie jest możliwe: "Zatrzymaj się i powiedz to wprost. Wypisz, co próbowałeś. Poproś użytkownika o: (a) dostęp do środowiska, które je odtwarza, (b) przechwycony artefakt (plik HAR, zrzut logów, zrzut rdzenia, nagranie ekranu ze znacznikami czasu) lub © pozwolenie na dodanie tymczasowej instrumentacji produkcyjnej. Nie przystępuj do hipotez bez pętli."

Przeczytaj to dwa razy. Umiejętnością jest nauczenie agenta, by *eskalował do człowieka*, gdy nie może robić postępów, zamiast dalej się miotać. To właśnie robią starsi inżynierowie, a tego nie robią młodsi inżynierowie (i większość agentów). Eskalacja nie jest porażką. To właściwy ruch.

W fazie hipotezy kryje się druga zasada, którą warto podkreślić. Agent musi wygenerować kilka hipotez rankingowych *przed* zmianą jakiegokolwiek kodu, a następnie dodać instrumentację, aby potwierdzić, która jest odpowiednia, *przed zastosowaniem* poprawki. Kusi, zawsze, jest przeskoczenie od "widzę błąd" do "naprawię go". Ta umiejętność sprawia, że agent najpierw udowadnia swoją teorię.

W przypadku błędów niedeterministycznych (tych, które pojawiają się raz na pięćdziesiąt), umiejętność instruuje agenta, aby traktował problem jako "zwiększenie wskaźnika reprodukcji do czasu debugowania". Nie próbujesz naprawić błędu. Starasz się, żeby zdarzało się to wystarczająco często, by się dało. To znowu dokładnie prawda i dokładnie to, czego młodsi inżynierowie nie robią.

## Umiejętność 4:, ta, którą większość ludzi ignorujeimprove-codebase-architecture

To jest niedoceniona część kolekcji i prawdopodobnie najbardziej ambitna. Operacjonalizuje on *filozofię projektowania oprogramowania* Johna Ousterhouta jako coś, co agent faktycznie może uruchomić na twoim repozytorium.

Dla osób, które nie czytały książki: centralnym twierdzeniem Ousterhouta jest to, że dobre moduły są "głębokie". Moduł głęboki ma mały interfejs, który ukrywa wiele zachowań. Płytki moduł ma interfejs niemal tak złożony jak jego implementacja, co oznacza, że abstrakcja nie zasługuje na swoje życie. Lepiej byłoby go włożyć w linię.

![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*Vu6_0xWhARGRmCpnS18RTA.png)

Większość prób zastosowania tej idei kończy się niepowodzeniem, ponieważ błędnie definiują "głębię". Ousterhout czasem opisuje głębokość jako stosunek linii implementacyjnych do linii interfejsu, co jest kuszącym wskaźnikiem, bo można go obliczyć. Repozytorium Pococka wyraźnie to odrzuca. Z pliku LANGUAGE.md: "Głębokość jako stosunek linii implementacyjnych do linii interfejsu (Ousterhout): nagradza wypełnianie implementacji. Zamiast tego używamy głębi jako dźwigni."

To naprawdę ważna krytyka. Jeśli zoptymalizujesz stosunki linii, agent doda implementację, by zagłębić się w szczegóły. Pocock zastępuje to "głębią jako dźwignią", czyli ile zachowań dzwoniący może wykazać na jednostkę interfejsu, której musi się nauczyć. Moduł jest głęboki, gdy dzwoniący (i testy) wyciągają dużo kilometrów z bardzo małej powierzchni. To definicja behawioralna, a nie strukturalna.

Umiejętność ta wymusza określony słownictwo, którego agent musi używać podczas proponowania refaktoryzacji: moduł, interfejs, implementacja, głębokość, szw, adapter, dźwignia. SKILL.md bardzo się tego nalega. Spójny język to sedno. Agent jest instruowany, by nie przechodził do "component", "service", "API" ani "boundary". Jeśli kiedykolwiek czytałeś sugestie refaktoryzujące przez agentów i poczułeś, jak oczy się szkliły, bo używają sześciu różnych słów na to samo, to właśnie dlatego.

Ruch diagnostyczny nazywa się "testem delecji". Jeśli podejrzewasz, że każdy moduł jest płytki, zapytaj: czy usunięcie go skoncentrowałoby złożoność, czy po prostu przesunęło? Jeśli usunięcie go koncentruje złożoność w znaczącej nowej abstrakcji, moduł zasługuje na swoje miejsce. Jeśli usunięcie tego tylko przenosi ten sam kod gdzie indziej, to był płytki i można go zmontować.

Umiejętność klasyfikuje także zależności w sposób określający sposób testowania modułu pogłębionego. Czysta obliczenia pogłębiają się trywialnie. Zależności z lokalnymi zastępstwami testowymi (PGLite dla Postgres, systemy plików w pamięci) pogłębiają się, gdy zastępstwo działa w pakucie. Zależności na granicy sieci wymagają zdefiniowania portu na szwie i wstrzyknięcia transportu jako adaptera. To architektura portów i adapterów wykonana na poziomie szczegółowości pojedynczej refaktoryzacji, przy czym agent automatycznie wykonuje klasyfikację.

Efektem jest ponumerowana lista "pogłębiających się możliwości" uszeregowana według dźwigni. Umiejętność ta wyraźnie wskazuje, że nie proponuje jeszcze interfejsów. Przedstawia kandydatów i pyta, które z nich warto zbadać. Wybór kandydata wciąga cię w intensywną rozmowę o projekcie interfejsu. Ta etapowa interakcja zapobiega agentowi przed przepisywaniem połowy twojego kodu podczas parzenia kawy.

Uruchamiaj tę umiejętność co kilka dni na kodzie, który szybko się rozwija przy wsparciu agenta. Znajdziesz tam zgniliznę. Entropia architektoniczna to cichy podatek od rozwoju wspomaganego przez AI, i to jedyna publiczna umiejętność, jaką osobiście widziałem, że porusza ten temat w ten sposób.

## Co wyróżnia to repozytorium

Odchodząc od indywidualnych umiejętności, jest wzór wart wymiany.

Każda z tych umiejętności koncentruje się na określonym trybie awarii, który wynika z interakcji między zachowaniem agenta a pracą inżynieryjną. To nie są "najlepsze praktyki w formie cenowej". Są środkami przeciwdziałającymi przewidywalnym błędom agentów.

`grill-with-docs` Istnieje dlatego, że agenci pomijają wyrównanie. Istnieje dlatego, że agenci piszą testy dopasowania wzorców. Istnieje, ponieważ agenci zgadują. Istnieje, ponieważ czynniki przyspieszają entropię. Każda umiejętność nosi nazwę od wykonywanej pracy, ale tak naprawdę każda nosi nazwę problemu, którego zapobiega.`tdd` `diagnose` `improve-codebase-architecture`

Warto też zauważyć: żadna z tych umiejętności nie ma na celu uczynienia agenta mądrzejszym. Sprawiają, że agent jest bardziej zdyscyplinowany. To rozróżnienie jest całym sensem repozytorium. Instalacja ich nie otrzymuje automatycznie wyników starszego inżyniera. Otrzymujesz coś bliższego procesowi starszego inżyniera: wolniejsze zgadywanie, ostrzejsze pytania na początku, bardziej zwarte pętle sprzężenia zwrotnego i znacznie mniej losowych poprawek. Jakość efektu wynika z procesu, a nie z umiejętności machania różdżką nad modelem.

Jest też szczerość w repozytorium, która jest rzadka. README rozpoczyna się zdaniem: "Te umiejętności są zaprojektowane tak, aby były małe, łatwe do adaptacji i łatwe do składania." To nie jest marketing. Umiejętności są naprawdę niewielkie. Możesz przeczytać SKILL.md w trzy minuty. I naprawdę są kompozycyjne. Możesz zainstalować trzy i zignorować szesnaście. Nie ma blokady frameworka. Nie wierzysz w filozofię rozwoju agenta Pococka. Zbierasz cztery lub pięć plików Markdown, które kodują konkretne praktyki inżynierskie.

## Jak właściwie tego używać

Jeśli wyciągniesz jedną rzecz z tego artykułu, weź na to taką: przeczytaj pliki przed ich instalacją.`SKILL.md`

Każde z nich to kilkaset słów. Wszystkie cztery, które omówiłem, możesz przeczytać w piętnaście minut. Instrukcje w środku są krótkie, konkretne i napisane najpierw dla ludzi, a dopiero potem dla agentów. Nauczysz się rzeczy, czytając je, czego nie nauczyłbyś się instalując je. Umiejętności te są także mistrzowską lekcją pisania skutecznych instrukcji dla agentów. Jeśli kiedykolwiek miałeś problem z tym, by kod Claude'a lub kursor działały spójnie, te pliki są najlepszym publicznym przykładem, jaki widziałem, jak to zrobić.

Rozsądne ustawienie początkowe: zainstaluj,, oraz. Uruchom raz w repozytorium, żeby podłączyć konfigurację. Używaj ich przez dwa tygodnie. Potem dodaj i uruchamiaj co kilka dni. Pomiń wszystko inne, dopóki nie będziesz miał konkretnego powodu, by to dodać.`grill-with-docs` `tdd` `diagnose` `setup-matt-pocock-skills` `improve-codebase-architecture`

Oto cały cykl dotyczący jednej funkcji, od początku do końca:

1. Uruchom przed napisaniem jakiegokolwiek kodu. Odpowiadaj na jego pytania szczerze.`grill-with-docs`
2. Pozwól, by zapisał twoje decyzje i wszelkie ADR na bieżąco.`CONTEXT.md`
3. Buduj funkcję z aktywnym, pionowym kawałkiem na raz.`tdd`
4. Sięgać po niego tylko wtedy, gdy coś się zepsuje, i pozwól mu zbudować replikę, zanim dotknie naprawy.`diagnose`
5. Biegnij po lądowaniu cechy, żeby złapać zgniliznę zanim się zachowuje.`improve-codebase-architecture`

To wszystko. Pięć kroków, cztery umiejętności i funkcja, która wychodzi z drugiej strony, jest zgodna, przetestowana, poprawnie debugowana i architektonicznie uczciwa.

Jeśli chcesz ocenić, czy to dla ciebie, przeprowadź tę pętlę raz na czymś małym. Jeśli końcowy kod wydaje się znacząco lepszy niż zwykle, masz odpowiedź. Jeśli czujesz to samo, umiejętności cię nie uratują i masz inny problem do rozwiązania.

Repozytorium będzie się dalej rozwijać. Pocock shipuje regularnie, a liczba umiejętności stale rośnie. Ale te cztery opisane tutaj to te nośne. To one były te nośne, gdy repozytorium miało dziesięć umiejętności. I tak będą te nośne, gdy będzie pięćdziesiąt. Zacznij od nich, nabierz w nich dobrego tempa, a resztę pozwól, by się kumulowała w razie potrzeby.

![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*v_SYjyR2vHI0MlXIS_sK1Q.png)

A jeśli zaczniesz marzyć o umiejętności, której jeszcze nie ma, napisz ją. Ta umiejętność istnieje właśnie do tego celu. Repozytorium jest licencjonowane przez MIT i format jest otwarty. Najlepsza wiedza inżynierska w twoim zespole to te, które nie są w głowie nikogo i są łamane za każdym razem, gdy junior pisze PR. Skodyfikuj to raz. Agent będzie go śledził na zawsze.`write-a-skill`

Bo ostatecznie to wszystko, co te umiejętności robią. Nie sprawiają, że model jest mądrzejszy. Sprawiają, że jest mniej lekkomyślnie. Na długowiecznym kodzie okazuje się, że to właśnie ta różnica jest najważniejsza.