Setup — Twoje środowisko AI kodowania

15 min czytania · 1-2 h na setup i testy

Ile razy napisałeś ten sam setup od zera — nowy projekt, nowy Copilot, zero kontekstu, zaczynasz jakby poprzednich miesięcy nie było? A Copilot znowu nie wie nic o Twoim projekcie i sugeruje biblioteki, których nie używasz. Każdy reset kosztuje czas i skupienie, których nie odzyskasz.

Siedzę przed dwiema zakładkami, każda po 4 otwarte terminale. Część agentów pracuje lokalnie, część w chmurze, a w bardziej intensywny dzień równolegle potrafi pracować nawet 20 agentów. Więcej niż 10 na jednej niezbyt mocnej maszynie bardzo szybko może zająć całą pamięć i procesor. Zdarza się też, że zamykam laptopa, idę spać, a rano czeka na mnie gotowy wynik kilku zadań, które domknęły się już beze mnie.

I właśnie dlatego ten setup robi takie wrażenie: to już nie wygląda jak “mam sprytne AI do pomocy”. To zaczyna przypominać małą, dobrze poukładaną firmę operacyjną wokół jednego developera. W tym rozdziale nie będę jeszcze rozkręcał całych kulis. Zrobimy fundament: działający terminal, GitHub Copilot CLI, pierwszy plik instrukcji repo, pierwszy test i prosty model przestrzeni roboczej, na którym później zbudujesz resztę.

Ważna rzecz, zanim pójdziemy dalej: pokazuję ten kurs na Copilocie, bo chcę operować na jednym konkretnym runtime i na oficjalnych docsach, a nie na mieszance luźnych analogii. Ale sam wzorzec jest szerszy niż jeden produkt. Claude, Codex, Antigravity i podobne narzędzia różnią się nazwami plików, detalami UX i sposobem włączania niektórych funkcji, ale w praktyce opierają się na tych samych klockach: zawsze aktywne instrukcje, reguły dla wybranych folderów albo typów plików, definicje agentów, zestawy toolsów i pętla walidacji. Jeśli więc używasz innego narzędzia, ten kurs nadal będzie dla Ciebie użyteczny. Zmienią się konkretne ścieżki i nazwy plików. Nie zmieni się logika orkiestracji.

Lekcja 1: Od jednego terminala do skali, która wygląda jak firma

Hook jest prosty: zanim pokażę Ci jak to skonfigurować, chcę żebyś zobaczył stawkę. Ten kurs nie jest o tym, jak napisać jednego sprytnego prompta. To kurs o tym, jak z laptopa zrobić stanowisko pracy, przy którym realnie dowozisz szybciej, spokojniej i z większym rozmachem.

W moim setupie najpierw czuć skalę, a dopiero później poznaje się mechanikę. I to jest ważne: na starcie nie musisz rozumieć całej orkiestracji. Wystarczy, że zobaczysz, że to nie jest tutorial do zabawy, tylko prawdziwy system pracy na wielu projektach.

Na tym etapie nie musisz jeszcze widzieć pełnej kuchni. Wystarczy uchwycić wzorzec: z czasem pojawiają się wyspecjalizowani agenci, osobne skille z własnym SKILL.md, dokładniejsze instrukcje dla wybranych folderów i gotowe slash prompty do powtarzalnych zadań. Taki arsenał nie bierze się znikąd. Zaczyna się od dobrego setupu i dobrego kontekstu.

Gdy chcesz pokazać tę skalę publicznie, ale bez odsłaniania kulis, taki listing wygląda bardziej tak:

design
coder
code-review
deploy
reporter
test-fixer

To też jest moment, w którym zmienia mi się sposób myślenia. Gdy otwieram taką przestrzeń roboczą, nie myślę już “to tylko edytor i czat”. Myślę raczej: to środowisko, w którym różne role mogą działać równolegle, a ja pilnuję kierunku i jakości. Dokładny efekt tej skali pokażę dopiero w rozdziałach 4 i 5. Teraz budujemy pierwszy, najnudniejszy i jednocześnie najważniejszy klocek.

I tu jest kluczowa rzecz na początku kursu: taki ekosystem zaczyna się od jednego pliku. Jednego AGENTS.md albo jednego repo-wide dokumentu instrukcji i jednego agenta. Twój też tak zacznie. I będzie wyglądał zupełnie inaczej niż jakikolwiek pokazany przykład — i to jest właśnie cel tego kursu. Nie kopiujesz cudzego setupu. Budujesz swój własny.

Ćwiczenie

