Naprawiacz promptów, który diagnozuje, zanim przepisze

Wklej wadliwy prompt do niemal każdego „optymalizatora promptów”, a dostaniesz ten sam ruch: twój prompt wchodzi do magicznego szablonu — framework 4-D! 27 wzorców! — i wraca dłuższy, przebudowany od góry do dołu, bez żadnego zapisu, która zmiana miała znaczenie ani czy nadal robi to samo zadanie. Czyta się lepiej. Czy działa lepiej — to zupełnie inna sprawa, a narzędzie nigdy tego nie sprawdza.

Na co dzień prowadzimy katalog, w którym benchmarkujemy skille Claude, i chcieliśmy przeciwieństwa tego. Więc zbudowaliśmy prompt-discipline, który traktuje prompt tak, jak potraktowałbyś bug report: najpierw nazwij tryb awarii, zastosuj najmniejszą poprawkę, która go adresuje, potem powiedz dokładnie, jak zrobić A/B tej zmiany. Jest darmowy, na licencji MIT: github.com/Skillproofdev/prompt-discipline.

Luka: przepisywacze nie diagnozują, diagności potrzebują infrastruktury

Zanim napisaliśmy pierwszą regułę, przejrzeliśmy 43 skille do prompt engineeringu w naszym katalogu plus samodzielne narzędzia — własny Console prompt improver Anthropic, PromptPerfect, DSPy, prompt-optimizer od getsentry. Nisza dzieli się na dwa obozy, które nigdy się nie przecinają.

Przepisywacze szablonowe transformują każdy input tak samo. Nie ma kroku, który pyta, co tu naprawdę jest nie tak — niejasny prompt i sprzeczny prompt dostają to samo traktowanie, a wynik jest niezmiennie dłuższy. To nie jest wyimaginowany przeciwnik: własny Console improver Anthropic otwarcie ostrzega, że jego przepisania wychodzą dłuższe i wolniejsze. Dłuższe jest produktem.

Pipeline'y eval-first — DSPy, optymalizatory sterowane trace'ami — mają właściwą epistemologię. Faktycznie mierzą. Ale potrzebują infrastruktury: śladów produkcyjnych, serwera MCP, harnessu worktree, oznaczonego zbioru danych, który musisz najpierw zebrać. Nie sięgasz po nie, żeby naprawić prompt, który edytujesz właśnie teraz.

Nikt nie pakuje tej środkowej rzeczy: skilla bez zależności, który robi najpierw-diagnoza → minimalny-diff → plan testu A/B, bez śladów i bez serwera do postawienia. Ta luka to cały skill.

Dziewięć reguł, trzy z nich to sedno

Skill to zestaw twardych reguł stosowanych po kolei (pełny SKILL.md). Znajome elementy są na miejscu — format wyniku jako pozytywna umowa (lista kluczy z typami, nie „odpowiedz w JSON”), przykłady zamiast przymiotników, listy zakazów przepisane na instrukcje nakazujące, kolejność rola→dane→instrukcje→przykłady→zapytanie. Trzy, które go definiują:

1. Diagnozuj, zanim czegokolwiek dotkniesz. Sklasyfikuj, co naprawdę jest nie tak — niejednoznaczność, brakujący kontekst, brak umowy co do wyniku, sprzeczne instrukcje, ryzyko dryfu formatu, nadmierny prompting, albo „to w ogóle nie jest problem promptingowy” — i zacytuj winny fragment dla każdego znaleziska. Bez diagnozy, bez przepisania. „Ten prompt jest w porządku” to poprawny, kompletny wynik.
2. Minimalny diff, jedna zmiana na porażkę. Każda edycja mapuje się na dokładnie jedną zdiagnozowaną porażkę, pokazaną jako old → new z jednolinijkowym uzasadnieniem. Działające części zostają dosłowne. Tam, gdzie Console improver dopycha, ten skill zwykle wychodzi krótszy — martwe zaklęcia („jesteś najlepszym na świecie…”, „weź głęboki oddech”, nieaktualne rusztowania „think step by step”) zostają wycięte.
3. Plan testu, nie obietnica. Każde przepisanie dostarczane jest z 2–3 konkretnymi inputami testowymi, wliczając przypadek brzegowy, tym, jak wygląda zaliczenie, i procedurą A/B: te same inputy, ten sam model, 3–5 przebiegów każdy, porównanie wskaźników zaliczeń. Jeśli edycje były nałożone, wskazuje, którą cofnąć najpierw. Nigdy nie obiecuje „to to naprawi” — zmieniłeś zmienne; test decyduje.

Benchmark — i zastrzeżenie, które musisz poznać najpierw

Dziesięć naprawdę wadliwych promptów, każdy sparowany z zadaniem, które ma mechanicznie sprawdzalną odpowiedź: ekstrakcja względem znanego stanu faktycznego, formatowanie, które musi się sparsować (json.loads / csv.reader), klasyfikacja względem oznaczonych przykładów. Trzy warianty na przypadek — oryginalny prompt, przepisanie bazowe (zwykły Claude, któremu powiedziano „popraw ten prompt”), i przepisanie ze skillem (identyczna sesja z wczytanym tym SKILL.md). Wszystkie przepisania są potem uruchamiane jako zadania na tym samym modelu.

Przeczytaj to przed tabelą: przebieg to n=1 na przypadek na wariant, nie z góry zarejestrowane n=5. Wariancja próbkowania jest niezmierzona. Każda luka na pojedynczym przypadku (0,1) mieści się w poziomie szumu. Traktuj każdą liczbę tutaj jako tymczasową do czasu replikacji n=5 — my też tak robimy.

