Ten artykuł jest inny niż poprzednie. Nie tłumaczymy tu podstaw ani nie opisujemy architektury – zakładam że przeszedłeś całą serię i rozumiesz jak Copilot CLI działa. Zamiast tego: konkretne przepisy na sytuacje które pojawiają się w codziennej pracy.

Format jest celowo skondensowany – każdy przepis to problem, rozwiązanie i gotowy do uruchomienia kod. Artykuł jest przeznaczony zarówno jako personal cheatsheet jak i materiał do knowledge sharingu w zespole.

01 Przerywasz pracę w połowie – wrócisz jutro

Pracujesz od 2 godzin, masz otwarte 3 pliki w kontekście, połowę planu zrealizowaną i listę rzeczy do zrobienia. Nie chcesz jutro zaczynać od nowa.

copilot

# Zanim wyjdziesz – nadaj sesji sensowną nazwę i zostaw notatkę
> /rename refactor-taskservice-errorhandling

# Opcjonalnie: poproś o podsumowanie stanu
> Podsumuj w punktach: co zrobiliśmy, co zostało, na czym skończyliśmy.
  Będę wracał do tej sesji jutro.

> /exit

# Następnego dnia – wróć dokładnie tam gdzie byłeś
copilot --continue

# Copilot widzi całą historię rozmowy i kontekst plików
> Gdzie skończyliśmy? Co zostało do zrobienia?

# Szybki powrót do ostatniego zadania
copilot --continue

# Mam kilka wątków, chcę wybrać
copilot --resume
# → pokazuje listę: refactor-taskservice, fix-search-bug, feat-export-csv...

02 Wiele równoległych zadań – jak nie mieszać kontekstów

Masz jednocześnie: bugfix na hotfix branchu, nową funkcję na feature branchu i code review PR kolegi. Każde zadanie powinno mieć własną sesję.

# Terminal 1: bugfix
copilot
> /rename hotfix-null-reference-taskservice
# praca nad bugiem...
> /exit

# Terminal 2: nowa funkcja
copilot
> /rename feat-search-by-tag
# praca nad featurem...
> /exit

# Terminal 3: review PR
copilot
> /rename review-pr-42-adam
> /review
# przeglądanie zmian...
> /exit

# Następny dzień: wróć do konkretnego wątku
copilot --resume
# wybierz "feat-search-by-tag" z listy

03 Eksport sesji do Markdown – dokumentacja przy okazji

Skończyłeś złożony refactoring. Cała decyzja architektoniczna jest w historii sesji. Zamiast pisać ją od nowa do Confluence – wyeksportuj.

copilot

# Pod koniec sesji
> /share file ./docs/adr-taskservice-refactoring-$(date +%Y%m%d).md

# Albo jako GitHub Gist jeśli chcesz podzielić się z zespołem
> /share gist

# Możesz też poprosić Copilota o podsumowanie przed eksportem
> Napisz podsumowanie tej sesji jako ADR (Architecture Decision Record):
  - Kontekst (dlaczego się tym zajęliśmy)
  - Rozważane opcje
  - Podjęta decyzja
  - Konsekwencje

> /share file ./docs/adr-$(date +%Y%m%d).md

04 Sesja się zapełnia – ratuj bez utraty wątku

Pracujesz od godziny, kontekst jest na 85%, Copilot zaczyna "zapominać" wcześniejsze ustalenia.

copilot

# Sprawdź stan
> /context
# Context usage: 112,000 / 128,000 tokens (87%)

# Opcja A: kompresja – zachowuje ustalenia, zwalnia tokeny
> /compact
# Copilot podsumowuje historię, zwalnia ~40% kontekstu

# Opcja B: jeśli temat się zmienił – wyczyść i zacznij świeżo
> /clear

# Po /compact możesz sprawdzić co zostało zapamiętane
> Co pamiętasz z naszych ustaleń dotyczących refactoringu TaskService?

05 Stopniowe ładowanie kontekstu dla dużego projektu

Projekt ma 30+ plików. Wrzucenie wszystkiego przez @folder/ zje połowę context window na starcie.

copilot

# Krok 1: zacznij od struktury (tani token-wise)
> @TaskList/ Pokaż mi strukturę projektu – tylko nazwy plików i krótki opis każdego.
  Nie czytaj zawartości.

