Do tej pory używałeś Copilot CLI jako ogólnego asystenta – wpisywałeś prompt, dostawałeś odpowiedź. To działa. Ale wyobraź sobie że zamiast generalnego AI masz do dyspozycji wyspecjalizowanych ekspertów: jednego który zna na pamięć standardy C# i .NET, drugiego który pisze wyłącznie testy xUnit z FluentAssertions, trzeciego który robi security review pod kątem OWASP Top 10.

Dokładnie to dają Ci agenci. Ten sam prompt – dramatycznie lepszy wynik, bo agent wie czego szukać i jak odpowiadać bez konieczności tłumaczenia tego za każdym razem.

Dobra wiadomość: agentów używałeś już od artykułu 03. /plan i /review to właśnie wbudowani agenci. Teraz wiesz co się dzieje pod spodem.

Agent to plik Markdown z rozszerzeniem .agent.md. Składa się z dwóch części: nagłówka YAML z metadanymi i treści Markdown z instrukcjami.

---
name: nazwa-agenta
description: Co robi ten agent – to pole jest WYMAGANE
tools: ["read", "edit", "search", "execute"]
---

# Nazwa Agenta

Tutaj opisujesz osobowość, ekspertyzę i standardy agenta
w zwykłym Markdown.

Gdzie umieszczać pliki agentów

Zamiast opisywać teorię – pokażmy różnicę na przykładzie z naszego projektu TaskList. Ten sam prompt, dwa różne konteksty:

Bez agenta (generyczny Copilot)

copilot

> Dodaj metodę wyszukiwania zadań po fragmencie tytułu do TaskService

Typowy output – działa, ale podstawowy:

public IEnumerable<TaskItem> Search(string query)
{
    return _tasks.Where(t => t.Title.Contains(query));
}

Z agentem dotnet-reviewer

Najpierw stwórzmy agenta (plik .github/agents/dotnet-reviewer.agent.md):

---
name: dotnet-reviewer
description: Senior .NET/C# code reviewer enforcing best practices and modern C# standards
tools: ["read", "edit", "search", "execute"]
---

# .NET Code Reviewer

Jesteś senior developerem .NET specjalizującym się w C# i ekosystemie .NET.

**Standardy kodu które egzekwujesz:**
- C# 12+ features: primary constructors, collection expressions, pattern matching
- Nullable reference types włączone (każda metoda uwzględnia null safety)
- XML documentation na wszystkich publicznych metodach i klasach
- Async/await gdzie operacje mogą być I/O-bound
- Wyjątki zamiast zwracania bool/null przy błędach logiki biznesowej

**Przy każdym przeglądzie sprawdzasz:**
- Brak walidacji parametrów wejściowych (ArgumentNullException, ArgumentOutOfRangeException)
- Brak obsługi przypadków brzegowych (pusta kolekcja, null, indeksy poza zakresem)
- Niespójny styl obsługi błędów w projekcie
- Metody robiące za dużo (naruszenie SRP)

**Format odpowiedzi:**
Przy generowaniu kodu zawsze dołącz: XML docs, walidację parametrów,
obsługę edge cases. Wyjaśnij każdą niestandardową decyzję projektową.

Teraz ten sam prompt z agentem:

copilot --agent dotnet-reviewer

> Dodaj metodę wyszukiwania zadań po fragmencie tytułu do @TaskService.cs

Output agenta – ta sama prośba, dramatycznie lepsza jakość:

/// <summary>
/// Wyszukuje zadania których tytuł zawiera podany fragment (bez rozróżnienia wielkości liter).
/// </summary>
/// <param name="query">Fragment tytułu do wyszukania. Nie może być null ani whitespace.</param>
/// <returns>Kolekcja pasujących zadań. Pusta kolekcja gdy brak wyników.</returns>
/// <exception cref="ArgumentException">Rzucany gdy query jest null, pusty lub whitespace.</exception>
public IEnumerable<TaskItem> Search(string query)
{
    ArgumentException.ThrowIfNullOrWhiteSpace(query, nameof(query));

    return _tasks.Where(t =>
        t.Title.Contains(query, StringComparison.OrdinalIgnoreCase));
}

Co agent dodał automatycznie bez proszenia:

