Kontekst dla GitHub Copilot — checklista instrukcji, trybu agenta i MCP

Tę checklistę przechodzisz na jednym, konkretnym repozytorium, z jego plikami otwartymi obok. Pięć bloków idzie w kolejności, w jakiej warto budować kontekst dla Copilota: najpierw instrukcje repozytorium, potem ich treść i weryfikacja, następnie tryb agenta w edytorze, a na końcu serwery MCP. Przy każdym bloku masz pola do odhaczenia i jedno zdanie do zapamiętania.

Przypomnę dwa pojęcia. Instrukcje własne to tekst, który Copilot dostaje automatycznie razem z każdym zapytaniem w kontekście repozytorium. MCP (Model Context Protocol) to otwarty standard podłączania narzędzi i danych do modelu. Instrukcje mówią, jak pracować. MCP daje dostęp do tego, czego agent potrzebuje.

1. Właściwy plik na właściwym poziomie

• [ ] Wiesz, które rodzaje instrukcji obsługuje twoje środowisko (GitHub, VS Code, Visual Studio, JetBrains, Xcode, Eclipse) i zadanie (czat, agent w chmurze, przegląd kodu).
• [ ] Preferencje osobiste (język odpowiedzi, poziom szczegółów) są w instrukcjach osobistych, a nie w repozytorium.
• [ ] Wiedza o projekcie jest w .github/copilot-instructions.md.
• [ ] Zasady dotyczące tylko części plików są w plikach .github/instructions/**/*.instructions.md z blokiem applyTo i wzorcem ścieżek.
• [ ] Tam, gdzie plik ma działać tylko w jednym miejscu, jest klucz excludeAgent z wartością "code-review" albo "cloud-agent".
• [ ] Jeśli używasz AGENTS.md, wiesz, że wygrywa plik najbliższy w drzewie katalogów. Zamiast nich możesz mieć jeden CLAUDE.md albo GEMINI.md w katalogu głównym.
• [ ] Nie mylisz instrukcji dla agentów z definicjami własnych agentów w .github/agents.
• [ ] Wytyczne dla całej organizacji (język, bezpieczeństwo, zgodność) są w instrukcjach organizacji, jeśli macie plan Business albo Enterprise.

Każda zasada ma jedno miejsce. Ta sama zasada zapisana na trzech poziomach to trzy okazje do sprzeczności.

2. Treść instrukcji

• [ ] Plik zaczyna się od krótkiego opisu projektu: cel, kontekst, główne założenia.
• [ ] Są w nim standardy kodu: nazewnictwo, formatowanie, przyjęte praktyki.
• [ ] Są w nim narzędzia, biblioteki i frameworki, z wersjami tam, gdzie to ma znaczenie.
• [ ] Jest w nim opis budowania, testowania i lintowania, z poleceniami, które naprawdę działają.
• [ ] Każda zasada to krótkie, samodzielne zdanie, które dotyczy większości zapytań w repozytorium.
• [ ] Nie ma w nim odsyłania do zewnętrznych zasobów, narzucania stylu odpowiedzi ani sztywnych limitów długości.
• [ ] Żadna zasada nie przeczy instrukcjom osobistym ani organizacji.
• [ ] Plik nie jest pisany pod jedno zadanie.

Instrukcje idą z każdą wiadomością. Zasada, która dotyczy jednego zadania, należy do zgłoszenia, a nie do pliku.

3. Sprawdzenie, czy instrukcje działają

• [ ] Jeśli nie masz pliku, poproś agenta Copilota w chmurze o jego wygenerowanie i przejrzyj roboczy pull request jak każdy inny.
• [ ] Po zapisaniu zadaj w czacie kilka pytań o projekt i rozwiń listę źródeł nad odpowiedzią: plik .github/copilot-instructions.md ma tam być.
• [ ] Zmiany instrukcji testujesz w tym samym pull requeście, bo przegląd kodu przez Copilota czyta instrukcje z gałęzi, którą scalasz.
• [ ] Opcja „Use custom instructions when reviewing pull requests” w ustawieniach repozytorium jest w takim stanie, jakiego oczekujesz.
• [ ] Jeśli odpowiedzi się pogorszyły, wyłącz na chwilę instrukcje repozytorium i porównaj wynik.
• [ ] Pamiętasz, że model nie stosuje instrukcji zawsze identycznie, więc instrukcje nie zastępują reguł repozytorium ani przeglądu.