# Krok 2: na podstawie odpowiedzi zdecyduj co ładować
> @TaskService.cs @ITaskRepository.cs Pokaż mi jak TaskService zależy od repozytorium.

# Krok 3: doładowuj tylko to co potrzebne
> @TaskServiceTests.cs Jak są teraz przetestowane metody Add i Remove?

# Zamiast: @TaskList/ Przeanalizuj cały projekt (kosztowne!)

06 Analiza pliku którego nie możesz pokazać wprost

Plik zawiera dane wrażliwe (klucze API, dane klientów) ale chcesz przeanalizować jego strukturę.

copilot

# Pokaż schemat zamiast zawartości
> Mam plik appsettings.json z sekretami. Oto jego struktura (wartości zastąpione):
{
  "ConnectionStrings": { "Default": "***" },
  "JwtSettings": { "Secret": "***", "ExpiryMinutes": 60 },
  "ExternalApi": { "Key": "***", "BaseUrl": "https://api.example.com" }
}

Czy ta struktura konfiguracji jest zgodna z best practices .NET?
Jak powinienem zarządzać sekretami w środowisku produkcyjnym?

07 Iteracyjne budowanie – nie proś o wszystko naraz

Jeden z najczęstszych błędów: próba wygenerowania całego serwisu jednym promptem. Iteruj.

copilot

# Złe (zbyt szeroki prompt → generyczne odpowiedzi)
> Napisz kompletny TaskRepository z EF Core, interfejsem, testami i migracją

# Dobre (iteracyjne, każdy krok weryfikowalny)
> @TaskItem.cs Zaprojektuj interfejs ITaskRepository. Tylko interfejs, bez implementacji.

# Oceniasz → akceptujesz lub modyfikujesz
> Wygląda dobrze. Teraz zaimplementuj TaskRepository używając EF Core DbContext.
  Użyj async/await wszędzie i pamiętaj o CancellationToken.

# Weryfikujesz → kolejny krok
> Wygeneruj testy jednostkowe dla TaskRepository używając Moq do mockowania DbContext.

> Teraz dodaj XML documentation do wszystkich publicznych metod interfejsu.

08 Porównanie podejść – poproś o opcje zanim zacommitujesz

Nie wiesz czy lepiej użyć Result<T>, wyjątków czy nullable. Zamiast google'ować – zapytaj o porównanie w kontekście Twojego kodu.

copilot

> @TaskService.cs Muszę zdecydować jak obsługiwać błąd "zadanie nie istnieje"
  w metodzie MarkDone. Pokaż mi trzy podejścia:
  1. Rzucanie wyjątku (ArgumentOutOfRangeException)
  2. Zwracanie bool
  3. Zwracanie Result (pattern funkcyjny)

  Dla każdego: przykład implementacji, kiedy stosować, co ułatwia a co utrudnia.
  Na końcu zasugeruj które pasuje najlepiej do stylu reszty tego projektu.

09 Debug przez eliminację – kiedy nie wiesz gdzie jest błąd

Test failuje, stack trace jest ogólny, nie wiesz czy problem jest w klasie, w danych testowych czy w konfiguracji mockowania.

copilot

> Mam failujący test:
[test output / stack trace]

@TaskServiceTests.cs @TaskService.cs

Proszę NIE proponować fixa od razu. Najpierw:
1. Wskaż wszystkie możliwe przyczyny tego błędu
2. Dla każdej: jak ją zweryfikować (co sprawdzić lub dodać)
3. Dopiero po mojej odpowiedzi zaproponuj fix

# To zmusza Copilota do analizy zamiast strzelania od razu rozwiązaniem

10 Refactoring z zachowaniem zachowania – kontrakt testowy

Chcesz przepisać metodę ale boisz się że zmienisz jej zachowanie. Klasyczny problem przy braku testów.

copilot

> @TaskService.cs Chcę zrefaktoryzować metodę Search() ale muszę mieć pewność
  że nie zmienię jej zachowania.

  Krok 1: Wygeneruj charakteryzacyjne testy (characterization tests) które
  dokumentują OBECNE zachowanie tej metody – w tym wszelkie bugi czy dziwne edge cases.
  Nie naprawiaj niczego – chcę przetestować to co JEST, nie to co POWINNO BYĆ.

  Krok 2 (po moim potwierdzeniu): Dopiero wtedy zaproponuj refactoring.

