W poprzednim wpisie rozmawialiśmy o kontekście – co Copilot widzi, a czego nie. Teraz przechodzimy do praktyki: gdzie i jak skonfigurować Copilota żeby zachowywał się tak jak chcemy – konsekwentnie, w całym teamie, bez konieczności tłumaczenia wszystkiego od nowa przy każdej sesji.

Konfiguracja Copilota w VS Code działa na trzech poziomach: user-level, workspace-level i repository-level. Każdy poziom ma inny zakres, inne pliki i służy do innych celów. Jeśli nie rozumiesz tej hierarchii, bardzo łatwo wpaść w sytuację gdzie "u mnie działa, u kolegi nie" albo "skonfigurowałem to w ustawieniach ale jakoś nie działa" – i tracisz czas na debugowanie czegoś co wynika po prostu z nadpisywania ustawień przez wyższy poziom.

Oryginalna dokumentacja, na której bazuje ten wpis: Copilot Configuration Basics – Awesome GitHub Copilot Learning Hub.

Zanim przejdziemy do konkretnych plików, warto zrozumieć hierarchię – bo ona decyduje co "wygrywa" gdy ustawienia na różnych poziomach są sprzeczne.

Omówmy teraz każdy poziom z osobna.

Gdzie to jest?

Ustawienia użytkownika w VS Code znajdziesz pod:

• Windows: %APPDATA%\Code\User\settings.json
• macOS: ~/Library/Application Support/Code/User/settings.json
• Linux: ~/.config/Code/User/settings.json

Możesz też otworzyć to bezpośrednio przez Ctrl+Shift+P → "Open User Settings (JSON)".

Co tu ustawiać?

Na poziomie użytkownika lądują rzeczy które są osobiste i niezwiązane z konkretnym projektem:

{
  // Twój preferred model (może różnić się od teamowego)
  "github.copilot.chat.defaultModel": "gpt-4o",

  // Język interfejsu chatu
  "github.copilot.chat.localeOverride": "pl",

  // Czy Copilot ma działać w plikach markdown (np. notatki)
  "github.copilot.enable": {
    "*": true,
    "plaintext": true,
    "markdown": true,
    "scminput": false
  },

  // Osobiste preferencje podpowiedzi inline
  "github.copilot.editor.enableAutoCompletions": true,

  // Globalny plik instrukcji dla wszystkich projektów
  // (omówiony niżej)
  "github.copilot.chat.codeGeneration.useInstructionFiles": true
}

Globalny plik instrukcji (user-level)

Oprócz settings.json możesz stworzyć globalny plik instrukcji który działa dla wszystkich projektów na Twojej maszynie, niezależnie od repozytorium:

• VS Code: ~/.config/GitHub Copilot/instructions.md (macOS/Linux) lub %APPDATA%\GitHub Copilot\instructions.md (Windows)
• JetBrains: ~/.config/github-copilot/intellij/global-copilot-instructions.md

Jestem senior .NET developerem. Domyślnie używam:
- C# 13 / .NET 9
- Nazewnictwo: PascalCase dla klas i metod, camelCase dla zmiennych lokalnych
- XML doc comments dla wszystkich publicznych API
- Preferuję record types dla niemutowalnych DTOs
- Nie używam var gdy typ nie jest oczywisty z prawej strony przypisania

Odpowiadaj po polsku jeśli piszę po polsku.

Gdzie to jest?

Ustawienia workspace siedzą w katalogu .vscode/ w głównym folderze projektu:

• .vscode/settings.json – ustawienia VS Code i Copilota dla tego projektu
• .vscode/extensions.json – rekomendowane rozszerzenia (VS Code pyta o ich instalację)
• .vscode/tasks.json – zadania build / test / run
• .vscode/launch.json – konfiguracje debugowania

Co tu ustawiać?

Na poziomie workspace lądują rzeczy specyficzne dla technologii projektu, które chcesz zaproponować teamowi – ale nie wymuszać:

// .vscode/settings.json
{
  // Copilot włączony/wyłączony per język dla tego projektu
  "github.copilot.enable": {
    "*": true,
    "env": false,
    "dotenv": false
  },

  // Dla projektu .NET – formatter
  "editor.defaultFormatter": "ms-dotnettools.csharp",
  "editor.formatOnSave": true,
  "editor.tabSize": 4,

  // Pliki do zignorowania w przeszukiwaniu
  "search.exclude": {
    "**/bin": true,
    "**/obj": true,
    "**/node_modules": true
  }
}

// .vscode/extensions.json
{
  "recommendations": [
    "github.copilot",
    "github.copilot-chat",
    "ms-dotnettools.csdevkit",
    "ms-dotnettools.csharp",
    "ms-dotnettools.vscode-dotnet-runtime",
    "editorconfig.editorconfig"
  ]
}

Struktura katalogu .github/

Wszystkie pliki konfiguracyjne Copilota na poziomie repozytorium siedzą w katalogu .github/:

