Lekcja 26 · Faza 3 · Zamknięcie — narzędzia jednorazowego użytku

Cztery samodzielne narzędzia deweloperskie

Ostatnia lekcja Fazy 3. W przeciwieństwie do wszystkiego dotąd, te cztery skille nie dzielą wspólnego słownictwa ani przepływu — każdy rozwiązuje jeden, wąski, mechaniczny problem, niezależnie od reszty pakietu. Łączy je tylko jedno: każdy koduje raz sprawdzoną procedurę, żeby nie trzeba było jej tłumaczyć AI (ani nowej osobie w zespole) od nowa za każdym razem — dokładnie ta sama postawa, co przy /wizard z poprzedniej lekcji, tylko skierowana na mechanikę inżynierską zamiast na ręczne procedury dla człowieka.

Polecane źródło Lokalne pliki .agents/skills/{git-guardrails-claude-code,migrate-to-shoehorn,setup-pre-commit,resolving-merge-conflicts}/SKILL.md w tym repo.

Szybka tabela

SkillKomendaRobi
git-guardrails-claude-code/git-guardrails-claude-codeInstaluje hook blokujący niebezpieczne komendy git przed ich wykonaniem
setup-pre-commit/setup-pre-commitKonfiguruje Husky + lint-staged + Prettier + typecheck/testy w pre-commit
migrate-to-shoehorn/migrate-to-shoehornZamienia asercje as w testach na bezpieczne typowo alternatywy
resolving-merge-conflicts/resolving-merge-conflictsDyscyplina rozwiązywania trwającego konfliktu merge'a/rebase'a

/git-guardrails-claude-code — hook, który już rozpoznajesz

To bezpośredni callback do Lekcji 6: skill instaluje hook typu PreToolUse z matcherem Bash, przechwytujący komendę zanim Claude ją wykona. Domyślnie blokuje: git push (wszystkie warianty, w tym --force), git reset --hard, git clean -f/-fd, git branch -D, git checkout ./git restore .. Zablokowana komenda kończy się kodem wyjścia 2, a Claude widzi komunikat, że nie ma uprawnień do tej komendy.

Proces instalacji: (1) zapytanie o zasięg — projekt (.claude/settings.json) czy globalnie (~/.claude/settings.json), dokładnie te same dwa poziomy z Lekcji 6; (2) skopiowanie skryptu do .claude/hooks/; (3) dopisanie wpisu do hooks.PreToolUse w istniejącym pliku ustawień — scalenie, nie nadpisanie reszty configu; (4) opcjonalna personalizacja listy wzorców; (5) weryfikacja przez spreparowany JSON na wejściu, oczekujący kodu wyjścia 2.

/setup-pre-commit — Husky, lint-staged, Prettier

Wykrywa menedżera pakietów po obecności pliku blokady (package-lock.json/pnpm-lock.yaml/yarn.lock/bun.lockb), instaluje husky/lint-staged/prettier jako devDependencies, inicjalizuje Husky (npx husky init) i pisze .husky/pre-commit uruchamiający po kolei: lint-staged (szybkie, tylko na zmienionych plikach), potem pełny typecheck, potem test. Jeśli projekt nie ma skryptu typecheck albo test w package.json, te linie są pomijane, a użytkownik dowiaduje się o tym wprost.

Ostatni krok jest jednocześnie testem: skill każe zacommitować zmiany z komunikatem opisującym dodanie hooków — sam ten commit przechodzi przez świeżo zainstalowany pre-commit, więc jeśli coś jest nie tak, widać to natychmiast.

/migrate-to-shoehorn — bezpieczne typowo dane testowe

@total-typescript/shoehorn pozwala przekazywać częściowe dane w testach, nie tracąc kontroli typów — wyłącznie w kodzie testowym, nigdy w produkcyjnym.

FunkcjaZastępujeKiedy
fromPartial()as TypeCzęściowe dane, które mają wciąż przechodzić typecheck
fromAny()as unknown as TypeCelowo błędne dane (np. testy przypadków błędu), z zachowanym autocomplete
fromExact()—Wymuszenie pełnego obiektu — łatwo zamienić potem na fromPartial

Przykład: zamiast fałszować wszystkie 20 pól typu Request, żeby przetestować funkcję, która czyta tylko body.id — fromPartial({ body: { id: "123" } }) podaje tylko to, co potrzebne, i wciąż przechodzi typecheck.

