Jak dać GitHub Copilotowi kontekst — instrukcje repozytorium, tryb agenta i MCP

Jeśli w każdej rozmowie z Copilotem przypominasz mu, że projekt używa Vue, że testy uruchamia się jednym konkretnym poleceniem, a nazwy plików piszecie małymi literami, to płacisz za ten sam kontekst raz za razem. Copilot nie zna kontekstu projektu, dopóki mu go nie zapiszesz, i sięga do świata tylko tymi drogami, które mu otworzysz. Pokażę ci trzy elementy, które o tym decydują: instrukcje repozytorium, tryb agenta w edytorze i serwery MCP. Przy każdym powiem, co zrobić najpierw i na co uważać.

Trzy poziomy instrukcji

Instrukcje własne (custom instructions) to zwykły tekst, który Copilot dostaje automatycznie razem z twoim pytaniem. Działają na trzech poziomach:

Instrukcje organizacji wymagają planu Copilot Business albo Enterprise i obecnie działają w czacie na GitHubie, w przeglądzie kodu przez Copilota i w agencie w chmurze. Najwięcej daje poziom repozytorium, bo tam leży wiedza o projekcie.

Jedno zastrzeżenie na start. Model językowy nie jest deterministyczny, więc Copilot nie zawsze zastosuje instrukcję dokładnie tak samo. Instrukcje podnoszą trafność odpowiedzi, ale nie gwarantują zgodności z żadną polityką.

Instrukcje repozytorium: trzy rodzaje plików

W repozytorium masz trzy rodzaje instrukcji i każdy odpowiada na inne pytanie.

Instrukcje dla całego repozytorium to plik .github/copilot-instructions.md. Trafia do każdego zapytania w kontekście repozytorium, także do czatu i przeglądu kodu przez Copilota. Tu opisujesz, czym jest projekt, jak go zbudować i przetestować oraz jakich konwencji pilnować.

Instrukcje dla wybranych ścieżek to pliki pasujące do wzorca .github/instructions/**/*.instructions.md, czyli NAZWA.instructions.md w katalogu .github/instructions albo w jego podkatalogach. Na początku każdego pliku stoi blok z kluczem applyTo i wzorcem ścieżek:

---
applyTo: "**/*.ts,**/*.tsx"
---
Komponenty piszemy jako funkcje. Każdy nowy komponent dostaje test.

Jeśli plik, nad którym pracuje Copilot, pasuje do wzorca, a istnieje też plik dla całego repozytorium, Copilot dostaje oba zestawy. Dzięki temu nie przeładowujesz głównego pliku zasadami, które dotyczą tylko testów albo jednego katalogu. Opcjonalny klucz excludeAgent z wartością "code-review" albo "cloud-agent" wyłącza dany plik dla przeglądu kodu albo dla agenta w chmurze. Na GitHubie instrukcje dla ścieżek działają obecnie tylko w agencie w chmurze i w przeglądzie kodu.

Instrukcje dla agentów to pliki AGENTS.md, które możesz położyć w dowolnym miejscu repozytorium. Gdy Copilot pracuje, pierwszeństwo ma plik najbliższy w drzewie katalogów. Zamiast nich możesz trzymać jeden plik CLAUDE.md albo GEMINI.md w katalogu głównym. Nie myl ich z definicjami własnych agentów w .github/agents: tamte pliki opisują wyspecjalizowanych agentów i ich konfigurację, a nie zasady pracy w repozytorium.

To, które rodzaje działają, zależy od miejsca (GitHub, VS Code, Visual Studio, JetBrains, Xcode, Eclipse) i od zadania: czatu, pracy agenta w chmurze albo przeglądu. Zanim zbudujesz całą strukturę, sprawdź w dokumentacji swojego środowiska, co obsługuje.

Co wygrywa, gdy instrukcje się różnią

W czacie na GitHubie Copilot dostaje wszystkie pasujące instrukcje, a przy konflikcie obowiązuje kolejność:

1. instrukcje osobiste;
2. instrukcje repozytorium: najpierw pliki dla ścieżek, potem plik dla całego repozytorium, potem AGENTS.md;
3. instrukcje organizacji.

