Skille, które uczą agenta porządnie testować i debugować

Skille do testowania i debugowania to Agent Skills, które każą agentowi programistycznemu odtworzyć błąd, najpierw napisać czerwony test i pokazać wynik polecenia, zanim ogłosi „naprawione”: tdd i diagnosing-bugs Matta Pococka, test-driven-development, systematic-debugging i verification-before-completion z Superpowers oraz webapp-testing od Anthropic. Skille kształtują zachowanie, ale niczego nie wymuszają; wymuszają CI i chroniony zestaw testów.

Ten schemat dobrze znasz. Klient zgłasza złą datę na stronie konta, agent zmienia trzy linie, pisze „Naprawione, data jest teraz poprawna”, a w sesji nic nie pokazuje, że błąd został odtworzony ani że poprawka działa. Tydzień później błąd wraca w innej strefie czasowej. Ta strona jest dla developerów, którzy chcą, żeby agent debugował jak staranny kolega z zespołu, i dla tech leadów, którzy chcą, żeby każda poprawka agenta przychodziła z dowodami, które reviewer sprawdzi bez ponownego czytania diffa.

Co dają ci skille do testowania i debugowania

Krótką listę sześciu skilli: co każdy z nich każe robić agentowi i jak je łączyć, żeby się nie gryzły
Polecenia instalacji dla Claude Code, Codex i Cursora, sprawdzone ze skills CLI 1.7.0 w dniu 2026-09-26
Rozpisaną sesję systematic-debugging: od zgłoszenia klienta do testu regresyjnego, który najpierw był czerwony, a potem zielony
Workflow red-green-refactor, który kończy się wklejonymi dowodami weryfikacji, a nie deklaracją
Bramki poza agentem, które dowodzą, że skille zadziałały, i typowe sposoby, w jakie to się psuje

Które skille do testowania i debugowania warto zainstalować?

Testowanie i debugowanie pokrywa sześć skilli z trzech repozytoriów: mattpocock/skills, obra/superpowers (metodyka Superpowers) i anthropics/skills.

Skill	Repozytorium	Co każe robić agentowi	Kiedy się uruchamia
`tdd`	mattpocock/skills	Najpierw uzgadnia z tobą szwy testowe (seams), potem jeden czerwony test i minimum kodu na każdy wycinek. Refaktoryzację przenosi do etapu review	Gdy prosisz o pracę test-first, red-green-refactor albo testy integracyjne
`diagnosing-bugs`	mattpocock/skills	Zanim powstanie jakakolwiek teoria, buduje szybką pętlę pass/fail, która daje czerwony wynik przy tym konkretnym błędzie; potem 3–5 uszeregowanych, falsyfikowalnych hipotez	Gdy piszesz „diagnose” albo „debug this” lub zgłaszasz, że coś jest zepsute albo wolne
`test-driven-development`	obra/superpowers	Ścisłe red-green-refactor. Kod napisany przed testem jest usuwany i pisany od nowa	Przed kodem każdej funkcji albo poprawki
`systematic-debugging`	obra/superpowers	Cztery fazy: badanie przyczyny źródłowej, analiza wzorców, jedna hipoteza naraz, potem czerwony test i jedna poprawka. Po trzech nieudanych poprawkach zatrzymuje się i każe zakwestionować projekt	Przy każdym błędzie, nieprzechodzącym teście albo nieoczekiwanym zachowaniu
`verification-before-completion`	obra/superpowers	Żadnej deklaracji sukcesu bez świeżego wyniku polecenia, które go dowodzi	Zanim agent napisze „gotowe”, „naprawione” albo „przechodzi” lub zrobi commit
`webapp-testing`	anthropics/skills	Pisze skrypty Playwright w Pythonie dla lokalnej aplikacji webowej, z pomocnikiem do uruchamiania serwerów, zrzutami ekranu i logami konsoli	Gdy prosisz o przetestowanie albo zdebugowanie lokalnego UI

