GitHub Copilot dynamic workflows: jak ułożyć proces dla repozytorium?

Najlepiej zbudować go jako wersjonowane rozszerzenie Copilota w repozytorium: kod zbiera dane i pilnuje kolejności, agent analizuje niejednoznaczne przypadki, a człowiek zatwierdza ważne decyzje. Dynamic workflows łączą kroki automatyczne z pracą agentów, pozwalają przekazywać między etapami ustrukturyzowane wyniki i zatrzymać proces na punkcie kontrolnym. GitHub ogłosił ich dostępność w Copilot CLI, aplikacji Copilot i SDK 1 października 2026 roku; funkcja jest w publicznym preview. (GitHub Changelog, dokumentacja dynamic workflows)

W skrócie

• Definicję workflow trzymaj w rozszerzeniu udostępnionym w repozytorium, aby zespół korzystał z tych samych kroków i reguł.
• Polecenia i warunki kontroluj kodem, a agentom powierzaj analizę, która wymaga oceny.
• Zacznij od małego zakresu, ogranicz uprawnienia i koszty, a wynik zatrzymuj do przeglądu człowieka.

Co dynamic workflow zmienia w pracy z repozytorium?

Zwykły prompt zostawia Copilotowi wybór kolejnych działań. W dynamic workflow autor definiuje w kodzie etapy, warunki i przekazywanie wyników, a agenci wykonują wybrane fragmenty pracy. Etapy mogą przebiegać po kolei lub równolegle. Dzięki temu można powtarzać logikę procesu, ale nie należy oczekiwać identycznej analizy ani raportu za każdym razem: wynik agenta zależy od wejścia i jego oceny. (dokumentacja GitHuba)

To przydatne tam, gdzie zadanie regularnie obejmuje te same kontrole, ale część wniosków wymaga rozumienia kodu. GitHub wskazuje między innymi przegląd wielu zmienionych plików w pull requeście, kontrole wydania i analizę incydentu przez agentów badających różne systemy. (GitHub Changelog, dokumentacja GitHuba)

Jak zaprojektować workflow do przeglądu pull requestu?

Proponuję zacząć od procesu, który tworzy raport i nie modyfikuje plików. Ogranicza to zakres działania agenta, a zespół może ocenić jakość analizy przed dodaniem kolejnych uprawnień.

1. Ustal wejście. Zdefiniuj, skąd workflow bierze bazową i bieżącą rewizję, które katalogi obejmuje oraz co ma zwrócić. Poleciłbym przekazywać zakres jawnie, zamiast pozwalać agentowi samodzielnie zgadywać, co należy sprawdzić.
2. Zbierz dane deterministycznie. Kod może wyliczyć zmienione pliki, pobrać diff i zebrać wyniki istniejących kontroli. Workflow może uruchamiać polecenia, używać narzędzi i korzystać z usług, a więc nie trzeba powierzać agentowi decyzji o każdym kroku technicznym. (dokumentacja GitHuba)
3. Rozdziel analizę. Agent może ocenić ryzyko regresji, a drugi przejrzeć testy lub bezpieczeństwo. Równoległość ma sens, gdy zadania są niezależne. Poproś o wynik w ustalonym formacie, na przykład z lokalizacją problemu, dowodem w kodzie i sugerowaną poprawką. Workflow może przekazywać ustrukturyzowane wyniki między etapami. (dokumentacja GitHuba)
4. Zweryfikuj raport. W kodzie można odrzucić niekompletne wyniki, połączyć powtarzające się uwagi i przygotować czytelne podsumowanie. Jeśli etap wymaga osądu, można zlecić agentowi sprawdzenie ustaleń innego agenta. Traktowałbym to jako dodatkową kontrolę, a nie dowód, że wniosek jest prawdziwy.
5. Zatrzymaj proces przed działaniem. Ustaw punkt, w którym człowiek przegląda raport przed zmianą kodu, publikacją komentarza albo uruchomieniem dalszych działań. Dynamic workflows mogą pytać o dane wejściowe, jeśli dany klient to obsługuje, i wstrzymywać przebieg do późniejszego wznowienia. (dokumentacja GitHuba)