11 Code review PR kolegi – z kontekstem całego projektu

Dostajesz link do PR. Tradycyjnie: przeglądasz diff w przeglądarce, nie widząc szerszego kontekstu. Z Copilot CLI + MCP:

copilot

# GitHub MCP odczytuje PR bez copy-paste
> Pobierz szczegóły PR #18 i pokaż mi diff

# Teraz przeanalizuj w kontekście projektu
> @TaskService.cs @ITaskRepository.cs Czy zmiany w PR #18 są spójne
  z istniejącą architekturą? Czy interfejs ITaskRepository jest respektowany?

# Sprawdź testy
> Czy PR #18 zawiera testy? Jakie edge cases nie są pokryte?

# Wygeneruj komentarze do PR
> Na podstawie powyższej analizy wygeneruj konstruktywne komentarze review
  w formacie: plik:linia – obserwacja – sugestia

12 Knowledge sharing – wytłumacz nieznanemu developerowi

Onboarding nowego kolegi. Zamiast godzinnego call'a "pokaż mi kod" – przygotuj materiał za pomocą Copilota.

copilot

> @TaskList/ Przygotuj "tour po projekcie" dla nowego developera .NET który
  właśnie dołączył do teamu. Uwzględnij:
  - Co robi aplikacja (1 akapit)
  - Struktura katalogów i co gdzie leży
  - Jak uruchomić lokalnie (komendy dotnet)
  - Jak uruchomić testy
  - Trzy najważniejsze klasy i ich odpowiedzialności
  - Gdzie zacząć jeśli chcę dodać nową komendę CLI

> /share file ./docs/onboarding-guide.md

13 Sprint retrospektywa – analiza commitów tygodnia

Piątek, koniec sprintu. Zamiast przekopywać historię gita ręcznie – Copilot wyciąga podsumowanie.

copilot

# GitHub MCP sięga po historię
> Wylistuj wszystkie commity z tego tygodnia (od poniedziałku) w tym repozytorium.
  Zgrupuj według typu (feat, fix, refactor, test) i autora.

> Na podstawie tej historii commitów: jakie były główne obszary pracy w tym tygodniu?
  Czy widać jakieś wzorce – np. dużo bugfixów w konkretnym module?

> Wygeneruj draft opisu dokonanej pracy na potrzeby raportu statusu projektu.
  Styl: rzeczowy, dla niedewelopera, max 5 zdań.

14 Automatyczny changelog z historii PR

# PowerShell – generuj CHANGELOG z ostatnich zmergowanych PR
$since = "2024-01-01"

copilot -p "Na podstawie poniższej historii gitowej przygotuj wpis do CHANGELOG.md
w formacie Keep a Changelog (keepachangelog.com):

$(git log --oneline --since=$since --merges)

Pogrupuj zmiany w kategorie: Added, Changed, Fixed, Removed.
Dla każdej zmiany napisz jedno zdanie zrozumiałe dla użytkownika końcowego,
nie dla developera."

15 Batch review wszystkich plików w module