Otwórz swoje obecne repo i odpowiedz sobie na trzy pytania:

1. Jakie 3-5 obszarów projektu agent musiałby znać, żeby nie zgadywać?
2. Gdzie są u Ciebie najważniejsze katalogi?
3. Jakie 2-3 zasady są tak ważne, że agent nie może ich łamać?

Jeśli nie umiesz odpowiedzieć od ręki, to bardzo dobry sygnał, że plik instrukcji repo naprawdę będzie Ci potrzebny.

Podsumowanie

Na razie nie budujemy jeszcze całej firmy z agentów. Ustawiamy biurko, sieć i wprowadzenie. To wystarczy, żeby za chwilę zrobić pierwszy działający dowód.

Słownik — kluczowe pojęcia

Zanim przejdziemy dalej, czas nazwać kilka rzeczy wprost. Ten kurs używa konkretnych pojęć i warto, żebyś od początku rozumiał je operacyjnie, a nie intuicyjnie.

Agent — układ złożony z modelu, pętli działania, celu, narzędzi i kryteriów zakończenia. To definicja robocza na cały kurs. Nie chat, nie makro, nie skrypt. LLM to silnik rozumowania, który interpretuje cel i decyduje co zrobić. Pętla to mechanizm iteracji — agent działa, sprawdza wynik, działa dalej. Cel to precyzyjny opis stanu końcowego: co ma być gotowe. Narzędzia to konkretne operacje, które agent może wykonać: uruchomić komendę bash, przeczytać plik, zapisać wynik, wywołać git, odpytać API. Kryteria zakończenia to warunek, który kończy pracę — bez nich agent działa do odwołania albo zatrzymuje się w złym miejscu. Dokładnie ta różnica oddziela agenta od zwykłego chatu: chat odpowiada raz, agent iteruje do skutku.

Tools — funkcje dostępne dla agenta w trakcie pracy. Bez narzędzi agent to tylko model językowy zamknięty w polu tekstowym. Z narzędziami to worker, który coś realnie robi: commituje, pisze testy, wywołuje CI, deployuje. W tym kursie zobaczysz tools takie jak bash, git, file read/write, API calls.

Więcej pojęć — Fleet, Forge, Łańcuch, Kryteria zakończenia — czeka na Ciebie w rozdziale 2. Tam będziesz ich potrzebować, bo sam je uruchomisz.

Lekcja 2: Instalacja — Warp + GitHub Copilot CLI

Zanim pokażę Ci jak to zainstalować — krótka historia, która wyjaśnia czemu w ogóle wylądowałem w terminalu zamiast w IDE.

Kiedy zaczynałem z Copilotem w VSCode, łatwo wpadałem w dziwny rytm: dawałem agentowi zadanie, patrzyłem jak powoli się kręci, a nudząc się brałem telefon i otwierałem Instagram. Przepalałem czas zamiast pracować równolegle. Naturalny odruch to otworzyć dwie sesje VSCode naraz, potem trzy — ale przy trzech komputer zaczynał się gotować, Copilot się timeoutował albo cały VSCode po prostu padał. Po takim crashu, kiedy traciłem kontekst trzech równoległych rozmów naraz, GitHub Copilot CLI przestał wyglądać jak ciekawostka, a zaczął jak rozwiązanie.

Setup wcale nie musi trwać dwóch dni. W praktyce potrzebujesz dwóch rzeczy: terminala, w którym dobrze Ci się pracuje, i GitHub Copilot CLI. W tym rozdziale pokazuję wszystko na Warp, bo dobrze pokazuje pracę w wielu oknach. Ale ważniejsze jest coś innego: Copilot CLI działa też poza Warp. Terminal ma Ci pomagać, nie blokować wejścia.

Copilot CLI to środowisko wykonawcze dla agentów — daje im dostęp do terminala, plików i gita jako narzędzi. Bez tej warstwy wykonawczej agent pozostaje tylko modelem językowym. Z nią zaczyna realnie pracować.

Dlaczego Warp?

Warp jest wygodny przez łatwe zarządzanie oknami, podpowiadanie komend, wygodę pracy i to, że przy większej liczbie sesji łatwo się między nimi przełączać. Jeśli jednak wolisz iTerm2, Alacritty, Windows Terminal albo zwykły terminal systemowy, to spokojnie możesz przejść cały ten rozdział bez Warp. Najważniejsze jest to, żebyś miał stabilne miejsce do uruchamiania copilot.

Instalacja

Copilot CLI działa na macOS, Windows i Linux. Oficjalna dokumentacja instalacji: https://gh.io/copilot-install

