GitHub Copilot CLI workflow: proces z punktami kontroli

Polecam zacząć od kontroli dokumentacji:

• Ustal konkretne pliki wejściowe i format raportu.
• Oddziel zebranie danych od ich oceny.
• Sprawdź, czy proces rzeczywiście zatrzymuje się przed raportem.
• Zachowaj rozszerzenie i sprawdź jego dostępność w nowej sesji.

Celem ćwiczenia jest wykrycie sprzeczności między dwoma dokumentami. Nie będziemy poprawiać ich automatycznie.

Przykład wykonuj w Ubuntu 24.04 LTS, w terminalu z powłoką Bash, czyli programem interpretującym polecenia. Przygotuj Git, system przechowujący historię zmian projektu, oraz edytor tekstu.

Do dalszych kroków przygotuj interaktywny terminal (TTY), czyli terminal, w którym możesz wpisywać polecenia i odpowiadać na pytania programu, oraz dostęp do przeglądarki do logowania. Ćwiczenie wykonuj w interaktywnej sesji Copilota, opisanej w przewodniku pierwszego uruchomienia; logowanie przez przeglądarkę opisuje instrukcja uwierzytelniania.

Do wybranej tutaj instalacji przez npm potrzebujesz Node.js 22 lub nowszego, środowiska uruchamiającego JavaScript. npm to menedżer pakietów, którym zainstalujesz Copilot CLI. Potrzebujesz też aktywnej subskrypcji Copilota; przy dostępie organizacyjnym administrator musi zezwalać na CLI, jak wskazuje instrukcja instalacji.

Sprawdź również dostępność samych workflows. Dokumentacja wyłącza subskrybentów Copilot Pro i Pro+ na istniejących planach rocznych, którzy pozostają przy starszym systemie rozliczeń, zgodnie z zasadami dostępności dynamicznych przepływów.

Na potrzeby ćwiczenia polecam nowy katalog bez danych prywatnych. Nie umieszczaj w nim haseł, kluczy dostępu ani plików z sekretami.

Agent to część systemu sztucznej inteligencji (AI), która wykonuje przydzielone zadanie i korzysta z narzędzi. Rozszerzenie to kod dodający funkcje do Copilota. Dynamiczny workflow przechowuje proces w kodzie rozszerzenia i może łączyć zwykłe operacje z analizą agentów, jak wyjaśnia zapowiedź GitHuba.

Polecam następujący podział pracy. To projekt naszego ćwiczenia, a nie gotowy workflow dostarczany przez GitHub.

Punkt kontroli to miejsce, w którym sprawdzasz wynik przed kontynuowaniem procesu. Nasz plan wygląda tak:

flowchart TD
    A[Odczyt plików] --> B[Porównanie przez agenta]
    B --> C[Zapis ustaleń]
    C --> D[Pauza na kontrolę]
    D --> E[Wznowienie przez użytkownika]
    E --> F[Raport końcowy]

1. Przygotuj dwa dokumenty do porównania

W wybranym katalogu na projekty uruchom:

git init copilot-workflow-demo
cd copilot-workflow-demo
mkdir -p docs

Initialized empty Git repository in ~/copilot-workflow-demo/.git/

Pierwsze polecenie tworzy lokalne repozytorium, czyli projekt zarządzany przez Git, z katalogiem .git, zgodnie z dokumentacją git init. Kolejne przechodzi do projektu i tworzy folder docs. Oczekuj komunikatu o inicjalizacji repozytorium; dalsze polecenia terminalowe wykonuj z jego głównego katalogu.

W edytorze utwórz plik README.md:

Projekt demonstracyjny: lista zadań.

Limit listy wynosi 10 zadań.
Użytkownik może dodać zadanie i oznaczyć je jako wykonane.

Utwórz plik docs/checklist.md:

Lista kontroli dokumentacji.

Limit listy wynosi 20 zadań.
Przed publikacją porównaj ten limit z README.md.

Zapisz oba pliki. Liczby są celowo różne: wynik kontroli powinien wskazać konflikt między limitem 10 i 20 zadań. To dane demonstracyjne, które pozwolą ocenić, czy proces działa zgodnie z naszym planem.

2. Zainstaluj CLI i włącz funkcję testową

W katalogu projektu wykonaj polecenie z instrukcji instalacji przez npm:

npm install -g @github/copilot

changed 3 packages in 9s

Polecenie instaluje pakiet globalnie, czyli udostępnia narzędzie poza jednym projektem. Jeżeli w konfiguracji ~/.npmrc masz ignore-scripts=true, dokumentacja wymaga zamiast niego:

npm_config_ignore_scripts=false npm install -g @github/copilot

changed 3 packages in 3s

