Zaplanowane zadanie AI sprawdza GitHub w nocy — Claude lub ChatGPT

Utwórz mi zaplanowane zadanie uruchamiane codziennie o godzinie 05:00.

Nazwa zadania: „Poranny przegląd GitHuba”.

Przy każdym uruchomieniu wykonaj następujące zadanie:

Przejrzyj wszystkie repozytoria GitHub należące do połączonego użytkownika. Pomiń repozytoria należące do innych osób lub organizacji, do których użytkownik ma tylko dostęp jako współpracownik albo gość.

Podstawowy zakres analizy stanowi poprzednia pełna doba kalendarzowa: od godziny 00:00 poprzedniego dnia do godziny 00:00 bieżącego dnia.

Dodatkowo uwzględnij commity utworzone bieżącego dnia pomiędzy godziną 00:00 a 02:00. Traktuj je jako przedłużenie poprzedniej sesji pracy i sprawdź je razem z poprzednią dobą.

Przed analizą każdego repozytorium sprawdź czas jego najnowszego commita dostępnego na GitHubie.

Jeżeli najnowszy commit bieżącego dnia został utworzony:

między 00:00 a 02:00 — przeanalizuj repozytorium normalnie i uwzględnij również te commity,
po 02:00, a przed uruchomieniem zadania o 05:00 — uznaj repozytorium za nadal aktywnie rozwijane i pomiń je w całości w tym uruchomieniu.

W takim przypadku zaznacz w raporcie:

„Repozytorium pominięte — aktywna praca po godzinie 02:00”.

Nie analizuj części zmian z takiego repozytorium, ponieważ podczas trwającej pracy późniejsze commity mogą modyfikować lub naprawiać wcześniejsze zmiany.

Przy następnym uruchomieniu, gdy repozytorium nie będzie już aktywnie rozwijane po godzinie 02:00, przeanalizuj wszystkie wcześniej pominięte i dotąd niesprawdzone commity.

Prowadź logiczną ciągłość analizy w taki sposób, aby:

żadna zmiana nie została pominięta,
żadna zmiana nie została przeanalizowana dwukrotnie,
commity z bieżącego dnia z godzin 00:00–02:00, które zostały już sprawdzone wcześniej, nie były ponownie analizowane następnego dnia.

Jeśli nie można wiarygodnie ustalić ostatniego sprawdzonego commita lub zakresu wcześniej przeanalizowanych zmian, zaznacz to wyraźnie w raporcie zamiast zgadywać.

Analizuj przede wszystkim diffy i bezpośrednio zmienione pliki. Możesz odczytać tylko minimalny, bezpośrednio powiązany fragment kodu potrzebny do potwierdzenia użycia zmienionej funkcji, typu, trasy lub konfiguracji. Nie wykonuj pełnej analizy ani audytu całego repozytorium.

Zrób szybki przegląd pod kątem:

błędów składni,
oczywistych błędów logicznych, odwróconych warunków, kodu nieosiągalnego i brakujących return,
błędnych lub brakujących importów, ścieżek, nazw, tras, zmiennych środowiskowych i odwołań,
niezdefiniowanych albo niezainicjalizowanych wartości,
możliwych null, dzielenia przez zero i wyjścia poza zakres,
nieobsłużonych wyjątków, odrzuconych Promise i błędów API,
prostych regresji oraz niezgodności zmienionych sygnatur funkcji lub formatów API z ich użyciami widocznymi w zmianach,
pozostawionych TODO, FIXME, console.log, var_dump, dd i podobnego kodu debugującego,
przypadkowo ujawnionych sekretów, tokenów, haseł, kluczy API lub prywatnych danych,
łatwo zauważalnych SQL injection, XSS, command injection, path traversal, braków walidacji danych wejściowych, błędnego filtrowania danych wyjściowych, problemów z autoryzacją oraz wyłączenia SSL, CSRF lub kontroli uprawnień,
podejrzanych albo zbędnych nowych zależności,
przypadkowo dodanych dużych plików, archiwów, logów, kopii baz i plików tymczasowych,
ryzykownych migracji baz danych mogących usuwać dane,
oczywistych problemów wydajnościowych, takich jak zapytania w pętli lub możliwa pętla nieskończona,
braku aktualizacji testów, gdy zmiana jednoznacznie modyfikuje istniejące zachowanie.

Jeśli jest to możliwe bez szerokiego skanowania projektu, wykonaj wyłącznie lekkie kontrole składni lub testy bezpośrednio odnoszące się do zmienionych plików.

Zgłaszaj tylko problemy wynikające z analizowanego zakresu zmian. Nie zgłaszaj istniejących wcześniej problemów i nie twórz listy ogólnych ulepszeń. Ogranicz fałszywe alarmy. Niczego nie zmieniaj w repozytoriach.

Przygotuj zwięzły raport po polsku. Dla każdego znaleziska podaj:

repozytorium, commit i plik, opis problemu, istotność, krótkie uzasadnienie oraz sugestię poprawki.

Każde znalezisko oznacz jednym z poziomów pewności:

„błąd pewny”
„wysokie ryzyko”
„do sprawdzenia”

Oddziel fakty od przypuszczeń.

Jeśli w analizowanym zakresie nie było zmian albo nie znaleziono problemów, napisz to krótko.