Popularność (stan na 2026-09-26): liczba instalacji na skills.sh od początku wynosiła: tdd 966 524, diagnosing-bugs 665 090, systematic-debugging 271 653, test-driven-development 236 900, verification-before-completion 221 579 i webapp-testing 164 051. Te liczby pochodzą z zewnętrznego zrzutu LinklyAI/best-skills z 2026-09-26 (źródło wtórne; sprawdź aktualne wartości na skills.sh). Gwiazdki na GitHubie tego samego dnia: obra/superpowers 291,7 tys., mattpocock/skills 269,8 tys., anthropics/skills 178,4 tys.

Pocock czy Superpowers: który zestaw wybrać?

Wybierz jedną rodzinę do testów i jedną do debugowania. Dwa skille z tym samym wyzwalaczem dają agentowi dwie sprzeczne procedury.

Jeśli twój zespół…	Zainstaluj	Dlaczego
chce uzgodnić, co będzie testowane, zanim powstanie kod	`tdd` + `diagnosing-bugs` (Pocock)	`tdd` nie testuje na szwie, którego nie potwierdziłeś; `diagnosing-bugs` nie teoretyzuje, dopóki nie istnieje polecenie, które potrafi wykazać błąd (dać czerwony wynik)
już pracuje w workflow Superpowers (burza mózgów, plan, subagenty)	`test-driven-development` + `systematic-debugging` + `verification-before-completion`, przez plugin Superpowers	Bootstrap pluginu przy starcie sesji sprawia, że skille uruchamiają się bez proszenia; wszystkie trzy odwołują się do siebie nawzajem
chce lekkich skilli i twardej zasady „pokaż mi wynik”	`tdd` + `diagnosing-bugs` + `verification-before-completion`	Zestaw Pococka nie miał 2026-09-26 osobnej bramki ukończenia; skill Superpowers wypełnia tę lukę i instaluje się samodzielnie
buduje UI webowe i chce sprawdzeń w przeglądarce	dodaj `webapp-testing` albo agent-browser	Testy jednostkowe nie dowodzą tego, co widzi użytkownik

Dwa skille do debugowania różnią się pierwszym ruchem. diagnosing-bugs większość wysiłku wkłada w jedno polecenie, które w kilka sekund daje czerwony wynik przy zgłoszonym objawie, a potem szereguje kilka hipotez i pokazuje ci listę. systematic-debugging zaczyna od dowodów: czyta cały komunikat błędu, sprawdza ostatnie zmiany i loguje, co przechodzi przez granicę każdego komponentu. Potem sprawdza jedną hipotezę najmniejszą możliwą zmianą. Wybierz diagnosing-bugs do błędów, które da się oskryptować, a systematic-debugging do awarii rozciągniętych na CI, usługi i konfigurację.

Jak zainstalować zestaw do testów i debugowania w Claude Code, Codex i Cursorze?

Ścieżka przenośna to jedno polecenie skills CLI (npm skills 1.7.0). Codex i Cursor czytają kopię w .agents/skills/, a Claude Code czyta .claude/skills/. Ścieżka przez pluginy dodaje aktualizacje, a w przypadku Superpowers także bootstrap, który sam uruchamia metodę.