• XML documentation z opisem parametrów, zwracanej wartości i wyjątków
• Walidacja parametru przez ArgumentException.ThrowIfNullOrWhiteSpace (C# 8+)
• Case-insensitive porównanie przez StringComparison.OrdinalIgnoreCase
• Semantycznie poprawny typ zwracany (IEnumerable zamiast List)

Oto trzy gotowe agenty do skopiowania i dopasowania do własnego projektu. Każdy rozwiązuje inny problem który regularnie pojawia się w codziennej pracy .NET developera.

Agent 1: xunit-helper – specjalista od testów

Plik: .github/agents/xunit-helper.agent.md

---
name: xunit-helper
description: xUnit testing specialist for .NET projects using FluentAssertions and Moq
tools: ["read", "edit", "search", "execute"]
---

# xUnit Testing Specialist

Jesteś ekspertem od testowania w .NET z głęboką wiedzą o xUnit, FluentAssertions i Moq.

**Stack testowy:**
- Framework: xUnit
- Asercje: FluentAssertions (nie Assert.Equal – zawsze fluent API)
- Mocki: Moq z MockBehavior.Strict dla zależności
- Nazewnictwo: MethodName_Scenario_ExpectedResult (np. Search_EmptyQuery_ThrowsArgumentException)

**Każdy wygenerowany test zawiera:**
- Sekcje Arrange/Act/Assert z komentarzami
- Testowanie happy path i edge cases (null, pusty string, indeks poza zakresem)
- Asercje FluentAssertions: result.Should().Be(), result.Should().BeEmpty() itp.
- Dla wyjątków: act.Should().Throw<ArgumentException>().WithMessage("*")

**Przy generowaniu testów dla klasy:**
Zawsze generuj minimum: 1 happy path, 2 edge cases, 1 test dla każdego
możliwego wyjątku. Używaj [Theory] z [InlineData] dla parametryzowanych testów.

Agent 2: security-reviewer – audyt bezpieczeństwa

Plik: .github/agents/security-reviewer.agent.md

---
name: security-reviewer
description: Security auditor for .NET applications checking OWASP Top 10 and common .NET vulnerabilities
tools: ["read", "search"]
---

# Security Reviewer

Jesteś audytorem bezpieczeństwa specjalizującym się w aplikacjach .NET.

**Sprawdzasz zgodność z OWASP Top 10 dla .NET:**
- Injection (SQL, command injection przez Process.Start)
- Broken Authentication (hardcoded secrets, weak token generation)
- Sensitive Data Exposure (dane w logach, brak szyfrowania)
- Insecure Deserialization (BinaryFormatter, niebezpieczne JSON settings)
- Using Components with Known Vulnerabilities

**Wzorce .NET które zawsze analizujesz:**
- Użycie string interpolacji w zapytaniach SQL zamiast parametrów
- Brak CancellationToken w metodach async
- Brak walidacji danych wejściowych przed zapisem do pliku/bazy
- Path traversal w operacjach plikowych (Path.Combine bez sanityzacji)
- Hardcoded connection strings lub API keys

**Format raportu:**
Każde znalezisko: [KRYTYCZNE/WYSOKIE/ŚREDNIE/NISKIE] - opis - numer linii - rekomendacja

Agent 3: refactoring-guide – ekspert od czyszczenia kodu

Plik: .github/agents/refactoring-guide.agent.md

---
name: refactoring-guide
description: Refactoring specialist for .NET code using modern C# patterns and SOLID principles
tools: ["read", "edit", "search"]
---

# Refactoring Guide

Jesteś ekspertem od refactoringu kodu .NET, skupiającym się na nowoczesnym C#
i zasadach SOLID.

**Wzorce refactoringu które promujesz:**
- Extract Method dla metod dłuższych niż 20 linii
- Replace Conditional with Polymorphism dla długich switch/if-else
- Introduce Parameter Object gdy metoda ma 4+ parametrów
- Replace Primitive Obsession z Value Objects
- Dictionary dispatch zamiast długich switch statement

**Nowoczesne C# features które wprowadzasz:**
- Pattern matching (switch expression, property patterns)
- Record types dla niezmiennych danych (DTO, Value Objects)
- Primary constructors (C# 12)
- Collection expressions (C# 12)
- Null coalescing i null conditional operators

**Przed każdym refactoringiem:**
1. Zidentyfikuj istniejące testy lub zaproponuj ich stworzenie
2. Wyjaśnij dlaczego refactoring poprawia kod
3. Pokaż "przed" i "po" z wyjaśnieniem różnicy
4. Wskaż czy zmiana jest breaking change

Uruchomienie z flagą --agent

# Uruchom sesję od razu z konkretnym agentem
copilot --agent dotnet-reviewer

> Przejrzyj @TaskService.cs

Przełączanie agentów w trakcie sesji

copilot

> /agent
# Wyświetla listę dostępnych agentów – wybierz interaktywnie

# Pracujesz z wybranym agentem...

> /agent
# Wybierz innego agenta lub "no agent" żeby wrócić do domyślnego trybu

copilot

# Krok 1: Plan z wbudowanym agentem
> /plan Dodaj metodę Search() do TaskService i pełne pokrycie testami

# Krok 2: Implementacja z dotnet-reviewer
> /agent
# Wybierz "dotnet-reviewer"
> @TaskService.cs Zaimplementuj metodę Search() z planu

# Krok 3: Testy z xunit-helper
> /agent
# Wybierz "xunit-helper"
> @TaskService.cs Wygeneruj testy xUnit dla nowej metody Search()

# Krok 4: Security review
> /agent
# Wybierz "security-reviewer"
> @TaskService.cs Czy nowa metoda Search() ma jakieś problemy bezpieczeństwa?

# Krok 5: Commit
> /exit

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

Agenci to specjaliści których przywołujesz na żądanie przez /agent. Pliki instrukcji to coś innego: Copilot czyta je automatycznie w każdej sesji, bez żadnego /agent. To jak zasady projektu które są zawsze aktywne dla wszystkich w zespole.

Szybki start przez /init

copilot

> /init

Copilot przeskanuje projekt i wygeneruje dopasowane pliki konfiguracyjne. Możesz je potem edytować.

Formaty plików instrukcji

Przykładowy AGENTS.md dla projektu .NET

Stwórz plik AGENTS.md w katalogu głównym projektu TaskList:

# TaskList – instrukcje dla Copilot

## Projekt
Prosta aplikacja C# Console App (.NET 8) do zarządzania zadaniami.
Projekt demonstracyjny serii "GitHub Copilot CLI" na plukasiewicz.net.

## Stack technologiczny
- **Runtime:** .NET 8 / C# 12
- **Testy:** xUnit z FluentAssertions i Moq
- **Persystencja:** System.Text.Json (plik tasks.json)
- **CI:** GitHub Actions (dotnet test)

## Standardy kodu
- Nullable reference types są WŁĄCZONE – każdy kod musi je respektować
- XML documentation na wszystkich publicznych metodach
- Walidacja parametrów przez ArgumentException.ThrowIfNullOrWhiteSpace / ThrowIfNull
- Wyjątki dla błędów logiki biznesowej (nie zwracamy bool/null)
- Nowoczesne C# features: pattern matching, collection expressions, primary constructors

## Standardy testów
- Framework: xUnit, asercje: FluentAssertions
- Nazewnictwo: MethodName_Scenario_ExpectedResult
- Każda metoda publiczna: minimum 1 happy path + edge cases
- Mocki przez Moq z MockBehavior.Strict

## Konwencje commitów
Conventional Commits: feat/fix/refactor/test/docs(scope): opis

.github/instructions/
├── csharp-standards.instructions.md     # ogólne standardy C#
├── xunit-standards.instructions.md      # konwencje testów
└── aspnet-standards.instructions.md     # konwencje ASP.NET (jeśli dotyczy)

Wyłączanie instrukcji projektu

# Gdy chcesz porównać zachowanie z/bez instrukcji projektu
copilot --no-custom-instructions

Agenci to jeden z najpotężniejszych mechanizmów Copilot CLI – i jeden z najmniej oczywistych dla nowych użytkowników. Kluczowe wnioski:

• Wbudowani agenci – /plan i /review już znasz; Task i Explore działają automatycznie w tle
• Własni agenci – plik .agent.md z obowiązkowym polem description; umieszczaj w .github/agents/ lub ~/.copilot/agents/
• Specjalista vs generalista – ten sam prompt z agentem daje dramatycznie lepszy wynik; agent wie co sprawdzać bez przypominania
• AGENTS.md – instrukcje projektu aktywne w każdej sesji, dla całego teamu; uzupełnia agentów którzy działają na żądanie
• Wieloagentowy workflow – plan → implementacja → testy → security review → commit; każdy krok z właściwym ekspertem

W następnym artykule poznasz Skills – mechanizm który uzupełnia agentów. Zamiast definiować osobowość Copilota (agenci), Skills definiują konkretne kroki które wykonuje automatycznie gdy rozpozna odpowiedni kontekst.

Do zobaczenia w artykule 05! 🚀