Jakie konwencje katalogów i style kodu dobrze obsługują Codex i Claude Code?

Codex i Claude Code nie preferują z natury określonego języka programowania, frameworka, szerokości wcięć ani układu katalogów. Środowiska, których zasady mogą stosować względnie niezawodnie, to takie, w których istniejące konwencje repozytorium są spójne, zakres wymaganych reguł jest jasny, a zmiany można automatycznie zweryfikować. Celem nie jest więc wymyślenie struktury, która mogłaby odpowiadać AI, lecz stworzenie konwencji projektu, które ludzie i nowi współtwórcy zrozumieją, a także które będą krótkie i weryfikowalne. openai.com↗code.claude.com↗

Terminów Codex i Claude Code używamy tutaj w odniesieniu do narzędzi agentów programistycznych, które mogą czytać pliki w repozytorium, korzystać z instrukcji, modyfikować kod lub uruchamiać polecenia. Takie narzędzia czerpią wiele wskazówek z samego kodu, lecz nie zawsze potrafią trafnie wywnioskować terminologię domeny produktu, zakazane zmiany, kontrole przed wdrożeniem ani reguły wyjątków dla określonych katalogów. Tę lukę wypełniają struktura repozytorium, pliki instrukcji i wykonywalne procedury walidacyjne. cdn.openai.com↗

Dlaczego spójność jest ważniejsza niż „właściwa struktura katalogów”?

Przykładowo jeden zespół może organizować src/payments/ i src/users/ według funkcji, a inny src/controllers/, src/services/ i src/repositories/ według warstw. Nie ma podstaw, aby rozstrzygająco stwierdzić, że któreś z tych podejść jest automatycznie lepsze dla Codex lub Claude Code. Istotne jest, aby odpowiedzialności tego samego rodzaju miały podobne lokalizacje w repozytorium, nowe pliki były umieszczane według tych samych kryteriów, a testy i style importów były zgodne z istniejącymi wzorcami.

To samo dotyczy sytuacji, gdy agent dodaje nową funkcję płatności. Jeżeli istniejący moduł płatności pokazuje, jak zorganizowane są walidacja żądań, obsługa błędów, dostęp do danych i testy, bezpieczniej jest kontynuować ten wzorzec. Z kolei jeśli każda nowa funkcja wprowadza nowe nazwy plików i warstwy albo jeśli pojedynczy katalog miesza kod domenowy z artefaktami kompilacji i plikami tymczasowymi, zarówno agenci, jak i ludzie będą mieć trudność z określeniem, gdzie wprowadzić zmiany i na co one wpłyną.

Konwencje katalogów nie są zatem jedynie zasadami wyglądu. Są systemem nawigacji, który wskazuje, gdzie znaleźć kod, co zmieniać razem i jaką walidację uruchomić. Im stabilniejsze są nazwy i granice, tym mniejsza jest potrzeba powtarzania długich wyjaśnień w plikach instrukcji.

Gdzie powinny znajdować się podstawowe wskazówki dotyczące repozytorium?

W Codex plik AGENTS.md zwykle pełni rolę pliku instrukcji projektu. Instrukcje dotyczące stylu kodu, struktury, nazewnictwa i testowania zawarte w tym pliku obowiązują dla katalogu, w którym się znajduje, oraz jego poddrzewa, a instrukcje w głębszych lokalizacjach mogą w razie konfliktu stanowić bardziej szczegółowe wskazówki. Obsługiwane są także instrukcje środowiska osobistego i nadpisania za pośrednictwem AGENTS.override.md. openai.com↗

W Claude Code plik CLAUDE.md lub .claude/CLAUDE.md może pełnić centralną rolę dla pamięci i wskazówek projektu. Plik CLAUDE.md w ścieżce nadrzędnej może zostać przekazany jako kontekst przy uruchomieniu, natomiast pliki w podkatalogach są ładowane w razie potrzeby podczas obsługi plików w tych ścieżkach. Możesz również używać CLAUDE.local.md dla ustawień per użytkownik oraz plików na poziomie katalogu domowego. code.claude.com↗

Mimo że nazwy tych dwóch plików są podobne, ich zachowanie w zakresie automatycznego wykrywania nie jest takie samo. W szczególności nie zakładaj, że Claude Code automatycznie odczyta AGENTS.md jako wspólne instrukcje. Gdy używasz obu narzędzi, zaimportuj wspólny plik w CLAUDE.md przez @AGENTS.md albo jasno zdefiniuj połączenie odpowiadające modelowi pracy zespołu. code.claude.com↗