Zainstaluj skille w zakresie projektu. Uruchom to w katalogu głównym repozytorium.
Okno terminala
# Opcja A: pluginy z oficjalnego marketplace'u (aktualizują się same) claude plugin install mattpocock-skills --scope project claude plugin install superpowers@claude-plugins-official --scope project # Opcja B: przenośne kopie zalecanego zestawu, bez pluginów npx skills add mattpocock/skills --skill tdd codebase-design diagnosing-bugs -a claude-code -y npx skills add obra/superpowers --skill verification-before-completion -a claude-code -y
Skille z pluginów mają przestrzeń nazw: /mattpocock-skills:tdd, /superpowers:systematic-debugging. Kopie przenośne zachowują gołą nazwę: /tdd, /diagnosing-bugs. --scope project zapisuje plugin w .claude/settings.json, który commitujesz. Jeśli claude plugin install zgłosi, że nie zna marketplace’u (na przykład w świeżym kontenerze CI), najpierw uruchom claude plugin marketplace add anthropics/claude-plugins-official. Oficjalny marketplace przypina Superpowers 6.4.1; marketplace autora superpowers-marketplace ma 6.4.2 (oba sprawdzone 2026-09-26).
Okno terminala
npx skills add mattpocock/skills --skill tdd codebase-design diagnosing-bugs -a codex -y npx skills add obra/superpowers --skill verification-before-completion -a codex -y
Codex czyta .agents/skills/; /skills w TUI pokazuje, co się załadowało, a $diagnosing-bugs wywołuje skill po nazwie. Po pełną metodę Superpowers zainstaluj zamiast tego plugin: wpisz /plugins w TUI Codex, wyszukaj „superpowers” i wybierz Install. Plugin jest w marketplace’ie OpenAI openai-curated.
Okno terminala
npx skills add mattpocock/skills --skill tdd codebase-design diagnosing-bugs -a cursor -y npx skills add obra/superpowers --skill verification-before-completion -a cursor -y
Cursor czyta te same kopie z .agents/skills/. Po pełną metodę Superpowers wpisz /add-plugin superpowers w Agent chat (tę ścieżkę opisuje README Superpowers). Własnej dokumentacji skilli Cursora nie dało się ponownie sprawdzić 2026-09-26; jeśli skill się nie pojawia, poproś agenta, żeby użył go po nazwie.
Jeśli zespół używa więcej niż jednego agenta, zainstaluj skille raz dla wszystkich: npx skills add mattpocock/skills --skill tdd codebase-design diagnosing-bugs -a claude-code -a codex -a cursor -y. W próbnej instalacji ze skills 1.7.0 w dniu 2026-09-26 takie polecenie zapisało jedną kopię w .agents/skills/ i utworzyło do niej symlinki w .claude/skills/; instalacja tylko dla Claude Code kopiuje pliki bezpośrednio do .claude/skills/. README Pococka prosi też o setup-matt-pocock-skills; ani tdd, ani diagnosing-bugs go nie wywołuje, więc dodaj go tylko wtedy, gdy korzystasz z reszty zestawu.
Dodaj webapp-testing, jeśli testujesz UI webowe. npx skills add anthropics/skills --skill webapp-testing -a claude-code -a codex -a cursor -y albo w Claude Code /plugin marketplace add anthropics/skills, a potem /plugin install example-skills@anthropic-agent-skills (pakiet 12 skilli). Skill pisze kod w Pythonie, więc maszyna potrzebuje Pythona z pakietem playwright (1.63.0 na PyPI w dniu 2026-09-26) i przeglądarki z python -m playwright install chromium.
Sprawdź, co się zainstalowało. npx skills list pokazuje zainstalowane skille. Obok tdd musi być codebase-design: tdd go wywołuje, gdy kształt interfejsu jest niejasny. W Claude Code claude plugin details mattpocock-skills pokazuje zawartość pluginu i prognozowany koszt w tokenach.
Przeczytaj, co zainstalowałeś, i zrób commit. Skille działają z uprawnieniami agenta. Commituj .agents/skills/, .claude/skills/ i skills-lock.json (albo .claude/settings.json przy pluginach), żeby zestaw zespołu zmieniał pull request, a nie wiadomość na czacie.

diagnose to stara nazwa. Pocock zmienił ją na diagnosing-bugs; stary folder zwraca 404 na main, a mimo to mattpocock/skills@diagnose ma w zrzucie z 2026-09-26 wciąż 239 259 instalacji. Wysoki licznik nie znaczy, że skill nadal się instaluje.
--skill=<nazwa> jest po cichu ignorowane przez skills CLI 1.7.0. Z -y instaluje wszystkie skille z repozytorium. Pisz --skill tdd ze spacją.
Przenośna kopia Superpowers nie ma bootstrapu. npx skills add obra/superpowers nie dodaje hooka startu sesji, więc systematic-debugging uruchamia się tylko z opisu albo gdy go nazwiesz. Plugin uruchamia metodę sam.
systematic-debugging zawiera fikstury testowe. Instalacja obejmuje test-academic.md oraz pliki od test-pressure-1.md do test-pressure-3.md; testy presji mówią czytającemu „This is a real scenario. You must choose and act” (zgłoszenie #2277 z 2026-09-10; pliki nadal były w instalacji z 2026-09-26). To testy obciążeniowe samego skilla, a nie instrukcje dla twojego repozytorium. Przeczytaj je, zanim zacommitujesz folder.
Instaluj od kanonicznych właścicieli. skills.sh pokazuje niezwiązane repozytoria o nazwie */superpowers z sześciocyfrowymi licznikami. Metodyka Superpowers to wyłącznie obra/superpowers.

Jak wygląda sesja systematic-debugging na prawdziwym zgłoszeniu błędu?

Poniższe zgłoszenie to wejście. Zapis sesji to skrócona ilustracja kroków, które przepisuje skill systematic-debugging. To nie jest nagrany przebieg; repozytorium, commit i liczby wymyśliliśmy na potrzeby przykładu.

Issue #318  Renewal date shown one day early for NZ customers
Customers in Auckland see "Renews on 14 March 2027" on the account page.
The card is charged on 15 March. Started after release 3.8.0.

Use the systematic-debugging skill on issue #318 (renewal date shown one day early for
customers in New Zealand, since release 3.8.0). Complete phase 1 before you propose any
fix: reproduce the exact symptom with a command I can rerun, read the full error or
output, and list the commits since 3.7.2 that touch src/billing. State one hypothesis
and the smallest experiment that would prove it wrong. Write the failing regression
test before the fix. Do not change more than one thing per experiment.

