Agent Copilota w chmurze — karta przed przypisaniem zadania

Tę kartę otwierasz obok repozytorium, zanim przypiszesz zgłoszenie agentowi GitHub Copilot w chmurze. Sześć bloków idzie w kolejności pracy: najpierw decydujesz, czy zadanie w ogóle jest dla agenta, potem piszesz zgłoszenie, sprawdzasz repozytorium i granice, a na końcu prowadzisz przegląd. Ostatni blok przyda się raz, przy pierwszej próbie z zespołem. Przy każdym bloku masz pola do odhaczenia i jedno zdanie do zapamiętania.

Jedno przypomnienie na start. Agent w chmurze pracuje sam, w osobnym środowisku na GitHub Actions, i oddaje wynik jako pull request. Nie siedzisz przy nim, więc wszystko, czego potrzebuje, musi być zapisane wcześniej.

1. Czy to zadanie dla agenta

• [ ] Zadanie da się opisać w kilku zdaniach, bez „zobaczymy w trakcie”.
• [ ] Wynik ocenisz w krótkim przeglądzie: poprawka błędu, test, drobna zmiana w interfejsie, dostępność, dokumentacja, konfiguracja, dług techniczny w jednym miejscu.
• [ ] Zadanie nie wymaga wiedzy z kilku repozytoriów ani dużej przebudowy, w której liczy się spójność projektu.
• [ ] Zadanie nie dotyka awarii produkcyjnej, incydentu, bezpieczeństwa, danych osobowych ani uwierzytelniania.
• [ ] Nie jest to zadanie, przy którym programista chce sam się czegoś nauczyć.
• [ ] Jeśli któryś punkt wyżej nie przechodzi, zostaw zadanie człowiekowi albo potnij je na mniejsze.

Agent dostaje zadania, których wynik ocenisz szybko. Granicę przesuwasz dopiero wtedy, gdy zobaczysz, z czym sobie radzi.

2. Zgłoszenie, które zadziała jako prompt

• [ ] Przeczytaj zgłoszenie tak, jakby było promptem dla modelu. Czy wiadomo z niego, co zrobić?
• [ ] Opis problemu albo pracy jest jasny i kompletny.
• [ ] Kryteria odbioru są zapisane, na przykład: czy mają powstać testy jednostkowe, co ma przechodzić, czego nie wolno zmieniać.
• [ ] Wskazówki, które pliki albo katalogi zmienić, są dopisane tam, gdzie je znasz.
• [ ] Przy większym zadaniu poproś najpierw o zbadanie repozytorium, plan i zmiany na gałęzi, a pull request dopiero po obejrzeniu różnic.

Treść zgłoszenia to cała instrukcja, jaką agent dostaje od ciebie. Jeśli nie zadziałałaby jako prompt, nie przypisuj jej.

3. Repozytorium gotowe na agenta

• [ ] W repozytorium jest plik .github/copilot-instructions.md z opisem projektu, sposobem budowania i testowania oraz konwencjami.
• [ ] Zasady dla wybranych typów plików leżą w .github/instructions/**/*.instructions.md z kluczem applyTo, a nie w głównym pliku.
• [ ] Zależności projektu są preinstalowane w copilot-setup-steps.yml, żeby agent nie zgadywał ich metodą prób i błędów.
• [ ] Agent może zbudować projekt, uruchomić testy i lintery w swoim środowisku.
• [ ] Dla powtarzalnej, wyspecjalizowanej pracy rozważ własnego agenta z ograniczonym zestawem narzędzi, na przykład agenta od testów bez prawa do zmian w kodzie produkcyjnym.

Agent, który sam zbuduje i przetestuje zmianę, częściej oddaje pull requesty gotowe do scalenia. Agent, który zgaduje zależności, oddaje pull requesty do poprawki.

4. Granice przed włączeniem