Najlepiej, aby główny plik wskazówek był bliższy mapie wejściowej niż encyklopedii opisującej całe repozytorium szczegółowo. Wystarczy wskazać polecenia, których nowy współtwórca potrzebuje w pierwszej kolejności, strukturę najwyższego poziomu, kluczowe niezmienniki i lokalizacje szczegółowej dokumentacji. Długi, pojedynczy plik instrukcji zużywa kontekst, który powinien być wykorzystany na rzeczywisty kod i wymagania zadania, a także może utrudniać zauważenie krytycznych ograniczeń. Przykład związany z OpenAI Codex również przedstawia połączenie krótkiego, przypominającego mapę pliku o długości około 100 wierszy oraz osobnej dokumentacji. openai.com↗

Co powinny zawierać AGENTS.md i CLAUDE.md?

Dobre instrukcje nie powielają szeroko faktów, które są już oczywiste z kodu. Zamiast tego priorytetowo traktują informacje, których trudno nauczyć się wyłącznie z kodu albo których błędne wywnioskowanie jest kosztowne. Materiały dotyczące Codex wskazują konwencje nazewnictwa, język domenowy, znane ograniczenia i zależności oraz procedury budowania i testowania jako informacje warte umieszczenia w AGENTS.md. cdn.openai.com↗

Instrukcje główne mogą zwięźle odpowiadać na pytania takie jak:

• Które polecenia uruchamiają formatowanie, analizę statyczną, sprawdzanie typów i testy po początkowej zmianie?
• Gdzie znajdują się kod źródłowy, testy, dokumentacja projektowa i dokumentacja operacyjna?
• Jakich konwencji nazewnictwa plików, importów, obsługi błędów i testowania należy przestrzegać przy rozszerzaniu istniejącego modułu?
• Czy pliki generowane, artefakty kompilacji, pliki lock i sekrety można modyfikować lub dodawać do repozytorium?
• Czy obszary wysokiego ryzyka wymagają planu, dodatkowego przeglądu lub określonych testów?
• Które dokumenty zawierają szczegółowy projekt i procedury operacyjne?

Natomiast ogólne stwierdzenia, takie jak „pisz czysty kod”, „stawiaj bezpieczeństwo na pierwszym miejscu” czy „daj z siebie wszystko”, trudno przekształcić w wykonywalne reguły. Stwierdzenie w rodzaju „używaj istniejącego modułu walidacji dla zewnętrznych danych wejściowych i dodawaj odpowiedni test integracyjny dla każdej nowej trasy API” jest bardziej użyteczne, ponieważ można je zaobserwować i zweryfikować. Wskazówki dotyczące Claude Code również kładą nacisk na konkretne zapisywanie reguł specyficznych dla projektu oraz na regularny przegląd i porządkowanie instrukcji w miarę ich rozrastania się. code.claude.com↗

Instrukcje powinny być skondensowanym zapisem kryteriów decyzji, a nie dokumentem narzucającym każdy szczegół implementacji. Wiedzę, która jest obszerna i prawdopodobnie będzie się zmieniać — na przykład sposób używania określonej biblioteki, kontrakty API lub kolejność reagowania na incydenty — łatwiej utrzymywać po przeniesieniu do odpowiedniego dokumentu w docs/, podczas gdy instrukcje główne wskazują jego lokalizację i warunki użycia.

Kiedy potrzebne są reguły dla poszczególnych podkatalogów?

Reguły podkatalogów nie są plikami, które należy mechanicznie dodawać do każdego katalogu. Tam, gdzie wystarczają wspólne reguły główne, osobne pliki mogą zamiast tego zwiększać narzut nawigacyjny i ryzyko konfliktów. Najlepiej zastrzec je dla granic wyraźnie odbiegających od zasad ogólnych lub obszarów, w których błędy mają istotne konsekwencje.

Na przykład src/payments/ może dokumentować sposób wyrażania obliczeń pieniężnych, użycie mocków dla zewnętrznych dostawców płatności oraz konkretne polecenie testów integracyjnych do uruchomienia. infra/ może wymagać planu przed zmianami, kontroli przed ich zastosowaniem oraz ograniczeń dotyczących plików specyficznych dla środowiska, które można modyfikować. generated/ może określać zakaz bezpośrednich edycji oraz wskazywać źródło i polecenie generowania. Celem tych reguł nie jest nadanie katalogowi pozoru wyjątkowości, lecz precyzyjne przekazanie rzeczywistych ograniczeń danego obszaru w kontekście pracy.