Jeśli pliku .github/copilot-instructions.md nie ma w źródłach odpowiedzi czatu, czat go nie użył. Sprawdź to, zanim poprawisz treść.

4. Tryb agenta w edytorze

• [ ] W przełączniku trybów czatu Copilota widzisz opcję Agent. Jeśli jej nie ma, pytasz administratora, czy tryb nie jest wyłączony.
• [ ] Tryb agenta wybierasz do zadań wieloetapowych, z iteracją i obsługą błędów, albo wymagających zewnętrznego narzędzia.
• [ ] Przy dużym albo niejasnym zadaniu najpierw prosisz o plan, a dopiero potem o kod.
• [ ] Przed wysłaniem zadania wybierasz model albo własnego agenta pasującego do pracy.
• [ ] Każde polecenie terminala zatwierdzasz albo odrzucasz. Wiesz, które polecenia (jeśli jakiekolwiek) mogą uruchamiać się automatycznie i kto o tym zdecydował.
• [ ] Zmiany przeglądasz na bieżąco i cofasz te, których nie chcesz.
• [ ] Gdy agent idzie w złą stronę, wysyłasz kolejny prompt i zmieniasz kierunek, zamiast czekać na koniec.
• [ ] Pamiętasz, że każdy wysłany prompt (wiadomość do agenta) zużywa kredyty AI GitHuba.

W edytorze to ty zatwierdzasz kroki agenta. Wykorzystaj to, żeby zobaczyć, czego brakuje w instrukcjach, i dopisz to do pliku.

5. Serwery MCP

• [ ] Wiesz, gdzie konfigurujesz MCP w swoim miejscu pracy: aplikacja GitHub Copilot, Copilot CLI, edytor i agent w chmurze mają osobne ustawienia.
• [ ] Dla agenta w chmurze znasz serwery domyślne: GitHub (uprawnienia tylko do odczytu, tylko bieżące repozytorium) i Playwright (tylko localhost w środowisku agenta).
• [ ] Pamiętasz, że agent w chmurze wywołuje narzędzia MCP bez pytania o zgodę.
• [ ] Każdy serwer firmy trzeciej jest sprawdzony: narzędzia, uwierzytelnianie, dane, do których sięga.
• [ ] W ustawieniach repozytorium pole tools zawiera listę dozwolonych narzędzi, najlepiej tylko do odczytu, a nie wszystkie.
• [ ] Domyślne klucze dostępu agenta nie są poszerzone bez potrzeby zadania.
• [ ] Serwer potrzebny tylko jednemu własnemu agentowi jest zdefiniowany w jego profilu, a nie dla całego repozytorium.
• [ ] Nie podłączasz zdalnych serwerów, które uwierzytelniają się przez OAuth, do agenta w chmurze i nie oczekujesz zasobów ani promptów MCP, bo obsługiwane są tylko narzędzia.
• [ ] Narzędzia, których ma używać przegląd kodu, mają readOnlyHint: true.
• [ ] W serwerze MCP GitHuba włączasz tylko potrzebne zestawy narzędzi (toolsets).
• [ ] W firmie wiesz, czy polityka MCP dla planów Business i Enterprise jest włączona (domyślnie jest wyłączona).
• [ ] W sesji agenta sprawdzasz, które serwery i narzędzia są naprawdę dostępne, zanim zaczniesz na nich polegać.

W chmurze listę dozwolonych narzędzi ustawiasz zamiast zatwierdzania każdego wywołania. Każde narzędzie na tej liście to decyzja, którą podejmujesz raz za wszystkie przyszłe sesje.

Po przejściu checklisty

Jeśli bloki 1 do 3 są odhaczone, repozytorium ma kontekst, z którego skorzysta każdy członek zespołu i każdy tryb pracy. Bloki 4 i 5 przechodzisz za każdym razem, gdy dodajesz nowe narzędzie albo nowy sposób pracy z agentem: najpierw w edytorze, gdzie widzisz każdy krok, potem w chmurze, gdzie widzisz tylko wynik.