Przez osiem artykułów budowałeś zestaw narzędzi: tryby pracy, zarządzanie kontekstem, pięć workflow developerskich, agenci, Skills i MCP Servers. Teraz czas przestać omawiać elementy osobno i zobaczyć jak działają razem jako spójny system.

Ten artykuł to jedno wielkie demo. Weźmiemy projekt TaskList który rozwijaliśmy przez całą serię i przeprowadzimy kompletny cykl: od zgłoszenia buga przez implementację, testy, security review, aż po zamknięty PR – wszystko z terminala, bez przełączania kontekstu.

Zanim wejdziemy w demo, jeden diagram który porządkuje cały zestaw narzędzi:

Kluczowa obserwacja: kontekst zawsze pierwszy. Zanim poprosisz agenta o analizę – daj mu dane. Agent bez kontekstu daje generyczne odpowiedzi. Agent z pełnym kontekstem daje precyzyjne wskazówki.

Scenariusz: użytkownicy zgłaszają że wyszukiwanie zadań po tytule nie działa dla małych liter. Mamy otwarte issue #3.

Faza 1: Zbierz kontekst (MCP)

copilot

# GitHub MCP odczytuje issue bez żadnego copy-paste
> Pobierz szczegóły issue #3

# Filesystem MCP bada projekt
> Ile plików .cs ma projekt? Wylistuj z krótkim opisem.

# Zrozum konkretny kod
> @TaskService.cs Pokaż mi metodę Search() – szukam przyczyny
  case-sensitive matchowania

Faza 2: Zaplanuj (/plan)

> /plan Napraw metodę Search() w TaskService.cs żeby działała
  case-insensitively. Uwzględnij testy i walidację.

Copilot tworzy plan krok po kroku: zmiana implementacji → aktualizacja XML docs → testy → commit.

Faza 3: Zaimplementuj (agent dotnet-reviewer)

> /agent
# Wybierz "dotnet-reviewer"

> @TaskService.cs Zaimplementuj fix z planu. Pamiętaj o:
  walidacji parametru, XML docs, StringComparison.OrdinalIgnoreCase

Agent generuje kod zgodny z naszymi standardami C# – XML docs, walidacja przez ArgumentException.ThrowIfNullOrWhiteSpace, poprawne porównanie:

/// <summary>Wyszukuje zadania zawierające podany fragment tytułu.</summary>
/// <param name="query">Fragment tytułu. Nie może być null ani whitespace.</param>
/// <returns>Pasujące zadania. Pusta kolekcja gdy brak wyników.</returns>
/// <exception cref="ArgumentException">Query jest null lub whitespace.</exception>
public IEnumerable<TaskItem> Search(string query)
{
    ArgumentException.ThrowIfNullOrWhiteSpace(query, nameof(query));
    return _tasks.Where(t =>
        t.Title.Contains(query, StringComparison.OrdinalIgnoreCase));
}

Faza 4: Przetestuj (agent xunit-helper)

> /agent
# Wybierz "xunit-helper"

> @TaskService.cs Wygeneruj testy xUnit dla naprawionej metody Search().
  Uwzględnij: exact match, lowercase query, uppercase query,
  partial match, brak wyników, pusta kolekcja, null/whitespace query.

Uruchom testy bez wychodzenia z sesji:

> !dotnet test
# Agent Task raportuje: "Wszystkie testy przeszły" albo pełny stack trace jeśli nie

Faza 5: Przejrzyj (/review + Skill dotnet-checklist)

> /agent
# Wróć do domyślnego (no agent) lub użyj security-reviewer

> /review
# Skill dotnet-checklist auto-ładuje się bo widzimy "code review" w kontekście
# Wbudowany agent /review sprawdza staged/unstaged zmiany

Faza 6: Wyślij (Skill commit-message + GitHub MCP)

> /exit

git add .
copilot -p "Wygeneruj conventional commit message dla: $(git diff --staged)"
# Output: "fix(TaskService): popraw wyszukiwanie na case-insensitive
#
# - Zmień porównanie na StringComparison.OrdinalIgnoreCase
# - Dodaj walidację parametru query
# - refs #3"

git commit -m "fix(TaskService): popraw wyszukiwanie na case-insensitive..."

copilot

> /pr create
# GitHub MCP tworzy PR i automatycznie linkuje do issue #3

Drugi scenariusz: dodajemy funkcję wyszukiwania zadań po zakresie dat – od podstaw, cały proces w jednej sesji.

copilot

# Krok 1: Plan
> /plan Dodaj metodę SearchByDateRange(DateTime from, DateTime to) do TaskService.
  TaskItem musi przechowywać datę dodania. Uwzględnij: migrację danych w tasks.json,
  implementację, testy, aktualizację Program.cs.

# Krok 2: Implementacja z dotnet-reviewer
> /agent
# Wybierz "dotnet-reviewer"
> @TaskService.cs @Program.cs Zaimplementuj krok 1 i 2 z planu

# Krok 3: Sprawdź czy tasks.json wymaga migracji
> @tasks.json Czy istniejące dane wymagają migracji? Jak obsłużyć brakujące pole CreatedAt?

# Krok 4: Testy
> /agent
# Wybierz "xunit-helper"
> Wygeneruj testy dla SearchByDateRange: range z wynikami, pusty range,
  odwrócony range (from > to), pusta kolekcja, granice zakresu (inclusive)

# Krok 5: Uruchom
> !dotnet test

# Krok 6: Review
> /review

# Krok 7: Wyślij
> /exit

git add .
copilot -p "Wygeneruj conventional commit message dla: $(git diff --staged)"
git commit -m "..."