Co robi agent, faza po fazie:

Phase 1: root cause investigation
  Symptom is the displayed date; the charge date is correct.
  $ TZ=Pacific/Auckland npx vitest run src/billing/renewal.test.ts
    6 passed                       <- existing tests do not cover the symptom
  $ TZ=Pacific/Auckland npx tsx scripts/print-renewal.ts --sub sub_1042
    renewsOn: 2027-03-14           (charge job uses 2027-03-15)
  $ git log --oneline v3.7.2..v3.8.0 -- src/billing
    a41c9e2 replace date-fns addMonths with native Date arithmetic

Phase 2: pattern analysis
  Working: src/invoices/period.ts builds dates with Date.UTC(...)
  Broken:  src/billing/renewal.ts builds new Date(year, month + 1, day) in local time,
           then serialises with toISOString()

Phase 3: hypothesis and minimal test
  Hypothesis: local midnight in UTC+13 serialises to the previous day in UTC.
  Prediction: the same script with TZ=UTC prints 2027-03-15.
  $ TZ=UTC npx tsx scripts/print-renewal.ts --sub sub_1042
    renewsOn: 2027-03-15           prediction holds

Phase 4: implementation
  Failing test first: "renews on the same calendar day in UTC+13"
  $ TZ=Pacific/Auckland npx vitest run src/billing/renewal.test.ts
    1 failed, 6 passed  expected '2027-03-15', received '2027-03-14'
  Single fix: addBillingMonths() builds the date with Date.UTC
  $ TZ=Pacific/Auckland npx vitest run src/billing/renewal.test.ts
    7 passed

Ten zapis pokazuje, za co płacisz, instalując skill: agent udowodnił, że istniejące testy nie widzą objawu, wskazał commit, który wprowadził błąd, i sprawił, że test regresyjny padł dokładnie z objawem klienta, zanim poprawka zmieniła go na zielony. Gdyby poprawka nie zadziałała, skill odesłałby agenta do fazy 1; po trzech nieudanych poprawkach zatrzymuje się i pyta, czy zły nie jest sam projekt.

Przy tym samym błędzie diagnosing-bugs działa inaczej: agent najpierw buduje skrypt z TZ=Pacific/Auckland jako jedno polecenie, które daje czerwony wynik, zmniejsza scenariusz do najmniejszego wejścia, które nadal pada, a potem pokazuje ci od trzech do pięciu uszeregowanych hipotez, zanim sprawdzi którąkolwiek. Tymczasowe logi oznacza prefiksem, na przykład [DEBUG-a4f2], i na koniec usuwa je jednym grep.

Use the diagnosing-bugs skill. The CSV export on /reports times out for accounts with
more than 10,000 rows since Tuesday's deploy. Phase 1 only for now: build one command
that reproduces the timeout in seconds, run it, and show me the invocation and its
output with secrets redacted. Then minimise the scenario and show me your 3 to 5 ranked
hypotheses, each with the prediction that would falsify it. Wait for my reply before
you instrument or change code.

