User-level vs Project-level: co gdzie trzymać

Czego się nauczysz

• Jak rozdzielać osobiste preferencje od zasad repozytorium i organizacji
• Dlaczego zły podział instrukcji psuje współpracę zespołu i przewidywalność odpowiedzi AI
• Jak działa priorytet instrukcji oraz co to zmienia w praktyce

Najprostsza zasada brzmi: prywatne trzymaj prywatnie, projektowe trzymaj w repo

Brzmi banalnie, ale to jeden z najczęściej psutych obszarów personalizacji Copilota.

Jeśli wrzucisz osobiste nawyki do repo, zespół dostanie szum. Jeśli wrzucisz reguły projektu do user-level, inni ich nie zobaczą, a agent będzie zachowywał się inaczej u każdej osoby.

Skutek jest zawsze ten sam: brak przewidywalności.

Co powinno być user-level

Do poziomu użytkownika trafiają rzeczy, które opisują Ciebie, a nie projekt.

Na przykład:

• sposób formatu odpowiedzi
• prywatne skróty workflow
• preferowany ton albo styl pracy z AI
• osobiste prompt files do własnych rutyn

To są rzeczy, które mogą synchronizować się między urządzeniami przez Settings Sync i nie muszą trafiać do repo.

Co powinno być project-level

Do repo trafia wszystko to, co ma obowiązywać niezależnie od osoby siedzącej przy klawiaturze.

Na przykład:

• .github/copilot-instructions.md
• .github/instructions/**/*.instructions.md
• .github/prompts/**/*.prompt.md
• agenty i inne customizations związane z projektem

To część operacyjnej dokumentacji pracy z AI. Jeśli zespół ma z tego korzystać wspólnie, to powinno być wersjonowane, reviewowane i widoczne w repo.

Priorytet instrukcji ma praktyczne konsekwencje

Aktualna dokumentacja mówi jasno:

1. najwyższy priorytet mają personal instructions
2. potem instrukcje repozytorium
3. najniżej stoją organization instructions

To oznacza jedną niewygodną, ale ważną rzecz: jeśli Twoje user-level instructions konfliktują z repo, Twoje prywatne reguły wygrają.

Z perspektywy zespołowej to potrafi być źródło trudnych do zdiagnozowania rozjazdów.

Dlatego user-level powinien zawierać rzeczy neutralne wobec projektu, a nie lokalne “nadpisania” polityki repo.

Organizacja to trzeci poziom, nie zamiennik repo

Organization-level instructions są świetne do rzeczy szerokich:

• polityki bezpieczeństwa
• standardów obowiązujących w wielu repo
• wspólnych zasad pracy z AI w firmie

Ale nie są dobrym miejscem na szczegóły konkretnej aplikacji. Do tego nadal lepiej nadaje się repo.

Najlepiej myśleć o tym tak:

• user: ja
• repo: ten projekt
• organization: nasza szeroka polityka

Prompt files też trzeba dzielić świadomie

Ten sam filtr działa dla .prompt.md.

Jeśli prompt:

• jest częścią zespołowego procesu
• ma sens dla innych osób
• dotyczy repo lub produktu

to powinien być project-level.

Jeśli jest Twoim prywatnym skrótem myślowym, eksperymentem albo osobistym workflow, trzymaj go user-level.

Monorepo wymaga dodatkowej uwagi

W monorepo dochodzi jeszcze kwestia parent repository discovery. Dokumentacja podkreśla, że ten mechanizm nie jest włączony domyślnie.

To ma praktyczny skutek: jeśli otwierasz tylko fragment repo, możesz nie widzieć customizations z roota, dopóki nie włączysz odpowiedniego settingu.

Dlatego przy monorepo trzeba świadomie zdecydować:

• co trzymać globalnie w root
• co trzymać bliżej konkretnego pakietu albo obszaru
• czy discovery jest włączone w typowym setupie zespołu

Sync jest wygodny, ale nie powinien zastępować repo

Docs wspierają synchronizację user instructions i user prompt files między urządzeniami. To świetne dla prywatnych ustawień.

Nie wolno jednak traktować tego jako substytutu commitowania projektowych customizations.

Jeśli reguła ma być widoczna dla wszystkich, musi być w repo albo na poziomie organizacji. Inaczej współpraca z AI staje się nieprzezroczysta.

Prosty filtr decyzyjny

Gdy nie wiesz, gdzie coś umieścić, zadaj sobie trzy pytania:

1. Czy to dotyczy mnie, czy projektu?
2. Czy inni powinni to widzieć i reviewować?
3. Czy konflikt tej reguły z repo byłby groźny?

Jeśli odpowiedź brzmi “to dotyczy projektu” albo “inni powinni to widzieć”, trzymaj to poza user-level.

Kluczowe wnioski

• User-level służy do prywatnych preferencji i osobistych workflow, nie do zasad projektu.
• Project-level powinien zawierać wszystko, co ma być wspólne, wersjonowane i przewidywalne dla zespołu.
• Personal instructions mają wyższy priorytet niż repo, więc konfliktujące prywatne reguły potrafią rozjechać zachowanie AI.
• Organization-level dobrze nadaje się do szerokich standardów, ale nie zastępuje instrukcji repo.
• W monorepo trzeba świadomie zarządzić parent repository discovery i rozmieszczeniem customizations.

Co dalej

Masz już kompletny zestaw podstaw personalizacji: always-on instructions, scoped rules, prompt files i sensowny podział odpowiedzialności. To moment, w którym Copilot przestaje być zbiorem promptów, a zaczyna działać jak konfigurowalne środowisko pracy.