# PowerShell – przejrzyj wszystkie pliki .cs w katalogu
Get-ChildItem -Path ".\TaskList" -Filter "*.cs" -Recurse | ForEach-Object {
    $relativePath = $_.FullName.Replace((Get-Location).Path + "\", "")
    Write-Host "Sprawdzam: $relativePath"

    $review = copilot --allow-all -p `
        "Security review @$relativePath – TYLKO krytyczne problemy:
         SQL injection, path traversal, hardcoded credentials.
         Odpowiedź: PASS lub lista problemów z numerami linii."

    if ($review -match "FAIL|injection|traversal|hardcoded") {
        Write-Warning "Potencjalny problem w: $relativePath"
        Write-Host $review
    }
}

16 Automatyczne testy dla wszystkich nowych plików

#!/bin/bash
# Dla każdego nowego pliku .cs – sprawdź czy ma odpowiadający plik testowy

NEW_FILES=$(git diff --cached --name-only --diff-filter=A | grep '\.cs$' | grep -v Tests)

for file in $NEW_FILES; do
    test_file="${file%.cs}Tests.cs"
    if [ ! -f "$test_file" ]; then
        echo "Brak pliku testowego dla: $file"
        echo "Generuję szkielet testów..."
        copilot --allow-all -p \
            "Wygeneruj szkielet testów xUnit dla @$file.
             Tylko szkielet z [Fact] dla każdej publicznej metody,
             bez implementacji testów. Zapisz jako $test_file" \
            > "$test_file"
        git add "$test_file"
    fi
done

17 Daily standup w 30 sekund

# Co robiłem wczoraj / co robię dziś – z historii gita i issues
copilot -p "Na podstawie poniższej historii gita i otwartych issues przygotuj
3-punktowy daily standup (co zrobiłem, co planuję, czy mam blokery):

Moje commity z wczoraj:
$(git log --oneline --author='$(git config user.name)' --since='1 day ago')

Moje otwarte issues/PR:
[wklej listę z GitHub lub pomiń jeśli nie masz MCP]

Styl: zwięzły, 1-2 zdania na punkt. Po polsku."

18 Analiza technicznego długu przed sprintem

copilot

> @TaskList/ Przeprowadź analizę technicznego długu w tym projekcie.
  Szukaj:
  - TODO i FIXME z datą lub bez
  - Metod dłuższych niż 30 linii
  - Klas bez testów jednostkowych
  - Przestarzałych pakietów NuGet (sprawdź .csproj)
  - Duplikacji kodu (podobnych bloków w różnych plikach)

  Wynik: lista posortowana według priorytetu z szacowanym czasem naprawy
  (S=<2h, M=2-8h, L=>8h). Format gotowy do wklejenia jako task backlogowy.

19 Agent jako "drugi pair programmer" przy trudnym problemie

Utknąłeś na problemie od godziny. Zamiast wołać kolegę – porozmawiaj z wyspecjalizowanym agentem jak z senior devem.

copilot

> /agent
# Wybierz "dotnet-reviewer"

# Opisz problem dokładnie – jak byś opisał seniorowi
> Mam problem z deadlockiem w aplikacji ASP.NET Core.
  @TaskController.cs @TaskService.cs

  Symptom: request do GET /tasks czasem się wiesza na 30 sekund,
  potem timeout. Nie reprodukuje się lokalnie, tylko na stagingu
  przy równoległych requestach.

  Co już sprawdziłem: nie ma .Result ani .Wait() które widzę gołym okiem.
  Connection pool wykluczone – problem jest też przy in-memory DB w testach.

  Przeprowadź mnie przez debugging krok po kroku. Pytaj jeśli potrzebujesz
  więcej informacji przed zaproponowaniem rozwiązania.

20 Skill jako "living documentation" standardów teamu

Masz standardy kodowania w Confluence które nikt nie czyta. Przenieś je do Skills – Copilot będzie je stosował automatycznie.

---
name: team-standards
description: Apply company coding standards for .NET projects. Use for all
  code generation, code reviews, refactoring and any C# code tasks.
---

# Standardy Kodowania – Nazwa Firmy

## Wymagane przy każdym kodzie
- XML documentation na wszystkich publicznych API
- Nullable reference types włączone i respektowane
- Async suffix dla metod zwracających Task (GetTaskAsync, not GetTask)
- Unit testy dla każdej nowej klasy biznesowej

## Nazewnictwo
- Repozytoria: ITaskRepository, TaskRepository
- Serwisy: ITaskService, TaskService
- DTOs: TaskDto, CreateTaskRequest, UpdateTaskResponse
- Wyjątki: TaskNotFoundException, InvalidTaskStateException

## Zakazane wzorce
- Brak .Result lub .Wait() na Task
- Brak pustych catch bloków
- Brak static mutable state
- Brak bezpośredniego new() na zależnościach (użyj DI)

## Nasze biblioteki (używaj zamiast własnych implementacji)
- Logowanie: Serilog z structured logging
- Walidacja: FluentValidation
- Mapowanie: Mapster (nie AutoMapper)
- Testy: xUnit + FluentAssertions + Moq

21 Kontrakt na output – precyzuj format odpowiedzi

Domyślnie Copilot odpowiada jak chce. Możesz precyzować format żeby dostać wyjście gotowe do użycia.

copilot

# Zamiast: wygeneruj testy
# Powiedz dokładnie czego chcesz:

> @TaskService.cs Wygeneruj testy dla metody Add().
  Format odpowiedzi:
  - Tylko kod C#, bez wyjaśnień tekstowych
  - Jeden plik TestClass z namespace TaskList.Tests
  - Używaj [Fact] i [Theory] z xUnit
  - Asercje tylko przez FluentAssertions
  - Nazewnictwo: MethodName_Scenario_ExpectedResult
  Nie pisz nic przed ani po kodzie.

22 Pytaj o uzasadnienie, nie tylko o fix

Gdy Copilot proponuje zmianę którą masz zacommitować i reviewować z kolegami – chcesz rozumieć dlaczego, nie tylko co.

copilot

> @TaskService.cs Zaproponuj refactoring metody LoadTasks().

# Po otrzymaniu propozycji:
> Zanim zaakceptuję – wyjaśnij:
  1. Dlaczego ta wersja jest lepsza od obecnej?
  2. Jakie są trade-offy tej decyzji?
  3. Czy są przypadki gdzie obecna implementacja byłaby lepsza?
  4. Co powinienem powiedzieć na code review gdy kolega zapyta dlaczego to zmieniłem?

23 Rubber duck debugging – Copilot jako słuchacz

Czasem potrzebujesz po prostu wytłumaczyć problem żeby go zobaczyć inaczej. Copilot sprawdza się jako "rubber duck" który zadaje pytania.

copilot

> Chcę Ci wytłumaczyć problem nad którym pracuję. Proszę nie proponuj
  rozwiązania – tylko słuchaj i zadawaj pytania wyjaśniające gdy coś
  jest niejasne lub gdy widzisz lukę w moim rozumowaniu.

  Problem: [twój opis]

# Copilot zadaje pytania, Ty odpowiadasz
# Często samo odpowiadanie na pytania odkrywa rozwiązanie

24 Sprawdzenie własnego kodu "świeżym okiem"

Napisałeś kod, wydaje Ci się że jest OK, ale masz wrażenie że czegoś nie widać po kilku godzinach pracy.

copilot

> @TaskService.cs Przejrzyj ten kod jakbyś widział go po raz pierwszy.
  Udawaj że jesteś seniorem który właśnie dostał ten plik do review
  i nie wie NIC o kontekście jego powstawania.

  Zwróć szczególną uwagę na:
  - Rzeczy które wyglądają "dziwnie" bez kontekstu
  - Miejsca gdzie intencja kodu nie jest jasna
  - Potencjalne pułapki dla następnego developera który będzie to modyfikował

Cookbook który właśnie przeczytałeś to zbiór wzorców zebranych z realnej pracy – nie teoria, tylko rzeczy które działają. Kilka obserwacji na koniec:

• Sesje i pamięć to niedoceniany ficzer – /rename + --continue to tandem który zmienia Copilot CLI z jednorazowego narzędzia w prawdziwego asystenta który pamięta kontekst
• Format odpowiedzi ma ogromne znaczenie – im precyzyjniej opiszesz oczekiwany output, tym mniej edytujesz wynik
• Iteracja > perfekcja na starcie – małe kroki, każdy weryfikowalny, zawsze lepiej niż jeden wielki prompt
• Skills i AGENTS.md w repozytorium to inwestycja która zwraca się przy każdym nowym czlonku teamu i każdym code review
• Rubber duck z pamięcią – brzmi żartobliwie, ale "wytłumacz mi problem zanim zaproponujesz rozwiązanie" to jeden z najskuteczniejszych wzorców w tym zbiorze

Masz swój ulubiony use case który tu pominąłem? Daj znać w komentarzu – najlepsze przepisy pochodzą od czytelników. 🚀

Dziękuję za przejście przez całą serię. 🚀

Jeżeli seria wpisów dotycząca GitHub Copilot CLI była dla Ciebie pomocna, pozwoliła Ci rozwinąć obecne umiejętności lub dzięki niej nauczyłeś się czegoś nowego... będę wdzięczny za wsparcie w każdej postaci wraz z wiadomością, którą będę miał przyjemność przeczytać.

Z góry dziekuje za każde wsparcie - i pamiętajcie, wpisy były, są i będą za darmo!