Ten wariant zezwala na wykonanie skryptów instalacyjnych pakietu. Po zakończeniu instalacji, w głównym katalogu projektu, wpisz ręcznie copilot --experimental bezpośrednio w interaktywnym terminalu. Flaga włącza funkcje eksperymentalne, opisane w instrukcji rozpoczęcia pracy z workflows.

Nie wykonuj tego uruchomienia w bezobsługowym skrypcie ani z przekierowanym wejściem. Prompt oznacza tutaj tekst polecenia dla AI. Do wykonywania pojedynczych promptów bez rozmowy GitHub dokumentuje flagę -p, ale kolejne kroki tego ćwiczenia wykonuj w sesji interaktywnej, zgodnie z przewodnikiem pracy z CLI.

Oczekiwany wynik to interaktywna sesja, czyli rozmowa prowadzona bezpośrednio w terminalu. Przy pierwszym uruchomieniu przejdź logowanie i, gdy pojawi się pytanie o zaufanie do katalogu, zatwierdź przygotowany projekt, zgodnie z przewodnikiem pierwszego uruchomienia.

Jeżeli nie jesteś zalogowany, wpisz wewnątrz Copilota:

/login

Wybierz konto GitHub.com i sposób logowania. Dokończ autoryzację w przeglądarce, sprawdź wymagane uprawnienia i zatwierdź Authorize GitHub Copilot CLI; przy organizacji z logowaniem SAML SSO, czyli logowaniem przez firmowego dostawcę tożsamości, autoryzuj także właściwą organizację. Po powrocie do terminala oczekuj komunikatu o udanym logowaniu, zgodnie z instrukcją uwierzytelniania.

Jeśli sesja była już otwarta bez flagi, alternatywą jest wpisanie /experimental on, jak podaje zapowiedź funkcji.

3. Poproś o utworzenie procesu

Opisz cel, etapy, agentów i limity, a po utworzeniu sprawdź rejestrację. Zapis definicji nie uruchamia procesu, zgodnie z instrukcją tworzenia workflow.

Wklej poniższy własny opis zadania do rozmowy z Copilotem.

Utwórz dynamiczny workflow o nazwie kontrola-dokumentacji.
Skorzystaj z wbudowanych wskazówek tworzenia dynamicznych workflows.

Proces nie wymaga parametrów wejściowych.
1. Odczytaj wyłącznie README.md i docs/checklist.md
   z bieżącego projektu. Jeżeli pliku brakuje, zwróć błąd.
2. Poproś jednego agenta o porównanie informacji w tych plikach.
   Każda sprzeczność ma zawierać nazwy obu plików
   i krótkie fragmenty uzasadniające ustalenie.
3. Zachowaj ustalenia i zatrzymaj workflow w punkcie kontroli,
   aby można było je przejrzeć przed wznowieniem.
4. Po wznowieniu zwróć wynik zawierający pola:
   files, findings, summary.

Nie modyfikuj dokumentów, nie uruchamiaj poleceń powłoki
i nie łącz się z zewnętrznymi usługami.
Ustaw limit jednego aktywnego agenta i jednego agenta łącznie.
Ustaw limit aktywnego czasu pracy na 5 minut.
Nie uruchamiaj workflow po jego utworzeniu.

Copilot ma przygotować kod rozszerzenia; jego wygenerowanie jest osobnym etapem od analizy dokumentów. Jeśli pyta o zgodę na tworzenie workflow, wybierz Yes po sprawdzeniu zakresu operacji, zgodnie z procedurą tworzenia.

Następnie wpisz własne pytanie:

Pokaż dostępne dynamiczne workflows.
Opisz etapy workflow kontrola-dokumentacji i wskaż,
gdzie zapisujesz ustalenia przed pauzą.

Oczekuj nazwy kontrola-dokumentacji na liście. Polecam sprawdzić kod i opis etapów przed pierwszym uruchomieniem: odczyt plików, analiza, zachowanie ustaleń, pauza oraz raport muszą odpowiadać zamówionemu procesowi.

4. Uruchom próbę i sprawdź pauzę

W rozmowie wpisz:

Uruchom dynamiczny workflow kontrola-dokumentacji.

Zatwierdź uruchomienie, jeśli Copilot poprosi o zgodę. W sesji użyj /workflows, wybierz przebieg strzałkami i naciśnij Enter, zgodnie z instrukcją monitorowania:

/workflows

Sprawdź, czy ustalenia wskazują konflikt limitów i czy przebieg zatrzymał się przed raportem. Za kryterium powodzenia przyjmij obie rzeczy naraz. Sam poprawny opis sprzeczności nie wystarcza, jeśli proces pominął zamówioną pauzę.