Wariant	Sukces zadania	Zgodność formatu	Mediana Δ długości promptu
A — oryginalny prompt	0,70 (7/10)	0,70 (7/10)	—
B — przepisanie bazowe („improve this prompt”)	0,80 (8/10)	0,70 (7/10)	+99,5 słowa
C — przepisanie ze skillem (ten SKILL.md)	0,90 (9/10)	0,80 (8/10)	+44,5 słowa

Wobec z góry zarejestrowanego testu skill zdaje: remisuje z przepisaniem bazowym lub je bije pod względem sukcesu (0,90 ≥ 0,80) i zgodności (0,80 ≥ 0,70), przekracza próg +15 pp nad oryginałem (+20 pp), i robi to, dodając mniej niż połowę nadmuchu promptu — mediana +44,5 słowa wobec +99,5 przy przepisaniu bazowym. Ta ostatnia liczba to najsolidniejsze znalezisko w całym przebiegu: C jest szczuplejszy we wszystkich dziesięciu przypadkach i jest jedynym wariantem, który kiedykolwiek idzie na minus (case-10, −10 słów, wycinając stos zakazów z systemowego promptu). Zarówno naiwne, jak i zdyscyplinowane przepisywanie nadmuchuje zwięzłe prompty; naiwne mniej więcej podwaja koszt.

Gdzie jest cienki i gdzie przegrał

Przewagi w sukcesie i zgodności są prawdziwe, ale kruche, i nie będziemy udawać inaczej.

Na 7 z 10 przypadków wszystkie trzy warianty remisują. Margines sukcesu opiera się niemal całkowicie na case-06 (klasyfikacja ticketów), jedynym przypadku, w którym skill wygrywa wprost: C wyprodukował poprawne, parsowalne per-element etykiety (15/15), podczas gdy przepisanie bazowe dostało 13/15 w formacie, który się nie parsował. Usuń ten jeden przypadek, a nagłówkowa luka w większości wyparuje. Tak wygląda n=1 z dużą liczbą remisów — uczciwe, nie druzgocące, ale powinieneś to wiedzieć.

Case-09 to porażka skilla na jego własnych zasadach. Prompt do poprawy tonu z brakującym odbiorcą — dokładnie sytuacja, dla której istnieje Reguła 2 („podaj swoje założenie, gdy intencja jest nierozstrzygalna”). Reguła się nie uruchomiła. Przepisanie skilla porzuciło problem brakującego odbiorcy, i C zawiodło razem z A i B. Skill przegrywający w rzeczy, do której złapania jest specjalnie zaprojektowany, to najbardziej użyteczny rodzaj wyniku negatywnego, więc zostaje w tabeli.

Zgodność w case-02 to 0 we wszystkich trzech wariantach. Prompt ze sprzecznymi instrukcjami: każdy wariant rozwiązał sprzeczność w treści (dostał właściwą liczbę), ale żaden nie wymusił jednowartościowego wyniku, więc wszystkie trzy dostały 0 za format. Żaden przepisywacz — zdyscyplinowany czy nie — nie pomyślał, żeby wyegzekwować umowę. Wspólny martwy punkt, zgłoszony, nie ukryty.

Na co dzień testujemy cudze skille, a nasza metodologia wymaga pokazywania porażek obok zwycięstw. To są te porażki.

Instalacja

git clone https://github.com/Skillproofdev/prompt-discipline ~/.claude/skills/prompt-discipline

Zrestartuj Claude Code. Uruchamia się na „improve this prompt”, „why does my prompt fail”, „optimize prompt” i gdy piszesz lub poprawiasz prompty systemowe i instrukcje agentów — i odmawia próśb o jailbreak/obejście bezpieczeństwa oraz promptów do generowania obrazów/wideo, które mają swoją własną gramatykę. Dołącza do naszej serii dyscyplin: token-discipline tnie to, ile kosztuje sesja, research-discipline tnie to, w czym myli się research, a ten tnie przepisania promptów do zmiany, która faktycznie miała znaczenie.

FAQ

Czym różni się to od Console prompt improvera Anthropic? Console improver to przepisywacz szablonowy — przebudowuje cały prompt i otwarcie ostrzega, że wynik wychodzi dłuższy i wolniejszy. prompt-discipline najpierw diagnozuje konkretną porażkę, zmienia tylko to, co się na nią mapuje, i w naszym benchmarku dodał mniej niż połowę długości, zwykle wychodząc krótszy. Inny cel: narzędzie Console produkuje wypolerowany prompt; ten produkuje najmniejszy obronny diff plus sposób, żeby to udowodnić.

Czemu publikować benchmark, o którym sami mówicie, że to n=1? Bo alternatywą w tej niszy jest niepublikowanie żadnych liczb, a to norma, na którą reagujemy. n=1 z jasno podanym zastrzeżeniem jest bardziej uczciwe niż pewne siebie twierdzenie bez żadnego pomiaru za nim. Znalezisko dotyczące mediany długości jest solidne we wszystkich dziesięciu przypadkach; przewagi sukcesu i zgodności są tymczasowe i tak oznaczone, do czasu replikacji n=5.

Czy zawsze przepisuje mój prompt? Nie. Jeśli prompt jest w porządku, skill tak mówi i się zatrzymuje — „ten prompt nie potrzebuje zmian; oto jedno ryzyko do przetestowania” to poprawny, kompletny wynik. Odmawia też dopychania diagnozy tylko po to, żeby uzasadnić zastosowanie szablonu, i wprost odmawia próśb o jailbreak zamiast je „poprawiać”.

Czy to naprawi mój prompt? Nie obieca tego, i żadne narzędzie, które nie uruchomiło twojego zadania, nie powinno tego robić. Skill zmienia zmienne i daje ci konkretną procedurę A/B — te same inputy, ten sam model, 3–5 przebiegów — więc decyduje test, nie wrażenie z ładniej wyglądającego promptu.