Szybka ścieżka jeśli masz już npm:

npm install -g @github/copilot
copilot --version
copilot

Po copilot dostaniesz ekran startowy CLI. Jeśli pojawi się prośba o logowanie, wpisujesz /login wewnątrz uruchomionej sesji. To tyle — dalej będziemy pisać agentów, nie instalować narzędzie.

Weryfikacja

To nie chodzi o “coś się zainstalowało”. Chcemy pierwszego konkretnego dowodu, że środowisko faktycznie działa.

# 1. Czy CLI jest widoczne?
copilot --version

# 2. Uruchom CLI
copilot

# 3. Jeśli potrzeba — zaloguj się wewnątrz sesji
/login

# 4. Zaakceptuj trusted directory dla bieżącego projektu

# 5. Zadaj dwa pytania testowe:
# Jaki jest stack technologiczny tego projektu?
# Jakie są zasady kardynalne tego projektu?

Jeśli agent odpowiada konkretnie — na podstawie Twojego AGENTS.md albo repo-wide instructions, a nie ogólnikami — setup działa. To jest moment, w którym widzisz że kontekst faktycznie działa. Jeśli nie — patrz sekcja poniżej.

Rozwiązywanie problemów

Jeśli coś nie działa, najczęściej to jedno z tych:

1. Nie jesteś zalogowany — uruchom copilot i wpisz /login wewnątrz sesji.
2. Nie zaakceptowałeś prompta o dostęp do katalogu — agent nie widzi repo. Uruchom ponownie i potwierdź.
3. Nie masz aktywnej subskrypcji GitHub Copilot — CLI wystartuje, ale nie odpowie poprawnie.
4. Wybrałeś ścieżkę npm bez zainstalowanego Node.js — zainstaluj Node.js i spróbuj ponownie.
5. Problem z siecią w WSL2 — uruchom wsl --shutdown i spróbuj jeszcze raz.

Ćwiczenie

Zainstaluj copilot na swoim systemie i doprowadź do momentu, w którym możesz wejść do sesji CLI bez błędów.

Właśnie postawiłeś fundament. Dowód: copilot --version zwraca numer wersji, a sesja copilot startuje bez błędów. Nie każdy developer ma to skonfigurowane poprawnie — teraz Ty masz.

Podsumowanie

Masz już pierwszy klocek: działające narzędzie. Jeszcze nie mądre, jeszcze nie wyspecjalizowane, ale gotowe. Teraz trzeba dać mu wprowadzenie.

Lekcja 3: Twój pierwszy plik instrukcji repo — od generycznego AI do specjalisty od Twojego projektu

Najprostsza analogia jest nadal najlepsza: nowy developer bez wprowadzenia błądzi. AI bez kontekstu robi dokładnie to samo. Dlatego plik instrukcji repo nie jest dodatkiem. To jest dokument, który ustawia rolę, granice i mapę projektu.

Najczęściej najlepiej zacząć od jednego pliku w repo: AGENTS.md. To najbardziej przenośny punkt startu, bo ten format jest zrozumiały nie tylko dla Copilota, ale też dla innych narzędzi agentowych. Jeśli pracujesz głównie w Copilocie, tę samą treść możesz też trzymać w .github/copilot-instructions.md. W praktyce oba pliki pełnią podobną rolę: ustawiają zawsze aktywny kontekst dla repo. Różnica jest głównie w nazewnictwie i w tym, jak bardzo chcesz zostać przy Copilot-native surface’ach.