.github/
├── copilot-instructions.md        # Główny plik instrukcji dla całego repo
├── instructions/                  # Szczegółowe instrukcje per język / katalog
│   ├── csharp.instructions.md
│   ├── typescript.instructions.md
│   └── tests.instructions.md
├── prompts/                       # Reużywalne prompty (*.prompt.md)
│   ├── create-endpoint.prompt.md
│   └── write-migration.prompt.md
├── agents/                        # Definicje agentów
│   └── dotnet-senior.agent.md
├── skills/                        # Skille (foldery z SKILL.md)
│   └── generate-unit-tests/
│       ├── SKILL.md
│       └── templates/
└── chatmodes/                     # Tryby chatu
    └── code-review.chatmode.md

Główny plik: copilot-instructions.md

Plik .github/copilot-instructions.md to serce konfiguracji na poziomie repozytorium. Trafia automatycznie do każdej sesji Copilota w tym projekcie – bez żadnej dodatkowej konfiguracji z Twojej strony.

# Instrukcje dla GitHub Copilot – MyProject API

## Stack technologiczny
- .NET 9, C# 13
- Clean Architecture (Domain / Application / Infrastructure / API)
- Entity Framework Core 9 z PostgreSQL
- MediatR dla CQRS
- FluentValidation dla walidacji requestów
- xUnit + FluentAssertions + NSubstitute dla testów

## Zasady kodowania
- Nigdy nie umieszczaj logiki biznesowej w kontrolerach
- Każdy command/query przechodzi przez MediatR handler
- DTOs to record types – niemutowalne
- Każda metoda publiczna ma XML doc comment
- Nazwy metod asynchronicznych kończą się na Async

## Struktura projektu
- Nowe endpointy: MyProject.API/Controllers/
- Handlery: MyProject.Application/[Feature]/Commands/ lub /Queries/
- Encje: MyProject.Domain/Entities/
- Migracje EF: MyProject.Infrastructure/Migrations/

## Czego unikać
- Nie używaj `var` gdy typ nie wynika jasno z prawej strony
- Nie commituj sekretów – używaj user secrets lub zmiennych środowiskowych
- Nie wyłączaj analizatorów Roslynatora bez uzasadnienia w komentarzu

Szczegółowe instrukcje z frontmatter (applyTo)

Pliki *.instructions.md pozwalają na precyzyjne scopowanie instrukcji za pomocą frontmatter:

---
applyTo: "**/*.cs"
description: "Zasady dla kodu C# w tym projekcie"
---

# Instrukcje C#

Używaj pattern matchingu zamiast długich if/else gdzie to możliwe.
Preferuj `switch` expressions nad `switch` statements.
Dla kolekcji używaj LINQ zamiast ręcznych pętli – ale tylko gdy poprawia czytelność.

---
applyTo: "**/*Tests.cs,**/*Spec.cs"
description: "Zasady dla plików testowych"
---

# Instrukcje dla testów

Wzorzec: Arrange / Act / Assert z komentarzami w każdej sekcji.
Nazwy testów: MethodName_Scenario_ExpectedResult (np. CancelOrder_WhenAlreadyCancelled_ThrowsException).
Jeden Assert per test – jeśli potrzebujesz więcej, rozdziel na osobne testy.
Mocki: tylko NSubstitute, nigdy Moq.

To jest właśnie ten dodatek do dokumentacji który chciałem Wam dać. W praktyce najtrudniej jest zdecydować gdzie dane ustawienie powinno trafić. Poniżej zebrałem zasady w jednej tabelce:

Wyobraź sobie klasyczny scenariusz onboardingu: nowy developer dołącza do projektu. Klonuje repo, otwiera VS Code i zaczyna pracować z Copilotem. Co dostaje?

Dobrze skonfigurowane repozytorium sprawia że Copilot działa jak senior developer który był przy projekcie od początku – nie jak stażysta który nie czytał żadnej dokumentacji.

Trzy poziomy konfiguracji, trzy różne zastosowania:

• ✅ USER User-level – osobiste preferencje, żyje tylko na Twojej maszynie. Model, język, własny styl. Nigdy nie commitowany.
• ✅ WORKSPACE Workspace-level – ustawienia projektu w .vscode/. Formatter, rozszerzenia, konfiguracje debugowania. Commituj – ale nie wymuszaj.
• ✅ REPO Repository-level – versjonowana wiedza o projekcie w .github/. Instrukcje, agenci, skille, zasady teamu. Obowiązkowe dla spójnej pracy w grupie.

Im lepiej wypełnisz poziom repozytorium, tym mniej czasu tracisz na tłumaczenie kontekstu – zarówno Copilotowi, jak i nowym developerom w teamie.

W kolejnym wpisie wchodzimy głębiej w temat instrukcji: jak definiować własne instrukcje – jak je pisać żeby działały, czego unikać i jak je scopować do konkretnych części projektu.