W wielu innych miejscach, między innymi w Copilot CLI, VS Code i Visual Studio, pliki są po prostu łączone, bez ogólnej kolejności. Wniosek praktyczny: nie pisz instrukcji, które sobie przeczą. Jeśli podejrzewasz, że to one psują odpowiedzi, wyłącz na chwilę instrukcje repozytorium i porównaj wynik.

Jak pisać instrukcje, które działają

Instrukcje idą razem z każdą wiadomością, więc mają dotyczyć większości zapytań w repozytorium. Najlepiej działają krótkie, samodzielne zdania. Dobry plik zawiera trzy rzeczy:

• krótki opis projektu: cel, kontekst i najważniejsze założenia;
• standardy kodu: nazewnictwo, formatowanie, przyjęte praktyki;
• narzędzia, biblioteki i frameworki, z wersjami tam, gdzie to ma znaczenie.

Przykładowe zdania: „Używaj Vue z biblioteką PrimeVue.” albo „Stosuj wczesne wyjście z funkcji wszędzie, gdzie się da.” Takie zdanie Copilot zrozumie bez dopytywania.

W dużym repozytorium z wieloma osobami trzy typy instrukcji mogą sprawiać kłopot:

• odsyłanie do zewnętrznych zasobów („trzymaj się przewodnika stylu z innego repozytorium”);
• narzucanie stylu odpowiedzi („odpowiadaj jak koleżeński współpracownik”);
• sztywne limity szczegółowości („odpowiadaj w mniej niż N znakach”).

Pliku nie musisz pisać od zera. Agent Copilota w chmurze potrafi sam przejrzeć repozytorium i przygotować copilot-instructions.md: w widoku agentów wybierasz repozytorium i wklejasz prompt, który każe mu udokumentować budowanie, testy, układ projektu i znane obejścia. Agent otwiera roboczy pull request z plikiem i dodaje cię do przeglądu. Przy pierwszym pull requeście agenta w nowym repozytorium Copilot sam zostawia komentarz z linkiem do takiego wygenerowania.

Po zapisaniu instrukcje działają od razu. Żeby sprawdzić, czy czat ich użył, rozwiń listę źródeł nad odpowiedzią i poszukaj tam pliku .github/copilot-instructions.md. Przegląd kodu przez Copilota czyta instrukcje z gałęzi, którą scalasz, a nie z gałęzi docelowej. Zmianę instrukcji przetestujesz więc w tym samym pull requeście, zanim trafi na główną gałąź.

Tryb agenta w edytorze

W trybie agenta Copilot dostaje zadanie wyższego poziomu, sam decyduje, które pliki zmienić, wprowadza zmiany i uruchamia polecenia, aż zadanie będzie skończone. Działa w VS Code, Visual Studio, JetBrains, Xcode i Eclipse. Kontrolę zachowujesz ty: przeglądasz zmiany, a polecenia terminala domyślnie zatwierdzasz przed uruchomieniem. Administrator albo twoje własne ustawienia mogą pozwolić na automatyczne uruchamianie części poleceń.

Tryb agenta wybierasz, gdy:

• zadanie ma wiele kroków, wymaga kilku przebiegów i obsługi błędów;
• chcesz, żeby to Copilot ustalił kolejne kroki;
• zadanie wymaga pracy z zewnętrzną aplikacją, na przykład przez serwer MCP.

Start wygląda wszędzie podobnie: otwierasz czat Copilota, w przełączniku trybów wybierasz Agent i wpisujesz prompt. Copilot pokazuje zmiany w edytorze na bieżąco, aktualizuje zestaw plików roboczych i w razie potrzeby proponuje polecenia terminala. Jeśli nie widzisz opcji Agent, administrator organizacji mógł wyłączyć ten tryb dla twojego edytora.

Agenta prowadzisz w trakcie pracy. Możesz wysłać kolejny prompt i zmienić kierunek, zanim skończy, zatwierdzić albo odrzucić każde proponowane polecenie terminala oraz cofnąć zmianę, której nie chcesz. Przy dużym albo niejasnym zadaniu najpierw poproś o plan zmian, a dopiero potem o kod. Przed wysłaniem zadania możesz też zmienić model albo wybrać własnego agenta przygotowanego pod dany typ pracy.