Podczas tworzenia workflow w interaktywnej sesji można poprosić Copilota o przygotowanie procesu, określając jego nazwę, kolejność etapów, miejsca użycia agentów i limity. Na przykład: utwórz repo-pr-review, który zbiera zmienione pliki, analizuje je bez edycji i zwraca raport z dowodami. Po wygenerowaniu sprawdziłbym, czy workflow został zarejestrowany, a następnie uruchomił go na niewielkim zakresie. (instrukcja tworzenia workflow)

Jak udostępnić go zespołowi i uruchamiać?

Dynamic workflows są częścią rozszerzeń Copilota. Dokumentacja pokazuje, jak skopiować rozszerzenie do katalogu .github/extensions/ w repozytorium. Po zatwierdzeniu tej zmiany w repozytorium pozostali członkowie zespołu mogą pobrać definicję i załadować rozszerzenie. Współdzielona jest definicja procesu, nie historia jego uruchomień ani zapisany postęp. (instrukcja udostępniania workflow)

W Copilot CLI workflow można uruchomić z terminala, przekazując argumenty jako JSON i zapisując zwrócony wynik do pliku. Przykładowe wywołanie wygląda tak:

copilot workflow run repo-pr-review --args @workflow-input.json --allow-tool=read --result-file review.json

Nazwa i pola argumentów muszą odpowiadać definicji przygotowanej przez zespół. Przy takim uruchomieniu CLI nie pokazuje okien zgody na uprawnienia. Trzeba wcześniej przyznać wymagane dostępy, a żądania, których nie zatwierdzono automatycznie, zostaną odrzucone. (instrukcja uruchamiania workflow)

Dlatego przed dodaniem rozszerzenia do repozytorium przejrzałbym jego kod, polecenia i wywoływane usługi. Szczególnie uważnie sprawdziłbym uprawnienia do zapisu, sieci i danych poza repozytorium. Dokumentacja zaznacza, że kod rozszerzenia może wykonywać się poza standardowymi monitami uprawnień; rozszerzenie projektowe należy włączać tylko wtedy, gdy ufa się jego kodowi. (dokumentacja dynamic workflows, instrukcja uruchamiania workflow)

Jak kontrolować jakość, czas i koszty?

Zacząłbym od dwóch lub trzech plików, sprawdził trafność uwag i dopiero potem rozszerzył zakres. GitHub zaleca mały test przed większym przebiegiem, a limity workflow mogą obejmować liczbę aktywnych agentów, łączną liczbę uruchomionych agentów, czas działania i przybliżone zużycie kredytów AI. Limit kredytów nie jest twardym sufitem: praca, która już trwa, może zwiększyć zużycie ponad ustawioną wartość. (dokumentacja GitHuba)

W interaktywnej sesji Copilot CLI można obserwować przebieg, wstrzymać go lub wznowić. W aplikacji Copilot monitorowanie i zarządzanie przebiegami jest dostępne tylko dla sesji lokalnych; wznowiony workflow może wykorzystać zapisane wyniki ukończonych etapów. Przy wdrożeniu zespołowym zapisywałbym też, jaki wynik uznajemy za użyteczny: na przykład czy każda uwaga wskazuje konkretny fragment kodu i czy raport jasno odróżnia błąd od sugestii. (instrukcja monitorowania i wznawiania workflow)

CLI, aplikacja czy SDK?

Do pracy lokalnej i uruchamiania z terminala wybrałbym Copilot CLI. Dynamic workflows wymagają w nim włączenia funkcji eksperymentalnych przez --experimental albo /experimental on. Aplikacja Copilot udostępnia je bez dodatkowej konfiguracji. GitHub potwierdził też dostępność przez Copilot SDK, a dokumentacja opisuje programowe uruchamianie workflow z kodu korzystającego z SDK. To kierunek dla zespołu, który chce osadzić taki przebieg we własnym narzędziu lub usłudze. (GitHub Changelog, dokumentacja GitHuba)

Na 5 października 2026 dynamic workflows pozostają w publicznym preview, więc przed uzależnieniem od nich krytycznego procesu sprawdziłbym aktualną dokumentację i ograniczył wpływ niepowodzenia workflow. (GitHub Changelog)

Dobry agentowy workflow dla repozytorium nie polega na tym, by agent przejął całą procedurę. Polega na tym, by stałe kroki były jawne i wersjonowane, analiza trafiała do agentów, a człowiek miał czytelny punkt kontroli. Od takiego procesu zacząłbym automatyzację przeglądów, kontroli wydania i analizy incydentów.