• [ ] Wiesz, w których organizacjach i repozytoriach agent będzie włączony.
• [ ] Wiesz, do jakich serwerów MCP dostanie dostęp, i każdy z nich jest świadomą decyzją.
• [ ] Zestawy reguł (rulesets) w repozytoriach z agentem mają potrzebne wymogi, na przykład wyniki skanowania kodu.
• [ ] Żadna obecna reguła nie blokuje agenta przez wymogi dotyczące metadanych commita.
• [ ] Pliki konfiguracji Copilota i MCP są w CODEOWNERS, a reguła wymaga przeglądu przez właścicieli kodu.
• [ ] Sekrety, których agent nie powinien widzieć, zostają jako sekrety i zmienne GitHub Actions. To, czego potrzebuje, trafia do sekretów i zmiennych agentów.
• [ ] Agent działa na runnerach hostowanych przez GitHuba albo na jednorazowych runnerach własnych.
• [ ] Wiesz, czy workflowy w pull requestach agenta czekają na zatwierdzenie przez osobę z prawem zapisu, i administratorzy repozytoriów znają to ustawienie.
• [ ] Domyślne uprawnienia GITHUB_TOKEN są przejrzane, a w copilot-setup-steps.yml obowiązuje zasada minimalnych uprawnień.

Wbudowane zabezpieczenia agenta (brak wypychania na gałąź domyślną, brak scalania) to punkt wyjścia. Resztę granic ustawiasz ty, zanim agent dostanie repozytorium.

5. Przegląd pull requesta od agenta

• [ ] Prowadzisz go tak samo jak pull request od człowieka: ta sama poprzeczka, te same testy.
• [ ] Uwagi zbierasz w jeden przegląd (Start a review) i wysyłasz razem, zamiast pojedynczych komentarzy.
• [ ] W komentarzu oznaczasz @copilot i piszesz konkretnie, co jest źle albo co poprawić.
• [ ] Komentarze pisze osoba z prawem zapisu, bo na inne agent nie reaguje.
• [ ] Przy konfliktach scalania prosisz agenta o ich rozwiązanie albo poprawiasz gałąź sam.
• [ ] Przed scaleniem sprawdzasz, czy tytuł i opis pull requesta zgadzają się z ostateczną zmianą.

Jeden zebrany przegląd to jedna runda pracy agenta. Pięć pojedynczych komentarzy to pięć osobnych rund.

6. Pierwsza próba w zespole

• [ ] Zespół próby ma osoby z różnych ról.
• [ ] Repozytorium próby jest niskiego ryzyka, na przykład z dokumentacją albo narzędziami wewnętrznymi, i ma już kontekst projektu.
• [ ] Agent jest włączony w tym repozytorium, a instrukcje i narzędzia środowiska są przygotowane.
• [ ] Wybraliście kilka konkretnych zastosowań, na przykład pokrycie testami albo dostępność.
• [ ] Zgłoszenia są przepisane według bloku 2, a zespół wie, że czekają go przeglądy.
• [ ] Po każdym tygodniu poprawiacie instrukcje, narzędzia, dostęp do MCP i sposób pisania zgłoszeń.
• [ ] Notujecie, ile agent zużywa kredytów AI i minut GitHub Actions, żeby zaplanować budżet szerszego uruchomienia.
• [ ] Wpływ oceniacie po celach, które zespół i tak ma, a nie po liczbie pull requestów agenta.

Próba ma ustalić wasze zasady pracy z agentem. Wynikiem są poprawione instrukcje i zgłoszenia, a nie sama decyzja „tak” albo „nie”.

Po przejściu karty

Jeśli wszystkie bloki od 1 do 5 są odhaczone, przypisz zgłoszenie i wróć do niego przy przeglądzie. Jeśli któryś punkt nie przechodzi, zatrzymaj się właśnie tam: poprawka zgłoszenia albo reguły zajmie mniej czasu niż przegląd pull requesta, który powstał bez nich.