/resolving-merge-conflicts — dyscyplina, nie automat

Pięć kroków, w tej kolejności:

  1. Zobacz aktualny stan mergea/rebase'a — historia git, pliki w konflikcie.
  2. Znajdź źródła pierwotne każdej zmiany po obu stronach konfliktu — commit message'e, PR-y, oryginalne issues — żeby zrozumieć intencję, nie tylko diff.
  3. Rozwiąż każdy hunk, zachowując obie intencje tam, gdzie to możliwe. Tam, gdzie się wykluczają — wybierz tę zgodną z deklarowanym celem merge'a i zanotuj kompromis. Nigdy nie wymyślaj nowego zachowania.
  4. Uruchom automatyczne sprawdzenia projektu — zwykle typecheck, potem testy, potem format — i napraw wszystko, co merge popsuł.
  5. Zakończ merge/rebase — zastaw wszystko i commituj; przy rebase kontynuuj proces, aż wszystkie commity zostaną przepisane.
Kluczowy wniosek: skill stawia dwie twarde zasady na równi: zawsze rozwiązuj, nigdy nie przerywaj przez --abort. Ucieczka z konfliktu przez abort tylko odracza tę samą pracę na później — dyscyplina zakłada, że skoro już wchodzisz w konflikt, kończysz go, uzbrojony w kontekst z oryginalnych źródeł.

Zadanie praktyczne — wybierz jedno narzędzie, realnie potrzebne teraz

W swoim prawdziwym projekcie firmowym wybierz jeden z czterech skilli, który faktycznie rozwiązuje coś, co masz na tapecie:

  1. Jeśli projekt nie ma jeszcze pre-commit hooków — uruchom /setup-pre-commit i sprawdź, czy testowy commit faktycznie przechodzi przez świeży hook.
  2. Jeśli zdarzyło Ci się przypadkowe git push --force albo reset --hard — uruchom /git-guardrails-claude-code i zweryfikuj go spreparowanym wejściem z SKILL.md.
  3. Jeśli masz trwający konflikt merge'a — przeprowadź /resolving-merge-conflicts i sprawdź, czy Claude faktycznie sięgnął po commit message'e i PR-y, zanim rozwiązał pierwszy hunk.

Sprawdź się

1. Jaki typ hooka instaluje git-guardrails-claude-code, i kiedy się uruchamia?

To hook PreToolUse z matcherem Bash — działa przed wykonaniem komendy i może ją zablokować kodem wyjścia 2, zanim cokolwiek się stanie.

2. Po czym setup-pre-commit rozpoznaje, którego menedżera pakietów użyć?

Skill sprawdza obecność package-lock.json, pnpm-lock.yaml, yarn.lock albo bun.lockb i na tej podstawie wybiera odpowiedni menedżer, domyślnie npm gdy niejasne.

3. Gdzie wolno używać funkcji z @total-typescript/shoehorn, według migrate-to-shoehorn?

Zasada jest wprost: "Test code only. Never use shoehorn in production code" — narzędzie istnieje po to, żeby ułatwić testy, nie żeby obchodzić typy w runtime.

4. Czego resolving-merge-conflicts wyraźnie zabrania podczas rozwiązywania konfliktu?

Skill mówi wprost: "Always resolve; never --abort". Ucieczka przez abort tylko odkłada ten sam konflikt na później, więc dyscyplina zakłada doprowadzenie do końca.

5. Skoro te cztery narzędzia nie dzielą wspólnego słownictwa, co je jednak łączy?

Wszystkie cztery zamykają jednorazowo znaną, sprawdzoną procedurę (hook, konfigurację, wzorzec migracji, dyscyplinę) w powtarzalnej formie — ta sama postawa, co przy /wizard, tylko skierowana na mechanikę inżynierską.
Coś niejasne? Zapytaj mnie wprost — mogę pomóc ocenić, które z tych czterech narzędzi realnie rozwiązuje problem, który masz teraz w swoim projekcie.
To zamyka Fazę 3 i cały łuk lekcji o pakietach Matta Pococka (Lekcje 13–26): najpierw główny cykl inżynierski, potem pipeline pisarski, planowanie wieloetapowe i narzędzia jednorazowego użytku. Kolejne pakiety, jeśli się pojawią, dostaną własną Fazę w MISSION.md — tak jak Faza 3 dostała, gdy dodałeś brakujące skille.
← Lekcja 25: wizard Cały pakiet od początku: Lekcja 13 →