W Codex zagnieżdżony plik AGENTS.md obowiązuje poniżej katalogu, w którym się znajduje, a głębiej położone pliki mogą dostarczać bardziej szczegółowych reguł. Claude Code również może kumulować wiele plików CLAUDE.md jako kontekst, dlatego bezpieczniej jest, aby pliki zagnieżdżone dodawały konkretne warunki potrzebne wyłącznie w danym obszarze, zamiast zawierać niejednoznaczne deklaracje odwracające zasady plików nadrzędnych. openai.com↗code.claude.com↗

Na przykład katalog główny może mówić: „Uruchom testy pakietu, który został zmieniony”, a katalog płatności: „Jeśli zmienia się kontrakt płatności, uruchom zarówno testy jednostkowe, jak i integracyjne”. Natomiast zapisanie „Testy muszą być zawsze uruchamiane” w katalogu głównym oraz „Nie uruchamiaj testów” w podkatalogu sprawia, że nie tylko narzędzia, lecz także ludzie nie wiedzą, której reguły przestrzegać.

Jak podzielić .claude/rules/ w Claude Code?

W Claude Code możesz umieścić globalne reguły potrzebne zawsze w CLAUDE.md, a reguły o odrębnych tematach lub zachowaniu zależnym od ścieżki podzielić na małe pliki w .claude/rules/. Pliki reguł można organizować rekursywnie, a warunki ścieżek mogą stosować reguły tylko do określonych plików lub obszarów. code.claude.com↗

Kryterium podziału nie jest liczba plików, lecz spójność reguł, które zmieniają się razem. Na przykład polecenia testowe i zasady dotyczące danych testowych mogą trafić do testing.md; wyjątki dotyczące importów, nazewnictwa i formatowania — do code-style.md; a ograniczenia dotyczące sekretów, zewnętrznych żądań i uprawnień — do security.md. Każdy plik powinien dotyczyć jednego tematu, a jego tytuł powinien jasno wskazywać, kiedy należy go przeczytać.

Zaletą tego podejścia jest to, że niepotrzebne instrukcje nie muszą być stale odczytywane w całości. Przykładowo, jeśli pełne reguły migracji bazy danych pozostają wymieszane z pracą obejmującą wyłącznie edycję dokumentacji, mogą przesłaniać kluczowe instrukcje. Jednak zbyt drobne dzielenie reguł utrudnia znajdowanie ich lokalizacji. Zrównoważone podejście polega na krótkim przedstawieniu głównych grup reguł i ich celów w głównym CLAUDE.md, przy jednoczesnym przechowywaniu faktycznej treści w plikach tematycznych.

Po rozdzieleniu reguł unikaj kopiowania tego samego obowiązku do wielu plików. Kopie z czasem łatwo zaczynają się różnić. Przechowywanie wspólnych zasad w jednym miejscu oraz zapisywanie wyłącznie wyjątków i dodatkowych warunków w plikach specyficznych dla ścieżki zmniejsza liczbę konfliktów.

Jak określać styl kodu?

„Styl kodu przyjazny AI” nie oznacza jednego uniwersalnego wyboru, takiego jak tabulatory zamiast spacji czy programowanie funkcyjne zamiast obiektowego. Ważniejszym kryterium jest to, czy lokalne konwencje repozytorium da się odtworzyć. Przeglądy i utrzymanie stają się łatwiejsze, gdy nowy moduł stosuje wzorce istniejących modułów dotyczące nazewnictwa plików, stylu eksportów, kolejności importów, ścieżek obsługi błędów i struktury testów.

Warto szczególnie dokumentować każdy wybór projektu, który różni się od powszechnych konwencji danego języka. Dokumentacja Claude Code używa specyficznego dla projektu stylu kodu, takiego jak moduły ES lub destrukturyzacja importów nazwanych, jako przykładów. Innymi słowy, zamiast przepisywać każdą domyślną regułę języka, wydajniej jest opisać „co nasz projekt robi inaczej niż domyślnie”. code.claude.com↗

Poniższa tabela przedstawia proste kryteria podejmowania decyzji o wskazówkach dotyczących stylu.