Trzeci scenariusz pokazuje wartość MCP przy wchodzeniu na nowy projekt. Zakładamy że dostajesz dostęp do repozytorium .NET którego nie znasz.

copilot

# Faza 1: Wielkie spojrzenie – Filesystem MCP
> Opisz architekturę tego projektu .NET. Warstwy, zależności, entry points.

# Faza 2: Konkretny przepływ – składnia @
> @Program.cs @TaskService.cs Co się dzieje gdy użytkownik woła "dotnet run -- add Zakupy"?
  Prześledź krok po kroku.

# Faza 3: Analiza jakości – agent dotnet-reviewer
> /agent
# Wybierz "dotnet-reviewer"
> @TaskService.cs Jakie są problemy projektowe, braki w obsłudze błędów
  i możliwości usprawnień?

# Faza 4: Co robić – GitHub MCP
> Wylistuj otwarte issues posortowane według priorytetu

# Faza 5: Zacznij kontrybuować
> Pobierz szczegóły najprostszego issue i zaproponuj plan implementacji

To co normalnie zajmuje kilka dni czytania dokumentacji i kodu – Copilot CLI skraca do jednej sesji.

Opcjonalne, ale bardzo wartościowe: security review automatycznie przed każdym commitem. Hook sprawdza staged pliki .cs i blokuje commit jeśli znajdzie krytyczne problemy.

cat > .git/hooks/pre-commit << 'EOF'
#!/bin/bash
# Pre-commit hook: security review staged plików C#

STAGED=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.cs$')

if [ -n "$STAGED" ]; then
    echo "Copilot security review staged plików C#..."
    for file in $STAGED; do
        echo "  Sprawdzam: $file"
        REVIEW=$(timeout 60 copilot --allow-all -p \
            "Security review @$file – tylko KRYTYCZNE problemy: SQL injection,
             path traversal, hardcoded secrets, brak walidacji. Odpowiedź jednym
             słowem PASS lub FAIL z krótkim uzasadnieniem." 2>/dev/null)

        if [ $? -eq 124 ]; then
            echo "  Warning: timeout dla $file (pomijam)"
            continue
        fi

        if echo "$REVIEW" | grep -qi "FAIL"; then
            echo "  Krytyczny problem w $file:"
            echo "$REVIEW"
            exit 1
        fi
    done
    echo "Security review: OK"
fi
EOF
chmod +x .git/hooks/pre-commit

1. Kontekst zawsze pierwszy

Zanim poprosisz o analizę – zbierz kontekst. Agent bez danych daje generyczne odpowiedzi. Agent z issue, plikami i historią commitów daje precyzyjne wskazówki.

# Dobrze: kontekst → analiza
> Pobierz issue #8
> /agent → dotnet-reviewer
> @TaskService.cs Zanalizuj problem z issue #8

# Gorzej: analiza bez kontekstu
> /agent → dotnet-reviewer
> Napraw błąd w TaskService

2. Jeden temat per sesja

Używaj /rename na początku sesji i /exit na końcu. Jedna sesja = jeden feature/bug. Łatwiej wznowić, łatwiej eksportować przez /share.

copilot
> /rename fix-search-case-insensitive
# praca...
> /exit

copilot
> /rename feat-date-range-search
# praca...
> /exit

3. Właściwe narzędzie do właściwego zadania

4. Enkoduj workflow w repozytorium, nie w głowach

Agenci, Skills i AGENTS.md żyją w .github/ i są wersjonowane razem z kodem. Nowi członkowie teamu dostają Twoje workflow za darmo – nie muszą się uczyć od zera ani pytać kolegów "jak u was robi się code review".

.github/
├── agents/
│   ├── dotnet-reviewer.agent.md
│   ├── xunit-helper.agent.md
│   └── security-reviewer.agent.md
├── skills/
│   ├── dotnet-checklist/SKILL.md
│   ├── xunit-gen/SKILL.md
│   └── commit-message/SKILL.md
├── instructions/
│   └── csharp-standards.instructions.md
└── copilot-instructions.md   # lub AGENTS.md w katalogu głównym

To repozytorium staje się wtedy self-documenting – standardy i workflow są w nim zakodowane, nie tylko w dokumentacji, której (zwykle) nikt nie czyta.

Jeden z najpraktyczniejszych snippetów całej serii – PowerShell skrypt który generuje pełen opis PR z logu commitów:

# PowerShell
$branch = git branch --show-current
$commits = git log main..$branch --oneline

copilot -p "Wygeneruj opis pull requesta dla:
Branch: $branch

Commity:
$commits

Uwzględnij:
- Podsumowanie zmian (2-3 zdania)
- Co zostało zmienione i dlaczego
- Jak testować zmiany
- Czy są breaking changes? (tak/nie)
- Numer issues które zamykają te zmiany (jeśli widoczne z commitów)"

Czas zamknąć całą serię. Zaczęliśmy od pytania "czym jest Copilot CLI i czym różni się od Copilota w IDE", a kończymy z kompletnym toolsetem który zmienia sposób pracy.

Najważniejsza rzecz do zapamiętania z całej serii: Copilot CLI nie zastępuje Cię jako developera. Zastępuje mechaniczne, powtarzalne fragmenty pracy – przepisywanie stack trace'ów, wyszukiwanie w dokumentacji, pisanie boilerplate'u, generowanie checklisty review. Ty zostajesz architektem który decyduje co zbudować i ocenić czy efekt jest dobry.

Najbardziej doświadczeni developerzy zyskują na tym nieproporcjonalnie dużo – bo wiedzą jak zadać właściwe pytanie, jak ocenić output i jak połączyć pracę AI w spójną architekturę. Copilot CLI nie podnosi poprzeczki dla juniorów. Mnoży możliwości seniorów.