Jak prowadzić red-green-refactor z dowodami weryfikacji przed „gotowe”?

Skille wpinają się w jedną pętlę. Pętla jest taka sama we wszystkich trzech agentach; różni się tylko sposób wywołania. Zaczyna się od zgłoszenia błędu albo kryterium akceptacji, a kończy dowodami, które reviewer sprawdzi bez czytania każdej linii.

Zapisz punkt odniesienia. Przed jakąkolwiek zmianą agent uruchamia cały zestaw testów, sprawdzanie typów i linter, i zapisuje wynik. Test, który już był czerwony, trafia na listę znanych, więc nie ukryje później regresji i nie będzie się za nią podawał.
Uzgodnij szew (tdd Pococka). Agent nazywa publiczny interfejs, przez który będzie testował, i czeka na twoje potwierdzenie. Przy błędzie szew to miejsce, w którym zgłoszony objaw da się zaobserwować. Szew zbyt płytki, żeby wyrazić błąd, daje fałszywą pewność; diagnosing-bugs traktuje „nie ma właściwego szwu” jako osobne ustalenie.
Czerwony. Jeden nieprzechodzący test na jedno zachowanie. Agent go uruchamia i pokazuje komunikat, który musi być oczekiwanym błędem (zła data), a nie literówką czy brakującym importem. Skill Superpowers podaje powód: jeśli nie widziałeś, jak test pada, nie wiesz, czy testuje właściwą rzecz.
Zielony. Minimum kodu, które przechodzi test. Bez opcji „na zapas” i bez sprzątania obok.
Refaktoryzacja na zielonym. Superpowers refaktoryzuje wewnątrz pętli i po każdej zmianie uruchamia testy ponownie. tdd Pococka przenosi refaktoryzację do etapu review i swojego skilla code-review. Tak czy inaczej testy pozostają zielone przy każdej zmianie struktury.
Udowodnij, że test łapie błąd. Cofnij poprawkę, uruchom nowy test i zobacz, jak pada; przywróć poprawkę i zobacz, jak przechodzi. verification-before-completion wskazuje ten cykl red-green jako dowód, że test regresyjny działa; test, który raz przeszedł, niczego nie dowodzi.
Pokaż dowody, potem ogłoś „gotowe”. Agent uruchamia cały zestaw testów, sprawdzanie typów, linter, a przy zmianach UI także sprawdzenie w przeglądarce. Wkleja polecenia z kodami wyjścia i liczbą błędów, a potem porównuje je z punktem odniesienia z kroku 1.
Przekaż do CI i review. Pull request niesie dowody; CI uruchamia te same polecenia na czystej infrastrukturze. Czerwony przebieg CI unieważnia każde „gotowe” z czatu.

Fix issue #318 test-first. First run the full test suite, the type check and the linter
and record the baseline. Tell me which public interface you will test through and wait
for my OK. Then: write one failing test that reproduces the reported symptom, run it and
show me the failure message; write the minimum fix; run it green. Finally revert only the
fix, show the new test failing, restore the fix and show it passing. Do not edit or
delete any existing test.

Before you tell me this is finished, use verification-before-completion. Run, fresh in
this turn: the full test suite, the type check and the linter. Paste each command with
its exit code and pass/fail counts, and compare them with the baseline you recorded at the
start. List every acceptance criterion from the issue with the command or test that
proves it. If anything is unverified or red, say so plainly instead of summarising.

Z pluginami nazwij skill, gdy chcesz mieć pewność, że zadziała: /superpowers:systematic-debugging, /mattpocock-skills:tdd. Po kroku 7 dodaj /verify, gdy zmianę widać w działającej aplikacji; buduje ją i obsługuje, zamiast polegać na testach. Punkt odniesienia z kroku 1 i zasadę red-green z kroku 6 zapisz w CLAUDE.md, żeby obowiązywały także wtedy, gdy skill się nie uruchomi.

Skille wywołujesz przez $: $diagnosing-bugs, $tdd, $verification-before-completion. Codex uruchamia polecenia w swoim sandboksie, więc test, który potrzebuje portu sieciowego albo lokalnej bazy, może tam padać, a u ciebie przechodzić. Traktuj to jako różnicę sandboksa do rozwiązania, a nie niestabilny test do powtarzania. Przed otwarciem pull requesta uruchom na diffie wbudowane w Codex /review.