Formatery, lintery i narzędzia sprawdzające typy czynią styl mechanicznie testowalnym, zamiast egzekwować go za pomocą prozy. Dlatego instrukcje powinny określać rzeczywiste polecenia do uruchomienia i oczekiwane postępowanie w razie błędów, zamiast mówić „ładnie formatuj kod”. Dobre praktyki Claude Code również zalecają jasne instrukcje projektu i weryfikowalne przepływy pracy programistycznej. code.claude.com↗

Od jakiej struktury katalogów możesz zacząć?

Poniżej znajduje się przykład, który można wykorzystać przy rozważaniu Codex i Claude Code razem. Nie jest to wymagany standard, lecz jeden z możliwych punktów wyjścia, rozdzielający wspólne instrukcje, szczegółową dokumentację i wyjątki specyficzne dla obszaru.

repo/
├── AGENTS.md
├── CLAUDE.md
├── README.md
├── ARCHITECTURE.md
├── docs/
│   ├── design-docs/
│   ├── product-specs/
│   ├── runbooks/
│   └── generated/
├── src/
│   ├── feature-a/
│   └── feature-b/
├── tests/
└── .claude/
    ├── rules/
    │   ├── testing.md
    │   ├── code-style.md
    │   └── security.md
    └── settings.json

W tym układzie README.md może zawierać informacje potrzebne ludziom do rozpoczęcia pracy z repozytorium, ARCHITECTURE.md może opisywać główne granice i strukturę systemu, a docs/ może przechowywać obszerną, szczegółową wiedzę projektową, produktową i operacyjną. Rzeczywisty układ src/ i tests/ powinien przede wszystkim wynikać z istniejącej struktury projektu. .claude/rules/ to lokalizacja reguł tematycznych lub specyficznych dla ścieżki dla Claude Code. code.claude.com↗

Jeśli obawiasz się wielu plików w katalogu głównym, kluczową kwestią nie jest liczba nazw plików, lecz rozdzielenie odpowiedzialności. Jeśli jeden plik jednocześnie pełni funkcję wprowadzenia do projektu, opisu architektury systemu, instrukcji reagowania operacyjnego, szczegółowych konwencji API i zasad stylu, trudno określić, która informacja jest niezbędna dla bieżącego zadania. Natomiast krótki przewodnik główny wskazujący wymagane szczegółowe dokumenty pozwala współtwórcom zagłębiać się tylko na tyle, na ile jest to konieczne.

Ta sama zasada dotyczy umieszczania plików instrukcji w katalogach specyficznych dla funkcji. Nie dodawaj pliku, jeśli dana funkcja nie ma dedykowanych reguł; dodaj go tylko wtedy, gdy istnieje jasny powód, na przykład obsługa danych wrażliwych lub automatyczny proces generowania. Częste mnożenie plików reguł może komplikować samą strukturę zamiast ją wyjaśniać.

Jak ograniczyć duplikowanie reguł przy używaniu obu narzędzi?

Jedną z opcji jest przechowywanie kanonicznych, wspólnych konwencji programistycznych w AGENTS.md, importowanie ich z głównego CLAUDE.md, a następnie dopisywanie wyłącznie treści potrzebnej Claude Code. Na przykład:

@AGENTS.md

## Claude Code only
- Present a plan before changing `src/payments/`.
- Follow the path-specific rules in `.claude/rules/`.

Taka konfiguracja zmniejsza potrzebę wielokrotnego utrzymywania poleceń testowych, wspólnych reguł nazewnictwa i zasad dotyczących plików generowanych w obu plikach. Jednocześnie zachowuje reguły specyficzne dla Claude Code i konfigurację opartą na .claude/rules/. Jak jednak wskazano wcześniej, Claude Code nie odczytuje automatycznie AGENTS.md jako wspólnych instrukcji, więc musisz faktycznie skonfigurować import lub równoważne połączenie. code.claude.com↗

Miejsce przechowywania wspólnego pliku może zależeć od względnej częstotliwości używania narzędzi przez zespół i od istniejących konwencji repozytorium. Jeśli najczęściej używany jest Codex, AGENTS.md jest łatwym źródłem kanonicznym; jeśli praca skupia się wokół systemu reguł Claude Code, źródłem kanonicznym może być zamiast tego CLAUDE.md. Niezależnie od wyboru kluczowe jest wyznaczenie jednego autorytatywnego oryginału dla każdej reguły i pozostawienie w drugim pliku wyłącznie odwołań lub dodatków specyficznych dla narzędzia.