Pamiętaj o kosztach: każdy wysłany prompt (wiadomość do agenta) zużywa kredyty AI GitHuba.

MCP: drzwi do narzędzi i danych

Model Context Protocol (MCP) to otwarty standard, który opisuje, jak aplikacje przekazują kontekst modelom językowym. W Copilocie dodaje połączenia z narzędziami i danymi. Na przykład podłączony system zgłoszeń pozwala Copilotowi samemu sprawdzić błąd, nad którym pracuje, bez kopiowania treści do czatu. MCP nie zastępuje instrukcji: instrukcje mówią, jak pracować, a MCP daje dostęp do tego, czego agent potrzebuje.

MCP działa w aplikacji GitHub Copilot, w Copilot CLI, w edytorach i w agencie w chmurze, ale w każdym z tych miejsc konfiguruje się go inaczej. Nie zakładaj, że ustawienie z jednego miejsca działa w drugim.

Agent w chmurze startuje z dwoma serwerami:

• GitHub: dostęp do zgłoszeń, pull requestów i danych repozytorium, domyślnie z uprawnieniami tylko do odczytu, ograniczonymi do bieżącego repozytorium;
• Playwright: czytanie stron, klikanie i zrzuty ekranu, domyślnie tylko na localhost w środowisku agenta.

Kolejne serwery dodaje administrator repozytorium w jego ustawieniach na GitHubie. Ta konfiguracja obowiązuje jednocześnie agenta w chmurze i przegląd kodu przez Copilota. Obsługiwane są tylko narzędzia MCP, bez zasobów i promptów, i nie da się podłączyć zdalnych serwerów, które uwierzytelniają się przez OAuth. Przegląd kodu używa wyłącznie narzędzi oznaczonych jako tylko do odczytu (readOnlyHint: true). Serwer MCP może też należeć do jednego własnego agenta, zamiast być dostępny dla wszystkich agentów w repozytorium.

Jedna rzecz zmienia sposób myślenia o tej konfiguracji: agent w chmurze używa narzędzi MCP samodzielnie i nie pyta o zgodę przed ich wywołaniem. W edytorze zatwierdzasz polecenia. W chmurze tę rolę pełni lista dozwolonych narzędzi.

Dlatego przy każdym serwerze trzymaj się czterech zasad:

1. Sprawdź serwer firmy trzeciej przed włączeniem: jakie ma narzędzia, jak się uwierzytelnia, do jakich danych sięga.
2. Włącz tylko potrzebne narzędzia. Polem tools w ustawieniach repozytorium ustaw listę dozwolonych narzędzi, najlepiej tylko do odczytu.
3. Ogranicz uprawnienia. Nie poszerzaj domyślnych kluczy dostępu agenta, jeśli zadanie tego nie wymaga.
4. Sprawdź konfigurację w sesji, zanim zaczniesz na niej polegać: które serwery i narzędzia agent naprawdę widzi.

Ta sama logika dotyczy serwera MCP GitHuba. Dzieli on swoje możliwości na zestawy narzędzi (toolsets), które włączasz albo wyłączasz. Mniej narzędzi to trafniejszy wybór narzędzia przez model, mniej błędów i więcej miejsca w oknie kontekstowym.

W firmie decyzja należy też do administratorów. Dla planów Copilot Business i Enterprise użycie MCP reguluje osobna polityka, domyślnie wyłączona. Gotowych serwerów od partnerów i społeczności możesz szukać w GitHub MCP Registry.

Kolejność, którą polecam

Zacznij od instrukcji repozytorium, bo bez nich każda kolejna warstwa pracuje po omacku: wygeneruj plik agentem albo napisz go sam, krótko, i sprawdź na kilku pytaniach, czy pojawia się w źródłach odpowiedzi. Potem pracuj w trybie agenta w edytorze, gdzie widzisz każdy krok i uczysz się, czego Copilotowi brakuje. MCP dodawaj na końcu, po jednym serwerze, z listą dozwolonych narzędzi. Kontekst, który zapiszesz w repozytorium, działa w każdej rozmowie, a tylko taki kontekst przetrwa zmianę osoby przy klawiaturze.

Twój zespół pracuje z GitHub Copilot? Zobacz pilotaż GitHub Copilot.