Praktyczne schematy automatyzacji z hookami

Czego się nauczysz

• Jakie wzorce hooków naprawdę mają sens w codziennej pracy
• Jak łączyć hooki z custom agentami i politykami bezpieczeństwa
• Których automatyzacji lepiej nie budować, mimo że technicznie się da

Nie buduj automatyzacji od zera za każdym razem

Przy hookach najwięcej czasu traci się nie na konfiguracji, tylko na wymyślaniu od nowa, co w ogóle warto automatyzować.

Dlatego lepiej myśleć wzorcami.

Nie jako listą gotowców do ślepego skopiowania, tylko jako katalogiem decyzji:

• co automatyzować
• na jakim etapie
• z jakim poziomem bezpieczeństwa
• dla jakiego typu projektu

Wzorzec 1: local CI po każdej sensownej zmianie

To chyba najbardziej praktyczny wzorzec zespołowy.

Schemat wygląda tak:

• PostToolUse po edycji uruchamia szybkie sprawdzenie lokalne
• wynik trafia do logu albo dodatkowego kontekstu dla modelu
• agent dostaje natychmiastowy sygnał, czy poszedł w dobrą stronę

To nie musi być pełne CI. W większości projektów wystarczy:

• formatter
• szybki lint
• testy celowane dla zmienionego obszaru

Takie hooki skracają pętlę feedbacku bez uruchamiania armaty do każdego przecinka.

Wzorzec 2: terminal guardrail

To wzorzec defensywny.

PreToolUse sprawdza wywołanie terminala i podejmuje decyzję:

• allow dla prostych, bezpiecznych poleceń
• ask dla operacji o większym promieniu
• deny dla komend destrukcyjnych albo niezgodnych z polityką

To świetnie działa w repozytoriach, gdzie chcesz zostawić agentowi dużą swobodę edycji plików, ale nie chcesz oddawać mu terminala bez żadnego filtra.

Wzorzec 3: audit trail i compliance log

Nie każda automatyzacja musi coś blokować albo naprawiać.

Czasem największą wartością jest ślad operacyjny:

• jakie narzędzia agent wywołał
• na jakich plikach pracował
• kiedy pojawiły się blokady albo ostrzeżenia

To przydaje się szczególnie wtedy, gdy z agentów korzysta więcej osób i chcesz wiedzieć nie tylko, że coś poszło źle, ale też jak wyglądała droga do tego stanu.

Wzorzec 4: context injection na starcie sesji

SessionStart albo SubagentStart pozwalają wstrzyknąć dodatkowy kontekst do rozmowy.

To może być na przykład:

• aktywna gałąź
• wersja Node albo .NET
• informacja o trybie repo
• ostrzeżenie, że dany katalog jest wrażliwy

To dobry wzorzec wtedy, gdy agent regularnie popełnia ten sam typ błędu, bo brakuje mu jednego, krótkiego kawałka kontekstu operacyjnego.

Nie myl tego jednak z dumpingiem kontekstu. Jeśli wstrzykujesz pół dokumentacji projektu na start każdej sesji, to najczęściej próbujesz hookiem naprawić źle zaprojektowane instructions.

Wzorzec 5: agent-scoped hooks

To jeden z ciekawszych kierunków w aktualnych docsach.

Hook może być osadzony bezpośrednio w custom agencie. Wtedy działa tylko wtedy, gdy ten agent jest aktywny albo wywołany jako subagent.

To bardzo praktyczne, bo nie każda automatyzacja powinna być globalna.

Przykłady:

• agent review może logować wszystkie wyniki analizy
• agent implementacyjny może odpalać formatowanie po edycji
• agent bezpieczeństwa może mieć bardziej restrykcyjne guardraile niż reszta workflow

To znacznie dojrzalszy model niż wrzucanie wszystkiego do jednego katalogu .github/hooks.

Wzorzec 6: policy hooks zamiast nadmiaru ręcznych approvali

Jeśli ciągle klikasz te same approvale, to zwykle znak, że brakuje warstwy polityki.

W dobrze ustawionym workflow hook przejmuje powtarzalną decyzję i zostawia manualny approval tylko tam, gdzie rzeczywiście trzeba ocenić kontekst.

To jest bardzo ważna granica. Hook ma zmniejszać tarcie, ale nie powinien ukrywać ryzyka. Jeśli decyzja jest z natury zależna od sytuacji, zostaw ask i człowieka w pętli.

Czego raczej nie automatyzować

Najczęstsze złe pomysły wyglądają efektownie, ale psują pracę:

• pełna bateria testów po każdej małej edycji
• hook robiący pięć rzeczy naraz i trudno diagnozowalny
• automatyczne akceptowanie wszystkiego, bo “to tylko lokalne repo”
• skrypty hooków, które agent może swobodnie edytować i zaraz potem uruchamiać

To nie są zaawansowane workflow. To są problemy czekające na eksplozję.

Myśl warstwami, nie maksymalizacją automatyzacji

Dobry system hooków zwykle ma trzy warstwy:

• szybkie automaty po pojedynczym kroku
• ostrzejsze walidacje przy większym ryzyku
• manualną decyzję tam, gdzie koszt błędu jest realny

To pozwala zachować zarówno tempo, jak i sensowny nadzór.

Ćwiczenie praktyczne

Rozpisz dwa schematy automatyzacji:

1. Dla projektu frontendowego.
2. Dla projektu backendowego.

W każdym przypadku odpowiedz:

• które eventy hooków wybierasz
• co ma być automatyczne po każdej edycji
• co wymaga ask
• co blokujesz bezwzględnie
• które hooki powinny być globalne, a które agent-scoped

Na końcu sprawdź, czy któryś z hooków nie próbuje robić zbyt dużo naraz. Jeśli tak, rozbij go na mniejsze polityki.

Kluczowe wnioski

• Hooki najlepiej projektować jako katalog małych wzorców, a nie jedną wielką maszynę automatyzującą wszystko.
• Najbardziej praktyczne schematy to local CI, terminal guardrails, audit trail i agent-scoped hooks.
• Dobra automatyzacja zmniejsza liczbę ręcznych decyzji, ale nie ukrywa ryzyka.
• Jeśli hook staje się bardziej skomplikowany niż problem, który rozwiązuje, trzeba go uprościć.

Co dalej

Hooki porządkują zachowanie agenta wewnątrz VS Code. Następny krok idzie szerzej: jak podłączać do Copilota zewnętrzne narzędzia i dane przez MCP, czyli Model Context Protocol.