Najlepiej oddzielać indywidualne preferencje od konwencji zespołowych. Aliasy poleceń w środowisku osobistym, lokalne wybory narzędzi i osobiste nawyki pracy mogą należeć do osobistych plików nadpisujących. Z kolei procedury testowe, ograniczenia bezpieczeństwa i struktura kodu, które powinien znać każdy klonujący repozytorium, powinny pozostać w wersjonowanych instrukcjach projektu. Zarówno Codex, jak i Claude Code obsługują konfiguracje instrukcji na poziomie projektu i użytkownika. openai.com↗code.claude.com↗

Dlaczego polecenia walidacyjne powinny stanowić centralny element instrukcji?

Propozycje lub zmiany agenta programistycznego mogą wyglądać wiarygodnie, lecz nie gwarantują automatycznie poprawności, kompatybilności ani bezpieczeństwa. Wskazówki dotyczące Codex również wyjaśniają, że ludzki przegląd i walidacja wyników nadal są konieczne. openai.com↗

Z tego powodu dobre instrukcje repozytorium wyjaśniają nie tylko „jak kodować”, ale także „jak sprawdzać”. W miarę możliwości wypisz polecenia formatowania, lintowania, sprawdzania typów, testów jednostkowych, testów integracyjnych i budowania w formach, które można rzeczywiście uruchomić. W dużych repozytoriach, gdzie wymaganie pełnej walidacji dla każdego zadania jest niepraktyczne, możesz rozróżnić minimalną walidację według lokalizacji zmiany od warunków wymagających pełnej walidacji.

Przykładowo aktualizacje dokumentacji mogą wymagać tylko sprawdzania linków lub budowania dokumentacji, natomiast zmiany publicznego kontraktu API mogą wymagać zarówno testów jednostkowych, jak i integracyjnych. Zmiany trudne do odwrócenia, takie jak schematy baz danych lub konfiguracja infrastruktury, mogą wymagać dodatkowego etapu przeglądu. Ważne jest nie oczekiwanie, że narzędzie magicznie oceni ryzyko, lecz jawne zapisanie w repozytorium ścieżek walidacji, które zespół już zna.

Kod generowany i artefakty kompilacji powinny być również wyraźnie rozróżniane z perspektywy walidacji. Jeśli plików nie wolno edytować bezpośrednio, udokumentuj ich lokalizację źródłową i procedurę generowania; jeśli edycja artefaktu jest dozwolona, podaj polecenie, które go aktualizuje. Bezpieczniej jest także jasno określić zasadę, że sekrety i osobiste ustawienia specyficzne dla środowiska nie należą do repozytorium, a także wskazać lokalizację plików przykładowych i wymagane kroki walidacji.

Jakie są typowe błędne przekonania i wzorce niepowodzeń?

Pierwszym błędnym przekonaniem jest to, że „więcej instrukcji oznacza lepsze przestrzeganie zasad”. W praktyce długie dokumenty mogą ukrywać najważniejsze reguły. Jeśli instrukcje zbyt się rozrosły, usuń powielone wyjaśnienia, zasady już zautomatyzowane i wyjątki, które przestały obowiązywać, a następnie przenieś szczegółową wiedzę do osobnych dokumentów. code.claude.com↗openai.com↗

Drugie brzmi: „każdy katalog potrzebuje pliku instrukcji”. Zagnieżdżone instrukcje są użyteczne tylko tam, gdzie występują szczególne ograniczenia. Zagnieżdżony plik bez konkretnej treści jedynie dodaje kolejny plik do przeczytania i może sprawić, że jego relacja z regułami nadrzędnymi będzie niejasna.

Trzecie brzmi: „wystarczy dopasować reguły stylu”. Nawet jeśli formatowanie jest spójne, zmiana nie musi być dobra, jeśli nie uruchomiono testów, naruszono zasady domenowe albo bezpośrednio edytowano pliki generowane. Automatyzacja stylu oraz procedury testowania i przeglądu nie są zamiennikami; są zabezpieczeniami działającymi razem.