Gdy projekt rośnie, dokładasz kolejne oficjalne warstwy: .github/instructions/*.instructions.md dla reguł zależnych od ścieżki albo typu plików, .github/agents/*.agent.md dla wyspecjalizowanych agentów, .github/skills/<skill>/SKILL.md dla przenośnych capability folders i .github/prompts/*.prompt.md dla gotowych slash promptów w VS Code. ~/.copilot/ też istnieje, ale jako user-level runtime/config directory: dla agentów, skilli, hooków i konfiguracji, a w VS Code także dla user-level plików .instructions.md. Te dwie warstwy mogą współistnieć. W praktyce często masz wspólny zestaw globalnych agentów i skilli w ~/.copilot/agents oraz ~/.copilot/skills, a .github/agents/ i .github/skills/ wykorzystujesz dopiero wtedy, gdy dany projekt potrzebuje własnych, lokalnych dodatków.

Warto znać też Copilot-native repo-wide surface: .github/copilot-instructions.md. W moich realnych repo właśnie ten plik jest dziś punktem wejścia dla zawsze aktywnych instrukcji, dlatego niżej zobaczysz przykłady dokładnie stamtąd. To nie jest sprzeczność. Studentowi polecam AGENTS.md jako pierwszy ruch, bo jest bardziej przenośny i mniej mylący. W moim działającym monorepo zostawiam .github/copilot-instructions.md, bo tam już cały system jest wokół tego ułożony.

I ważna rzecz: nie potrzebujesz żadnej teatralnej persony. Nie musisz pisać, że agent “jest kimś” w sensie fabularnym. Wystarczy prosty, roboczy opis roli typu: AI asystent pracujący nad tym projektem, piszący po polsku, niełamiący określonych zasad.

W mojej dojrzałej globalnej przestrzeni roboczej taki dokument jest już dużo bogatszy. Poniżej pokazuję przykład sekcji tego typu z realnego .github/copilot-instructions.md.

## Zasady kardynalne

1. **Człowiek decyduje** — Rafał zatwierdza: breaking changes, architektura, pricing, UX. Pytaj zanim zrobisz coś nieodwracalnego.
2. **Nie pushuj bezpośrednio na główny branch produkcyjny** — pracuj na feature branchach i wpuszczaj zmiany przez Pull Request; jeśli repo ma etap pośredni, opisz go jawnie i trzymaj się tej ścieżki
3. **Nie psuj systemu** — Przed i po zmianie uruchom testy. Jeśli coś się sypie — napraw albo wycofaj.
4. **Pytaj gdy nie wiesz** — `ask_user` do krytycznych decyzji.

Gdy później pytasz agenta o zasady projektu, oczekujesz właśnie takiego wyniku: ma zacytować konkretne reguły, a nie wymyślić swoją bezpieczną listę ogólników. Zwróć uwagę na drugą zasadę. Nie chodzi o magiczną formułę jednego idealnego flow, tylko o jasne opisanie bezpiecznej ścieżki zmian dla danego repo.

I tu ważne doprecyzowanie: to jest reguła do dostosowania pod Twoje środowisko, nie uniwersalny przepis dla każdego repo. Sens ogólny jest prostszy: nie pushuj bezpośrednio na główny branch produkcyjny. Jeśli w Twoim projekcie istnieje dodatkowy etap pośredni, taki jak staging, preprod albo osobny branch integracyjny, opisz go jawnie. Jeśli nie masz takiej warstwy, sama zasada “nie pushuj bezpośrednio na główny branch” w zupełności wystarcza na start.

Drugi ważny element to mapa kodu. Tu świetnie widać różnicę między “AI coś zgaduje” a “AI wie gdzie patrzeć”. Poniżej fragment z prawdziwego pliku /home/raff/projects/awesomeworks/callwise/.github/copilot-instructions.md.

## Odkrywanie codebase

| Szukasz...                     | Sprawdź                                                         |
| ------------------------------ | --------------------------------------------------------------- |
| Wszystkie modele DB (58 tabel) | `backend/models.py`                                             |
| Routery / endpointy            | `backend/app/main.py` + `backend/app/routes.py` + `*_routes.py` |
| Celery taski                   | `backend/tasks/`                                                |
| Auth / JWT validation          | `backend/auth.py`                                               |
| Frontend hooks (per domain)    | `frontend/src/hooks/`                                           |
| Design system                  | `docs/design-system.md`                                         |

Po zadaniu pytania o architekturę albo endpointy agent ma dzięki temu bardzo konkretny punkt startu. Zamiast błądzić po repo, od razu idzie do właściwych plików. I o to chodzi.

Na start nie musisz jednak pisać 200 linii. W kursie masz gotowy template w pliku templates/agents-template.md.

# [Nazwa projektu] — AGENTS

## Rola agenta
[Krótko: kim agent jest w tym repo i jakiego języka ma używać]

## Zasady kardynalne
1. **Człowiek decyduje** — krytyczne decyzje (breaking changes, architektura, pricing) zawsze zatwierdza człowiek
2. **Nie pushuj bezpośrednio na główny branch** — pracuj na feature branchach, a zmiany wpuszczaj przez Pull Request; jeśli masz środowisko pośrednie typu `staging` lub `preprod`, kieruj PR-y najpierw tam
3. **Nie psuj systemu** — przed zmianą sprawdź testy, po zmianie uruchom testy
4. **Pytaj gdy nie wiesz** — lepiej zapytać niż zgadywać

## Mapa repo

## Stack technologiczny

## Testowanie i walidacja

## Format odpowiedzi

Po zapisaniu takiego pliku agent dostaje pierwsze sensowne wprowadzenie. I jeszcze jedna praktyczna uwaga: template jest celowo prostszy niż dojrzała przestrzeń robocza. To dobrze. W rozdziale 1 masz mieć działający fundament, nie encyklopedię wszystkiego. Minimum na start to 5 sekcji: rola, zasady kardynalne, mapa repo, stack technologiczny i walidacja.

Jeśli pracujesz wyłącznie w Copilocie i wolisz Copilot-native layout, możesz skopiować tę samą treść do .github/copilot-instructions.md. Logika dokumentu pozostaje ta sama.

Jeśli później będziesz pracować na kilku repozytoriach, możesz dołożyć globalny runtime z agentami i skillami w ~/.copilot/, a repo-level instrukcje zostawić na kontekst konkretnego projektu. Ale teraz trzymajmy się prostego fundamentu: jedno repo, jeden dobry dokument, zero chaosu.

Ćwiczenie

Stwórz u siebie plik AGENTS.md i wypełnij minimum 5 sekcji:

┌─────────────────────────────────────────────────┐
│   AGENTS.md — minimalna struktura               │
├─────────────────────────────────────────────────┤
│  1. Rola agenta            (kim jest agent)     │
│  2. Zasady kardynalne      (co wolno/nie wolno) │
│  3. Mapa repo              (gdzie co leży)      │
│  4. Stack technologiczny   (czego używamy)      │
│  5. Walidacja              (jak sprawdzać wynik)│
└─────────────────────────────────────────────────┘

Jeśli chcesz zacząć szybciej, poniżej masz generyczny starter do skopiowania i dopasowania:

# AGENTS.md

## Rola agenta

Jesteś AI asystentem pracującym w tym repozytorium.
Najpierw czytaj kod i kontekst projektu, potem proponuj albo wykonuj zmiany.
Nie zgaduj architektury ani intencji, jeśli można je ustalić z plików.
Odpowiadaj zwięźle i pokazuj operatorowi tylko to, co pomaga podjąć następną decyzję.

## Zasady kardynalne

1. Najpierw zrozum istniejący kod, potem edytuj.
2. Nie wprowadzaj breaking changes bez wyraźnego sygnału.
3. Po zmianach uruchom najwęższą sensowną walidację.
4. Nie ruszaj niepowiązanych plików tylko po to, żeby "posprzątać".
5. Jeśli decyzja wpływa na architekturę, koszt, bezpieczeństwo albo deploy, zatrzymaj się i poproś o decyzję człowieka.

## Mapa repo

- Entry point backendu: [gdzie aplikacja startuje]
- Logika domenowa: [gdzie są serwisy / use case'y]
- UI / frontend: [gdzie są ekrany i komponenty]
- Testy: [gdzie są testy i smoke checks]
- Dokumentacja: [gdzie są docs, ADR-y, PRD, design docs]

## Stack technologiczny

- Backend: [język, framework, ORM]
- Frontend: [framework, język, styling]
- Baza danych: [silnik]
- Infra / CI: [deploy, pipeline, hosting]

## Jak pracować w tym repo

- Szukaj najpierw najbliższego miejsca, które naprawdę kontroluje zachowanie.
- Preferuj małe, lokalne zmiany zamiast szerokich refaktorów.
- Jeśli istnieje sąsiedni test dla zmienianej logiki, użyj go jako pierwszej walidacji.
- Jeśli repo ma istniejący wzorzec, dopasuj się do niego zamiast wprowadzać nowy styl bez potrzeby.

## Testowanie i walidacja

- Backend: [komenda testowa]
- Frontend: [komenda testowa]
- Lint / typecheck: [komenda]
- Smoke / manual check: [co sprawdzić po zmianie]

## Format odpowiedzi

- Napisz krótko co zostało zmienione.
- Powiedz jak to sprawdzić.
- Jeśli jest ryzyko albo brak walidacji, nazwij to wprost.
- Jeśli kolejny krok jest oczywisty, zaproponuj go zamiast zostawiać użytkownika z pustym „done”.

Jeśli chcesz, tę samą treść możesz później zmirrorować do .github/copilot-instructions.md, ale na start nie potrzebujesz dwóch plików naraz.

Cel minimum: 40+ linii realnego kontekstu o Twoim projekcie.

Właśnie zamieniłeś generycznego chatbota w specjalistę od Twojego projektu. Dowód: plik AGENTS.md ma co najmniej 40 linii — konkretna architektura, stack i zasady, których agent nigdy sam by nie odgadł.

Podsumowanie

Na tym etapie agent nie musi być jeszcze genialny. Ma po prostu przestać zgadywać. Dobry plik instrukcji repo robi dokładnie to.

Lekcja 4: Pierwszy test — sprawdzamy, czy agent naprawdę czyta Twój kontekst

To jest mój ulubiony moment w rozdziale 1, bo tu kończy się teoria. Masz terminal. Masz copilot. Masz swój plik instrukcji. Teraz potrzebujesz pierwszego dowodu, że to się naprawdę spina.

Najprostszy test wygląda tak:

copilot

Jeśli przy pierwszym wejściu sesja poprosi o autoryzację, wpisujesz w środku:

/login

A potem zadajesz dwa pytania:

Jaki jest stack technologiczny tego projektu?
Jakie są zasady kardynalne tego projektu?

Dobry wynik wygląda bardzo konkretnie. Agent powinien:

• odnieść się do technologii, które naprawdę masz wpisane w pliku,
• cytować albo parafrazować zasady z AGENTS.md albo repo-wide instructions,
• używać języka i tonu zgodnego z instrukcjami,
• wskazywać prawdziwe katalogi lub pliki, jeśli pytanie tego wymaga.

Zły wynik też rozpoznasz od razu. Jeśli agent pyta Cię, jakiego frameworka używasz, zgaduje biblioteki albo odpowiada jak generyczny chatbot z internetu, to znaczy, że kontekst nie zaskoczył.

W moim setupie taki test szybko pokazuje jakość. Gdy pytam o projekt z dobrze przygotowaną mapą kodu, agent wraca do mnie z rzeczami w stylu: backend/models.py, backend/app/main.py, backend/auth.py, frontend/src/hooks/. Nie dlatego, że ma magiczną intuicję, tylko dlatego, że dostał dobre wprowadzenie i umie je połączyć z prawdziwymi plikami.

Jeśli chcesz zrobić trzeci test, zadaj pytanie: “Opisz strukturę katalogów i powiedz co gdzie znajdę”. To zwykle świetnie obnaża różnicę między projektem z kontekstem a projektem bez kontekstu.

Ćwiczenie

Zadaj agentowi 3 pytania o Twój projekt:

1. Jaki jest stack technologiczny tego projektu?
2. Jakie są zasady kardynalne tego projektu?
3. Opisz strukturę katalogów i powiedz co gdzie znajdę.

Kryterium sukcesu jest proste: odpowiedzi mają bazować na Twoim pliku i Twoim repo, nie na improwizacji.

Właśnie zobaczyłeś różnicę między AI, które zgaduje, a AI, które wie. Dowód: odpowiedzi agenta cytują Twój stack i Twoje zasady — nie generyczne przykłady z internetu.

Podsumowanie

Masz już pierwszy dowód. Nie obietnicę, nie marketing, tylko realne zachowanie agenta, który czyta Twój kontekst i odpowiada na bazie projektu.

Lekcja 5: Struktura przestrzeni roboczej i co dalej

Działający agent w jednym repo to świetny start. Ale warto jeszcze zobaczyć, jak wygląda przestrzeń robocza, kiedy z czasem robi się z niej większy system pracy. Nie po to, żeby Cię przytłoczyć. Po to, żebyś wiedział, że ten rozdział jest początkiem czegoś większego.

Poniżej fragment z prawdziwego pliku /home/raff/projects/awesomeworks/.github/copilot-instructions.md, sekcja Monorepo.

## Monorepo

| Projekt | Ścieżka | Opis | Instrukcje |
|---------|---------|------|------------|
| **CallWise** | `callwise/` | AI Call Scoring SaaS — **core product, produkcja** | `callwise/.github/copilot-instructions.md` |
| Background | `background/` | Background worker tasks (Celery) | `background/.github/copilot-instructions.md` |
| CallWise Mobile | `callwise-mobile/` | Aplikacja mobilna | `callwise-mobile/.github/copilot-instructions.md` |
| CourseAI | `courseai/` | Kurs AI coding | `courseai/.github/copilot-instructions.md` |
| Ask | `ask/` | Ask AI — chatbot produkt | `ask/.github/copilot-instructions.md` |
| Prompts | `prompts/` | Agenty i skille (**osobne repo git**) | ten plik |
| Docs | `docs/` | Dokumentacja cross-project | — |
| Scripts | `scripts/` | Skrypty DevOps/utility | — |

A jeśli chcesz to zapamiętać jako prosty template zgodny z oficjalnymi docsami i jednocześnie bliski realnemu setupowi pracy na wielu repo, rysuję to tak:

<workspace-root>/
├── shared-runtime/
│   ├── agents/
│   │   ├── planner.agent.md
│   │   └── reviewer.agent.md
│   ├── skills/
│   │   ├── debugging/
│   │   │   └── SKILL.md
│   │   └── refactoring/
│   │       └── SKILL.md
│   └── workspace-defaults.instructions.md
├── project-1/
│   ├── AGENTS.md
│   └── src/
├── project-2/
│   ├── AGENTS.md
│   └── app/
└── worktrees/
    └── project-1-feature-1/
        ├── AGENTS.md
        └── src/

Na tym etapie worktrees/ pokazuję tylko jako sygnał skali. Do praktycznego użycia wrócimy dopiero w rozdziale 12, gdzie pokażę Ci, jak wykorzystać git worktrees do pracy na wielu terminalach na tym samym repozytorium bez wchodzenia sobie i agentom w drogę.

Tu ważny detal nazewnictwa:

• AGENTS.md to przenośna warstwa repo-wide instructions i dobry domyślny start,
• .github/copilot-instructions.md to Copilot-native warstwa repo-wide instructions,
• *.instructions.md to węższe reguły dla konkretnej ścieżki albo typu pliku,
• agent to pojedynczy plik .agent.md,
• skill to osobny katalog z SKILL.md i opcjonalnymi skryptami albo przykładami,
• prompt file to plik .prompt.md, czyli gotowy slash prompt w VS Code.

A teraz osobno bazowa warstwa user-level:

~/.copilot/
├── agents/
│   ├── planner.agent.md
│   └── reviewer.agent.md
├── skills/
│   └── debugging/
│       └── SKILL.md
├── instructions/
│   └── workspace-defaults.instructions.md
├── config.json
├── mcp-config.json
└── hooks/

To jest najprostszy układ, jaki użytkownik może ustawić ręcznie bez dodatkowej warstwy publikacji, symlinków i wersjonowania runtime.

Jeśli pracujesz w VS Code, masz jeszcze jedną opcję: nie musisz opierać się wyłącznie na domyślnym ~/.copilot/. Dokumentacja VS Code pozwala dołączać własne lokalizacje customizacji przez settings.json. Dla instrukcji służy do tego chat.instructionsFilesLocations, a dla pozostałych warstw istnieją analogiczne ustawienia: chat.agentFilesLocations, chat.agentSkillsLocations i chat.promptFilesLocations. W praktyce oznacza to, że możesz podłączyć własny katalog z instrukcjami, agentami, skillami albo promptami bez ręcznego rozkładania wszystkiego dokładnie w domyślnych ścieżkach user-level.

To rozróżnienie jest ważne. Repo projektu jest source of truth dla kontekstu projektu. ~/.copilot/ jest user-level runtime/config directory. W bardziej rozbudowanym setupie możesz trzymać wspólne agenty i skille w osobnym katalogu albo osobnym repo, wersjonować je normalnie w gicie, a potem synchronizować do ~/.copilot/agents i ~/.copilot/skills, żeby działały w każdej sesji i w każdym repo. Nie musisz jednak opisywać ani budować takiej mechaniki w rozdziale 1. Tu ważne jest tylko samo rozróżnienie warstw. W praktyce oznacza to tyle:

• projektowe reguły trzymaj przede wszystkim w AGENTS.md albo .github/copilot-instructions.md,
• bardziej precyzyjne zasady rozkładaj do .github/instructions/*.instructions.md,
• wspólne, wielorepo agenty i skille możesz trzymać poza repo projektu i synchronizować później do ~/.copilot/agents oraz ~/.copilot/skills,
• .github/agents/*.agent.md i .github/skills/<skill>/ wykorzystuj wtedy, gdy projekt potrzebuje lokalnych dodatków specyficznych tylko dla tego repo,
• powtarzalne slash taski w VS Code zapisuj jako .github/prompts/*.prompt.md,
• ~/.copilot/agents i ~/.copilot/skills są user-level runtime dla rzeczy współdzielonych między projektami,
• a w VS Code user-level .instructions.md mogą leżeć w ~/.copilot/instructions/.

Po takim fragmencie agent od razu rozumie, że nie pracuje w pojedynczym folderze wrzuconym na szybko do gita, tylko w szerszym środowisku, gdzie różne katalogi mają różną rolę i różny poziom własnych instrukcji. To jest dokładnie ten moment, w którym setup zaczyna wyglądać bardziej jak infrastruktura firmy niż jak prywatny notatnik developera.

I tu jest bardzo świadoma granica. Na tym etapie chodzi tylko o zasugerowanie skali:

• z jednego terminala możesz dojść do 7,
• część pracy może dziać się poza Twoim lokalnym ekranem,
• niektóre wyniki mogą wpadać wtedy, gdy Ty akurat robisz coś innego albo po prostu śpisz.

Ale nie będziemy jeszcze rozpisywać dokładnych przepływów, tabel dobierania agentów, backgroundowych mechanik ani tego, kto z kim rozmawia pod spodem. To jest efekt późniejszych rozdziałów. Tutaj chodzi o to, żebyś wyszedł z rozdziału 1 z poczuciem: “okej, widzę skalę, ale umiesz już zrobić pierwszy działający krok”.

Ćwiczenie

Narysuj sobie prostą mapę swojej przestrzeni roboczej albo repo:

• główny katalog,
• 3-7 najważniejszych podkatalogów,
• miejsce na AGENTS.md,
• jedno zdanie o tym, do czego służy każdy ważny obszar.

To będzie bardzo dobry materiał do dalszych rozdziałów.

Właśnie stworzyłeś mapę, której agent będzie szukał przez cały ten kurs. Dowód: masz narysowaną strukturę workspace z co najmniej 3 podkatalogami i miejscem na instrukcje — fundament pod kolejne warstwy.

Podsumowanie

Masz już nie tylko setup, ale też kierunek. Wiesz, jak wygląda mały, działający fundament i czujesz, że dalej skala rośnie. To dokładnie ten efekt, o który chodziło w chapter 1.

Ćwiczenie rozdziału

Zadanie: Stwórz swoje środowisko AI kodowania od zera i potwierdź, że działa na prawdziwym projekcie.

Deliverable:

• działający terminal z copilot,
• plik AGENTS.md w repo,
• trzy odpowiedzi agenta, które bazują na realnym kontekście Twojego projektu.

Kroki:

┌─────────────────────────────────────────────────────────────┐
│   Copilot CLI Setup — 6 kroków                              │
├───┬─────────────────────────────────────────────────────────┤
│ 1 │ Terminal    → Warp lub ulubiony terminal                │
│ 2 │ Copilot CLI → zainstaluj GitHub Copilot CLI            │
│ 3 │ Repo        → otwórz repozytorium projektu             │
│ 4 │ Files       → stwórz AGENTS.md                         │
│ 5 │ Fill        → wypełnij minimum 5 sekcji                │
│ 6 │ Test        → uruchom copilot + zadaj 3 pytania        │
└───┴─────────────────────────────────────────────────────────┘

Kryteria sukcesu:

1. copilot --version zwraca wersję.
2. Plik AGENTS.md ma co najmniej 40 linii sensownej treści.
3. Agent potrafi podać Twój stack bez zgadywania.
4. Agent potrafi przytoczyć zasady kardynalne z Twojego pliku.
5. Agent umie wskazać konkretne katalogi albo pliki w odpowiedzi na pytanie o strukturę projektu.

Weryfikacja:

# 1. Setup działa?
copilot --version

# 2. Uruchom CLI
copilot

# 3. Jeśli trzeba, zaloguj się w środku
/login

# 4. Sprawdź długość pliku (Bash / WSL)
cat AGENTS.md | wc -l

# 5. Zadaj pytania testowe
# Jaki jest stack technologiczny tego projektu?
# Jakie są zasady kardynalne tego projektu?
# Opisz strukturę katalogów i powiedz co gdzie znajdę.

Po tej sekwencji powinieneś zobaczyć numer wersji, uruchomioną sesję CLI i odpowiedzi odnoszące się do Twojego pliku, a nie do domysłów.

# PowerShell: policz linie pliku
(Get-Content AGENTS.md).Count

W PowerShellu oczekiwany wynik to liczba co najmniej 40.

Masz działające środowisko i agenta, który czyta Twój kontekst zamiast zgadywać. Pierwszy krok zrobiony — i to nie jest mały krok. Ale AGENTS.md to tylko onboarding. Agent wciąż czeka na prawdziwe zlecenie. W następnym rozdziale stworzysz swojego pierwszego agenta od zera: od pustego pliku .agent.md do działającego workera, który czyta Twój kod, analizuje go i zwraca coś, co realnie się przydaje — w 30 minut.

Podsumowanie

W tym rozdziale zrobiłeś dokładnie to, co trzeba było zrobić na początku: postawiłeś fundament. Masz działające środowisko, pierwszy AGENTS.md, pierwszy test i pierwszy dowód, że agent potrafi czytać Twój projekt zamiast improwizować.