Utwórz to jako aktywne zadanie cykliczne, codziennie o 05:00.

Utwórz mi zaplanowane zadanie uruchamiane codziennie o godzinie 05:00.

Nazwa zadania: „Poranny przegląd GitHuba”.

Przy każdym uruchomieniu wykonaj następujące zadanie:

Przejrzyj wszystkie repozytoria GitHub należące do połączonego użytkownika. Pomiń repozytoria należące do innych osób lub organizacji, do których użytkownik ma tylko dostęp jako współpracownik albo gość.

Podstawowy zakres analizy stanowi poprzednia pełna doba kalendarzowa: od godziny 00:00 poprzedniego dnia do godziny 00:00 bieżącego dnia.

Dodatkowo uwzględnij commity utworzone bieżącego dnia pomiędzy godziną 00:00 a 02:00. Traktuj je jako przedłużenie poprzedniej sesji pracy i sprawdź je razem z poprzednią dobą.

Przed analizą każdego repozytorium sprawdź czas jego najnowszego commita dostępnego na GitHubie.

Jeżeli najnowszy commit bieżącego dnia został utworzony:

między 00:00 a 02:00 — przeanalizuj repozytorium normalnie i uwzględnij również te commity,
po 02:00, a przed uruchomieniem zadania o 05:00 — uznaj repozytorium za nadal aktywnie rozwijane i pomiń je w całości w tym uruchomieniu.

W takim przypadku zaznacz w raporcie:

„Repozytorium pominięte — aktywna praca po godzinie 02:00”.

Nie analizuj części zmian z takiego repozytorium, ponieważ podczas trwającej pracy późniejsze commity mogą modyfikować lub naprawiać wcześniejsze zmiany.

Przy następnym uruchomieniu, gdy repozytorium nie będzie już aktywnie rozwijane po godzinie 02:00, przeanalizuj wszystkie wcześniej pominięte i dotąd niesprawdzone commity.

Prowadź logiczną ciągłość analizy w taki sposób, aby:

żadna zmiana nie została pominięta,
żadna zmiana nie została przeanalizowana dwukrotnie,
commity z bieżącego dnia z godzin 00:00–02:00, które zostały już sprawdzone wcześniej, nie były ponownie analizowane następnego dnia.

Jeśli nie można wiarygodnie ustalić ostatniego sprawdzonego commita lub zakresu wcześniej przeanalizowanych zmian, zaznacz to wyraźnie w raporcie zamiast zgadywać.

Analizuj przede wszystkim diffy i bezpośrednio zmienione pliki. Możesz odczytać tylko minimalny, bezpośrednio powiązany fragment kodu potrzebny do potwierdzenia użycia zmienionej funkcji, typu, trasy lub konfiguracji. Nie wykonuj pełnej analizy ani audytu całego repozytorium.

Zrób szybki przegląd pod kątem:

błędów składni,
oczywistych błędów logicznych, odwróconych warunków, kodu nieosiągalnego i brakujących return,
błędnych lub brakujących importów, ścieżek, nazw, tras, zmiennych środowiskowych i odwołań,
niezdefiniowanych albo niezainicjalizowanych wartości,
możliwych null, dzielenia przez zero i wyjścia poza zakres,
nieobsłużonych wyjątków, odrzuconych Promise i błędów API,
prostych regresji oraz niezgodności zmienionych sygnatur funkcji lub formatów API z ich użyciami widocznymi w zmianach,
pozostawionych TODO, FIXME, console.log, var_dump, dd i podobnego kodu debugującego,
przypadkowo ujawnionych sekretów, tokenów, haseł, kluczy API lub prywatnych danych,
łatwo zauważalnych SQL injection, XSS, command injection, path traversal, braków walidacji danych wejściowych, błędnego filtrowania danych wyjściowych, problemów z autoryzacją oraz wyłączenia SSL, CSRF lub kontroli uprawnień,
podejrzanych albo zbędnych nowych zależności,
przypadkowo dodanych dużych plików, archiwów, logów, kopii baz i plików tymczasowych,
ryzykownych migracji baz danych mogących usuwać dane,
oczywistych problemów wydajnościowych, takich jak zapytania w pętli lub możliwa pętla nieskończona,
braku aktualizacji testów, gdy zmiana jednoznacznie modyfikuje istniejące zachowanie.

Jeśli jest to możliwe bez szerokiego skanowania projektu, wykonaj wyłącznie lekkie kontrole składni lub testy bezpośrednio odnoszące się do zmienionych plików.

Zgłaszaj tylko problemy wynikające z analizowanego zakresu zmian. Nie zgłaszaj istniejących wcześniej problemów i nie twórz listy ogólnych ulepszeń. Ogranicz fałszywe alarmy. Niczego nie zmieniaj w repozytoriach.

Przygotuj zwięzły raport po polsku. Dla każdego znaleziska podaj:

repozytorium, commit i plik, opis problemu, istotność, krótkie uzasadnienie oraz sugestię poprawki.

Każde znalezisko oznacz jednym z poziomów pewności:

„błąd pewny”
„wysokie ryzyko”
„do sprawdzenia”

Oddziel fakty od przypuszczeń.

Jeśli w analizowanym zakresie nie było zmian albo nie znaleziono problemów, napisz to krótko.

Utwórz to jako aktywne zadanie cykliczne, codziennie o 05:00.