Czwarte brzmi: „narzędzie samodzielnie rozwiąże sprzeczności w dokumentacji”. Gdy instrukcje nadrzędne i podrzędne albo instrukcje wspólne i specyficzne dla narzędzia są ze sobą sprzeczne, wynik staje się trudny do przewidzenia. Przechowuj tę samą regułę w jednym miejscu i jasno określaj zakres oraz dodatkowe warunki reguł podrzędnych. Ponieważ konfiguracja pamięci Claude Code również obsługuje instrukcje hierarchiczne, projektowanie reguł w sposób unikający konfliktów jest ważne. code.claude.com↗

Na koniec unikaj traktowania pliku instrukcji jako gwarancji jakości. Instrukcje dostarczają kontekstu wspierającego osąd agentów i ludzi; nie są mechanizmami gwarantującymi poprawność, bezpieczeństwo ani przejście testów przez wygenerowany kod. Przegląd zmian i przeprowadzanie niezbędnej walidacji nadal są kluczowe. openai.com↗

Co powinniśmy zastosować najpierw w naszym repozytorium?

Nie musisz od początku przeprojektowywać całej struktury katalogów. Bardziej realistyczne jest rozpoczęcie od niewielkich usprawnień opartych na powtarzających się niejasnościach w obecnym repozytorium. Na przykład, jeśli nowi współtwórcy nie mogą znaleźć polecenia testowego, dodaj je do instrukcji głównych. Jeśli te same błędy wielokrotnie pojawiają się w module płatności, dodaj szczegółowe reguły tylko dla tej ścieżki. Jeśli dokumenty projektowe są wymieszane z kodem i trudno się po nich poruszać, najpierw rozróżnij typy dokumentów w docs/.

Możesz zastosować następującą kolejność oceny:

1. Zidentyfikuj konwencje dotyczące umieszczania plików, nazewnictwa i testowania, które rzeczywiście powtarzają się w aktualnej bazie kodu.
2. Uporządkuj polecenia i warunki błędów dla formatterów, linterów, sprawdzania typów i testów.
3. Zidentyfikuj ograniczenia domenowe, obszary bez możliwości edycji i procedury generowania trudne do zrozumienia z samego kodu.
4. Zapisz zwięźle tylko najważniejszą treść w głównym AGENTS.md lub CLAUDE.md.
5. Dodawaj zagnieżdżone instrukcje lub reguły specyficzne dla ścieżki tylko w wrażliwych obszarach, których ogólne zasady nie mogą wyjaśnić.
6. Wyznacz jedno oryginalne źródło wspólnych reguł i pozostaw w plikach drugiego narzędzia wyłącznie odwołania oraz reguły specyficzne dla narzędzia.
7. Regularnie sprawdzaj, czy instrukcje były pomocne w rzeczywistej pracy oraz czy zawierają niepotrzebne lub sprzeczne stwierdzenia.

W tym procesie nie musisz traktować „łatwości zrozumienia przez narzędzia” i „łatwości utrzymania przez ludzi” jako przeciwstawnych celów. Krótka, precyzyjna dokumentacja, przewidywalne granice modułów i automatycznie wykonywalna walidacja pomagają obu stronom. Z kolei próba rekompensowania samymi plikami instrukcji struktury trudnej do wyjaśnienia nawet ludziom prawdopodobnie sprawi, że dokumentacja stanie się nieporęczna.

Podsumowanie: które konwencje wybrać?

Kluczem do konwencji katalogów i stylów kodu odpowiednich dla Codex i Claude Code nie jest przyjęcie konkretnej modnej struktury. Praktyczne podejście polega na konsekwentnym utrzymywaniu konwencji istniejącej bazy kodu, przechowywaniu krótkiego przewodnika w katalogu głównym, rozdzielaniu szczegółowej wiedzy do odpowiednich dokumentów oraz dodawaniu reguł o wąskim zakresie tylko tam, gdzie są potrzebne.

Dla Codex możesz użyć AGENTS.md; dla Claude Code — CLAUDE.md oraz, w razie potrzeby, .claude/rules/. Jeśli używasz obu narzędzi, wyznacz jedno źródło wspólnych reguł i jawnie połącz wspólny plik w Claude Code, aby ograniczyć duplikację. Przede wszystkim łącz instrukcje z formatterami, linterami, sprawdzaniem typów, testami i przeglądem człowieka. Ponieważ interpretacja instrukcji specyficznych dla produktu może zmieniać się między wersjami, warto utrzymywać reguły niewielkie i jasne, jednocześnie sprawdzając oficjalną dokumentację narzędzi, których faktycznie używasz. openai.com↗code.claude.com↗