W widoku przebiegów klawisz P służy do pauzowania aktywnego wykonania, R do wznowienia przebiegu możliwego do wznowienia, a X do anulowania. Anulowanego wykonania nie można wznowić, jak wyjaśnia instrukcja zarządzania przebiegami.

Po sprawdzeniu ustaleń wznów przebieg przez R. Oczekiwany raport naszego przykładu powinien zawierać pola zamówione w prompcie oraz wykrytą sprzeczność.

5. Zachowaj definicję i powtórz próbę

Poproś Copilota o wskazanie ścieżki, a następnie skopiowanie workflow do projektu, zgodnie z procedurą ponownego użycia:

Pokaż ścieżkę do workflow kontrola-dokumentacji.

Po otrzymaniu ścieżki wpisz:

Skopiuj workflow kontrola-dokumentacji do katalogu
rozszerzeń bieżącego repozytorium.

Ta operacja dodaje kod rozszerzenia do projektu. Rozszerzenia projektowe znajdują się w .github/extensions/NAME/; osobiste w ~/.copilot/extensions/NAME/, zgodnie z opisem ich lokalizacji. NAME oznacza nazwę katalogu danego rozszerzenia.

Najpierw zakończ bieżącą sesję Copilota, naciskając dwukrotnie Ctrl+C, zgodnie z dokumentacją skrótów CLI, i wróć do powłoki Bash. Dopiero po powrocie do Bash zrestartuj CLI, wpisując ponownie copilot --experimental bezpośrednio w interaktywnym terminalu, i zapytaj o dostępne workflows. Restart jest jednym z dokumentowanych sposobów ponownego załadowania rozszerzenia. Potem uruchom kontrola-dokumentacji jeszcze raz.

Polecam teraz zmienić w docs/checklist.md limit na 10 zadań i wykonać kolejną próbę. To świadoma zmiana danych wejściowych: oczekuj raportu bez wcześniejszej sprzeczności. Sprawdzasz w ten sposób, czy proces czyta aktualne dokumenty.

Funkcja nie jest dostępna

Sprawdź wymagania konta i uruchomienie z --experimental. Aktualizację CLI możesz wywołać przez /update, zgodnie z instrukcją GitHuba:

/update

Polecenie aktualizuje narzędzie. Po aktualizacji ponów uruchomienie i pytanie o workflows.

Workflow znika po restarcie

Sprawdź, czy skopiowano rozszerzenie do projektu lub katalogu osobistego. Domyślnie definicja utworzona przez Copilota jest dostępna tylko w bieżącej sesji, zgodnie z dokumentacją zakresu workflow.

Rozszerzenie nie startuje

W sesji wpisz:

/extensions manage

Sprawdź stan rozszerzenia i ścieżkę jego dziennika błędów, czyli pliku z informacjami o działaniu programu. GitHub wskazuje tę procedurę w poradniku diagnozowania rozszerzeń.

Proces pomija punkt kontroli

Polecam poprosić o poprawienie zapisanej definicji i ponownie sprawdzić ją na dwóch plikach. Przyjmij test pauzy za obowiązkowy warunek przed użyciem procesu na większym projekcie.

Czy workflow zawsze zwróci identyczną odpowiedź?

Nie. Ponownie używasz etapów i reguł, ale odpowiedzi agentów mogą się różnić między wykonaniami, zgodnie z wyjaśnieniem powtarzalności procesu. Polecam porównywać konkretne ustalenia, a nie identyczne brzmienie raportów.

Czy można uruchomić workflow bez otwierania czatu?

Tak. Służy do tego copilot workflow run WORKFLOW-NAME, gdzie WORKFLOW-NAME zastępujesz zarejestrowaną nazwą procesu. Workflow musi być dostępny poza pierwotną sesją, a wymagane uprawnienia trzeba nadać wcześniej: polecenie nie wyświetla pytań o ich zatwierdzenie, zgodnie z dokumentacją uruchamiania programowego.

Czy limit kredytów chroni przed każdym przekroczeniem?

Kredyty AI są jednostką rozliczania użycia Copilota. Limit workflow nie jest ścisłym maksimum: zużycie jest raportowane po wykonaniu pracy, więc rozpoczęte operacje mogą przekroczyć ustawiony limit. GitHub opisuje tę granicę jako przybliżoną w dokumentacji limitów workflow.

Czy harmonogram /every działa po zamknięciu sesji?

Nie. /every wysyła prompt cyklicznie, a /after po zadanym opóźnieniu; oba harmonogramy działają tylko, gdy sesja, w której je utworzono, pozostaje uruchomiona, zgodnie z dokumentacją harmonogramów.

Polecam następną wersję procesu rozszerzyć o przegląd zmian w projekcie.