Jak sprawdzić UI webowe skillem webapp-testing?

webapp-testing obsługuje błędy, które widać tylko w przeglądarce. Uczy wzorca „najpierw rozpoznanie, potem akcja”: poczekaj, aż strona się ustabilizuje, zrób zrzut ekranu albo przeczytaj DOM, znajdź selektory w tym, co się wyrenderowało, i dopiero wtedy działaj. Pomocnik scripts/with_server.py uruchamia jeden lub kilka serwerów deweloperskich, czeka na ich porty i odpala na nich twój skrypt Playwright.

Use the webapp-testing skill. Start the app with scripts/with_server.py (run it with
--help first) using "npm run dev" on port 5173. Reproduce this report: submitting the
settings form with an empty email shows no validation error. Write a headless Playwright
script that fills the form, submits it, saves a full-page screenshot to
.evidence/settings-empty-email.png and prints every console error. Tell me whether the
bug reproduces, with the script output. Do not change application code yet.

Gdy błąd odtwarza się w przeglądarce, skrypt staje się w opisanej wyżej pętli poleceniem, które daje czerwony wynik. Po wdrożeniu poprawki przenieś go do zestawu testów end-to-end, żeby uruchamiał się przy każdej zmianie. Jeśli twoi agenci już używają agent-browser, zostań przy nim: we wszystkich trzech agentach ma to samo CLI i nie potrzebuje Pythona. Strona o agent-browser porównuje oba narzędzia z serwerami MCP Playwright i Chrome DevTools.

Jak udowodnić, że skille zrobiły swoje?

Skill zmienia to, co agent zwykle robi, ale niczego nie gwarantuje: może się nie uruchomić, a agent może źle odczytać własny wynik. Dlatego dowód leży poza agentem.

CI powtarza dowody. Polecenia wklejone przez agenta uruchamiają się ponownie w CI na pull requeście. Wklejony wynik to wygoda dla reviewera; bramką jest wynik CI.
Test jest chroniony. Agent debugujący pod presją może „naprawić” czerwony test, zmieniając asercję. Obejmij testy regułami deny i CODEOWNERS opisanymi w ochronie wyroczni testowej i odrzucaj każdy pull request, który usuwa albo pomija test bez wskazanej osoby zatwierdzającej.
Sprawdzenie red-green jest w pull requeście. Reviewer sprawdza jedną rzecz: nowy test padał ze zgłoszonym objawem przed poprawką i przechodzi po niej. Dołącz je do pakietu dowodów razem z commitem przyczyny źródłowej, który znalazł agent.
Zestaw skilli też jest testowany. Zanim ustandaryzujesz skill w zespole, sprawdź, czy uruchamia się na waszych promptach. W Claude Code 2.1.283 claude plugin eval uruchamia przypadki ewaluacyjne pluginu i porównuje je z przebiegiem bez pluginu; skill skill-creator od Anthropic uruchamia testowe prompty ze skillem i bez niego.

Kto zatwierdza. Developer, który otwiera pull request, odpowiada za dowody. Reviewer zatwierdza na podstawie sprawdzenia red-green, przyczyny źródłowej i zielonego CI, a linia po linii czyta kod tylko na ścieżkach wysokiego ryzyka (uwierzytelnianie, pieniądze, migracje schematu). Tech lead odpowiada za zacommitowany zestaw skilli i zmienia go przez review, jak każdy inny kod.

Ile kontekstu kosztują skille do testowania i debugowania?

Każdy zainstalowany skill dodaje do każdej sesji swoją nazwę i opis; treść ładuje się dopiero wtedy, gdy skill się uruchomi. Pomiar z 2026-09-26:

Co się ładuje	Kiedy	Rozmiar
`SKILL.md` skilli `tdd` / `diagnosing-bugs`	Gdy skill się uruchomi	3549 / 8529 bajtów
`SKILL.md` skilli `test-driven-development` / `systematic-debugging`	Gdy skill się uruchomi	9578 / 9465 bajtów
`SKILL.md` skilli `verification-before-completion` / `webapp-testing`	Gdy skill się uruchomi	3646 / 3913 bajtów
Plugin `superpowers@claude-plugins-official` (15 skilli)	W każdej sesji	około 838 tokenów, `claude plugin details` w Claude Code 2.1.283
Plugin `mattpocock-skills@claude-plugins-official` (25 skilli)	W każdej sesji	około 1609 tokenów, ten sam pomiar

Uruchomiony skill do debugowania kosztuje około 2000–2500 tokenów (mniej więcej cztery bajty na token). Większym kosztem są duplikaty: plugin Superpowers plus przenośna kopia tych samych skilli pokazuje każdy z nich dwa razy. W Claude Code porównaj /context przed instalacją i po niej.

Co się psuje, gdy agent korzysta ze skilli do testowania i debugowania?

Na ten sam błąd uruchamiają się dwa skille. Gdy zainstalowane są jednocześnie diagnosing-bugs i systematic-debugging, agent zaczyna jedną procedurę i dryfuje w drugą. Wyjście: zostaw jeden skill do debugowania na repozytorium, a drugi usuń przez npx skills remove.

Agent pisze test, który od razu przechodzi. Test powstał względem obecnego zachowania albo jego asercja wylicza oczekiwaną wartość tak samo jak kod. Ten drugi przypadek tdd Pococka nazywa „tautologicznym”. Wyjście: wymagaj czerwonego przebiegu ze zgłoszonym objawem w komunikacie i sprawdzenia z cofniętą poprawką przed każdym „gotowe”.

Skill nie uruchamia się przy lakonicznej prośbie. „Popraw tę datę” może nie pasować do opisu żadnego skilla. Wyjście: nazwij skill w prompcie, zainstaluj Superpowers jako plugin, żeby działał bootstrap, albo dopisz do CLAUDE.md lub AGENTS.md: „For any bug report, use the systematic-debugging skill before proposing a fix.”

Pętla sprzężenia zwrotnego jest niestabilna. Test, który pada w co trzecim przebiegu, zamienia każdą hipotezę w szum. Wyjście: przypnij czas, ustaw ziarno losowości i odizoluj system plików, tak jak przepisuje diagnosing-bugs. Przy niestabilnych testach zastąp stałe opóźnienia odpytywaniem warunku (condition-based-waiting.md z Superpowers). Gdy test zostawia po sobie pliki, użyj find-polluter.sh z tego samego folderu skilla, żeby bisekcją znaleźć test, który je tworzy.

Agent kręci się w kółko z poprawkami. Każda poprawka odsłania nowy objaw gdzie indziej. Wyjście: zatrzymaj się po trzeciej nieudanej poprawce, czego wymaga systematic-debugging, i omów projekt z człowiekiem, zanim padnie czwarta próba.

Weryfikacja utyka na testach, które były czerwone od początku. Bez punktu odniesienia agent nie odróżni starego błędu od nowej regresji i ponawia próby. Wyjście: najpierw zapisz punkt odniesienia (krok 1 pętli) i raportuj stare błędy osobno; nigdy nie pozwalaj agentowi pomijać pliku z testami bez spisanej polityki zespołu.

Dokąd dalej ze skillami do testowania i debugowania

Test-driven development z AI Metoda stojąca za skillami: dlaczego potwierdzony czerwony krok ma znaczenie i jak podzielić pętlę na tury.

25 najczęściej instalowanych skilli praktyk Szerszy ranking i pętla przepytanie, specyfikacja, tdd i review, w którą wpinają się te skille.

Skille do code review Etap po pętli: skille i boty do review, które sprawdzają diff względem waszych standardów i specyfikacji.

Superpowers Pełna metodyka, z której pochodzą test-driven-development, systematic-debugging i verification-before-completion.

Ochrona wyroczni testowej Jak powstrzymać agenta, który zamiast kodu poprawia test.

Bezpieczeństwo łańcucha dostaw skilli Jak przejrzeć zewnętrzne skille i dołączone do nich skrypty, zanim zespół je uruchomi.

Procesy debugowania w konkretnych narzędziach opisują strony debugowanie w CLI Claude Code, systematyczne debugowanie w Codex i debugowanie z AI w Cursorze.