Najlepsze praktyki CLAUDE.md dla zespołów

Każdy programista korzystający z agenta do kodowania opartego na sztucznej inteligencji po cichu tworzy zbiór zasad. Funkcja „auto memory” w Claude Code zapisuje notatki dotyczące Państwa poprawek w trakcie pracy, Państwa osobisty profil ~/.claude/CLAUDE.mdgromadzi preferencje, których powtarzanie stało się dla Państwa uciążliwe, a kilka osobistych umiejętności rozwija się w oparciu o zadania, które wykonują Państwo co tydzień. Wszystko to ma charakter prywatny. Pamięć automatyczna działa lokalnie na komputerze i jest przypisana do konkretnego repozytorium: agenci Państwa współpracowników nigdy nie mają do niej dostępu.

W ten sposób pięć osób przyswaja tę samą lekcję osobno, każda w swoim prywatnym pliku. Zasady, których Państwa zespół najbardziej potrzebuje, są już spisane. Po prostu nie znajdują się one w żadnym wspólnym miejscu.

We wrześniu w pięcioosobowym gronie przeprowadziliśmy „zbiórkę wspomnień”: zebraliśmy te prywatne zapisy i zastanawialiśmy się, które z nich zasługują na to, by stać się zasadami zespołowymi. Oto, jak to zrobiliśmy, które zasady zostały zatwierdzone, gdzie każda z nich znalazła swoje miejsce oraz jakie wnioski wyciągnęliśmy – w tym również te dotyczące zasad, w których się pomyliliśmy.

Czym jest „żniwo wspomnień”

„Zbieranie wspomnień” to ćwiczenie zespołowe składające się z trzech etapów. Każda osoba eksportuje swoje prywatne wspomnienia dotyczące agentów oraz osobiste zasady. Jedna osoba sprawdzająca grupuje wpisy pochodzące z eksportów wszystkich uczestników. Zasady, które kilka osób zapisało niezależnie od siebie, są proponowane do umieszczenia w plikach wspólnych: w projekcieCLAUDE.md, AGENTS.md, we wspólnej umiejętności lub w procesie zatwierdzania w CI.

Jest to etap konserwacji, który w inżynierii kontekstowej zazwyczaj pomija się. Już wcześniej argumentowaliśmy, że pliki kontekstowe wymagają pętli sprzężenia zwrotnego napędzanej przez agentów, którzy z nich korzystają. „Zbiór” stanowi tę samą pętlę, ale realizowaną w odniesieniu do osób zamiast sesji: jest to etap 4 cyklu życia sprzężenia zwrotnego agenta, ukierunkowany na notatki, które utknęły już w pamięci prywatnej.

Narzędzia służące do tego celu są ograniczone. Spośród dziesięciu narzędzi do kodowania sztucznej inteligencji, które przeanalizowaliśmy, jedynie Devin oferuje pętlę, która monitoruje sesję, proponuje wspólną regułę i oczekuje na zatwierdzenie przez użytkownika. Pozostałe opierają się na plikach tworzonych i zatwierdzanych ręcznie przez użytkowników lub na zestawach instrukcji przekazywanych przez administratora. Żadne z nich nie analizuje prywatnych wspomnień wielu osób w celu znalezienia potencjalnych zasad zespołowych.

Co zrobiliśmy

W dniu 17 września 2026 r. pięciu programistów uruchomiło skrypt eksportujący, stosując go odpowiednio do własnych pamięci Claude Code, osobistych zmiennych globalnych orazCLAUDE.md osobistych umiejętności. Skrypt ten nie przesyła żadnych danych. Każda z tych osób zapoznała się z własnym pakietem danych, usunęła z niego wszystko, co nie powinno zostać przesłane, a dopiero potem go przesłała.

Pięć pakietów zawierało 444 wpisy pamięci, 5 CLAUDE.mdplików globalnych, 13 umiejętności osobistych oraz 194 wiersze opisujące umiejętności zainstalowane w każdym repozytorium. Jeden z recenzentów – agent sztucznej inteligencji współpracujący z człowiekiem – pogrupował wpisy we wszystkich pięciu pakietach i sporządził propozycję dla każdej grupy. 22 września czworo z nas zagłosowało na dwóch stronach recenzji. Zatwierdzenia pojawiły się jako zwykłe pull requesty w trzech repozytoriach: naszym głównym repozytorium produktu, repozytorium gier oraz naszej wspólnej wtyczce umiejętności.

Pakiety znajdują się na gałęzi, która nigdy nie jest scalana. Wyjść mogą jedynie promocje – każda z nich jako oddzielny PR w repozytorium, którym zarządza, i jest weryfikowana tak samo jak każda inna zmiana.

Co decyduje o awansie: należy brać pod uwagę liczbę autorów, a nie liczbę zgłoszeń

Zasada zostaje promowana, gdy co najmniej dwie osoby zapisały ją niezależnie od siebie. Należy liczyć poszczególnych autorów, a nie same wpisy. Ta jedna zasada wykonała większość pracy, a zanim można było jej zaufać, wymagała trzech udoskonaleń.

Proszę wziąć pod uwagę użytkownika intensywnie korzystającego z serwisu. Jeden pakiet zawierał 251 z 444 wpisów, rozmieszczonych w 10 repozytoriach. Wszyscy pozostali wnieśli od 37 do 68 wpisów w 1–4 repozytoriach. Zatem określenie „dwóch autorów” zazwyczaj oznaczało „naszego użytkownika o największej aktywności oraz jeszcze jedną osobę”, a klaster bez tego użytkownika o największej aktywności stanowił rzadszy i mocniejszy dowód. Klastry te oznaczyliśmy oddzielnie.

Jedna osoba to jeden autor. Jeden programista, którego dane zostały wyeksportowane z dwóch komputerów. To jeden autor. Jedna osoba powtarzająca tę samą zasadę trzy razy – to podkreślenie. Potwierdzenie wymaga obecności drugiej osoby.

Wspólne źródła nie są niezależne. CLAUDE.mdPliki globalne obu osób były identyczne na poziomie bajtów w pierwszych czterech sekcjach, ponieważ obie osoby wykorzystały ten sam opublikowany tekst: wytyczne Andreja Karpathy’ego dotyczące kodowania agentów sztucznej inteligencji. Obie osoby powoływały się na ten sam dokument źródłowy, więc uznano to za jedno źródło. Każdy przyszły klaster oparty wyłącznie na tej parze zostanie najpierw zweryfikowany pod kątem zgodności z brzmieniem dokumentu źródłowego.

W celu sklasyfikowania każdego klastra wykorzystaliśmy cztery operatory z ExpeL, metody badawczej dotyczącej agentów uczących się reguł na podstawie doświadczenia: DODAJ nową regułę, POPRZEM tę, która już znajduje się we wspólnych dokumentach, ODRZUĆ tę, z którą dowody są sprzeczne, EDYTUJ tę, która jest zbliżona, ale błędna. Głosowanie na „przeciw” i edycja mają równie duże znaczenie jak dodawanie. Proces zbierania danych, który pozwala jedynie na dodawanie reguł, powoduje jedynie wydłużenie plików kontekstowych, a nie poprawia ich poprawności.

To próg decyduje o tym, co proponuje recenzent, a nie o tym, co zespół może przyjąć. Na drugiej stronie recenzji wymieniono informacje autorstwa pojedynczych autorów, które wydawały się warte opublikowania, a uczestnicy spotkania głosowali nad każdą z nich. Zostały one przyjęte, ponieważ ludzie je przeczytali i zgodzili się z nimi.

Gdzie powinna znajdować się każda reguła

Uzgodnienie zasady to połowa decyzji. Druga połowa to jej poziom: poziom, na którym zasada ta będzie faktycznie odczytywana i stosowana. (W rozdziale naszego przewodnika poświęconym temu, na jakim poziomie powinna znajdować się poprawka, omówiono tę hierarchię w całości.) W przypadku zasad zebranych z innych źródeł korzystaliśmy z następującej tabeli routingu:

Zasada brzmi następująco:	To należy do	Dlaczego
Niezmiennym faktem jest to, że każda sesja w tym repozytorium wymaga	Projekt `CLAUDE.md`	Ładuje się na początku każdej sesji
To samo dotyczy każdego narzędzia opartego na sztucznej inteligencji, z którego korzysta zespół	`AGENTS.md`, sprowadzone z `CLAUDE.md`	Jeden plik, który może odczytać każde narzędzie
Dotyczy wyłącznie części kodu źródłowego	Reguła o zasięgu ścieżki w `.claude/rules/`	Pobiera dane wyłącznie wtedy, gdy agent wykryje pasujące pliki
Procedura stosowana w kilku repozytoriach	Umiejętność w wtyczce współdzielonej	Wtyczki zawierają funkcje, a nie `CLAUDE.md`
Procedura dotycząca konkretnego repozytorium	Umiejętność repo	Ładuje się, gdy wymaga tego zadanie
Szczegóły odniesienia są zbyt długie, by uwzględniać je w każdej sesji	Dokumentacja oraz jednowierszowa wskazówka w `CLAUDE.md`	Dokument, który się nie ładuje, to dokument, którego agent nigdy nie przeczyta
Możliwość sprawdzenia mechanicznego	Reguła Lint, test lub kontrola w ramach ciągłego wdrażania (CI)	Prose ostrzega; czek to powstrzymuje
Informacje na temat działania agenta, np. polecenia git lub zakończenie procesów	Hook w wtyczce współdzielonej	CI nigdy nie widzi działań agenta; hak zatrzymuje polecenie
Państwa preferencje dotyczące własnych narzędzi, maszyn lub budżetu	Państwa osobiste `CLAUDE.md`lub wspomnienie	Nie jest to fakt dotyczący kodu źródłowego

Należy zwrócić uwagę na dwie kwestie. Po pierwsze, wtyczka Claude Code może zawierać umiejętności, agenty i haki, ale nie proceduryCLAUDE.md. Procedury obejmują wiele repozytoriów w ramach jednej wtyczki; stałe reguły należy umieścić w każdym repozytorium, które ich wymaga.

Po drugie, pamięć prywatną należy usunąć dopiero po automatycznym załadowaniu dokumentu docelowego. Jeśli reguła zostanie przeniesiona do dokumentu, który się nie ładuje, agent po prostu o niej zapomina. W przypadku umieszczenia reguły w dokumentach referencyjnych pamięć prywatna zmniejszała się do rozmiarów wskaźnika, zamiast całkowicie znikać.

Jak radzić sobie z sprzecznościami

Wspólne zapisy pamięci są ze sobą sprzeczne. W miarę możliwości należy rozwiązać sprzeczność poprzez określenie zakresu, zastąpić nieaktualną stronę i umieścić rozbieżności dotyczące preferencji w wyraźnie oznaczonym zbiorze spraw nierozstrzygniętych.

Proszę najpierw sprawdzić zakres. Jedna z rozbieżności dotyczyła sposobu konfigurowania zależności w drugiej kopii roboczej repozytorium: dwie osoby sformułowały sprzeczne zasady. Obie były prawdziwe w ich własnych repozytoriach. Późniejsza zmiana we wspólnej umiejętności rozstrzygnęła tę kwestię dla obu stron, a pamięć naszego najbardziej aktywnego użytkownika okazała się nieaktualna, dlatego to właśnie ta wersja powinna zostać zastąpiona, a nie po cichu usunięta.

Zastępuj, nigdy nie nadpisuj. Gdy zmienia się reguła wspólna, proszę dodać nową regułę wraz z datą i zachować starą w sposób umożliwiający jej odczytanie – tak jak zapis decyzji architektonicznej zastępuje wcześniejszą decyzję. Kolejny recenzent będzie mógł sprawdzić, co uległo zmianie i dlaczego.

Proszę pozostawić tę kwestię otwartą. Drugą sprzecznością było to, z jakiego modelu sztucznej inteligencji powinni korzystać podagenci. Dwie osoby opowiadały się za jednym modelem najwyższej klasy dla każdego podagenta; jedna osoba proponowała dobór modeli w zależności od zadania. W głosowaniu padły dwa głosy „do dyskusji” i dwa „zgadzam się”. Kwestia ta pozostała celowo nierozstrzygnięta, ponieważ dotyczy ona tego, ile każda osoba jest skłonna wydać ze środków własnych, a nie faktu związanego z kodem źródłowym. Pozostaje to w prywatnych zasadach każdej osoby.

Co odkryto podczas żniw

Z pierwszej strony przeglądu przyjęto piętnaście zgłoszeń: 11 dotyczących naszego głównego repozytorium produktów (z czego dwa dotyczyły również repozytorium gier), trzy dotyczące wtyczki „shared skills” oraz jedno dotyczące poprawki eksportera własnego narzędzia „harvest”. Kolejne siedemnaście propozycji zostało zatwierdzonych z drugiej strony: fakty autorstwa jednego autora, które grupa zgodziła się udostępnić, oraz dwa klastry, które podczas pierwszego liczenia zostały błędnie zarejestrowane jako autorstwa jednego autora. Na drugiej stronie jedna propozycja została odrzucona w głosowaniu, trzy odłożono do dalszej dyskusji lub w celu znalezienia dla nich bardziej odpowiedniego miejsca, a trzy zostały zatwierdzone, ale wymagają kodu lub umiejętności, a nie jedynie wpisu w dokumentacji. Kwestia dotycząca modelu pozostała otwarta.

Najczęściej powtarzającym się zagadnieniem były komentarze. Trzech autorów, z których jeden odnotował to czterokrotnie: komentarze przedstawiają trwałe fakty dotyczące kodu; nigdy nie opisują one samej zmiany ani jej historii. Jeden z autorów zauważył, że najczęściej winowajcami są podagenci.

Najszersza z nich dotyczyła dowodów. Czterech z pięciu autorów sformułowało wersję zasady: „zweryfikuj, zanim sformułujesz twierdzenie; nieudane poszukiwanie nie stanowi dowodu na brak”. Twierdzenia recenzentów mają charakter hipotez, a brak możliwości odtworzenia błędu nie dowodzi, że nie może on wystąpić. Była to zasada najbliższa wspólnej zasadzie obowiązującej w zespole, jednak nie została nigdzie spisana ani udostępniona.

Inny zestaw przypadków, opisany przez dwóch autorów, dotyczył nieaktualnego stanu repozytorium Git: lokalnej gałęzi znacznie opóźnionej względem zdalnej oraz wyszukiwania przeprowadzonego na niewłaściwym kopii roboczej. Każdy z pięciu odnotowanych incydentów skutkował pewnym, ale błędnym stwierdzeniem, które znalazło odzwierciedlenie w komunikacie zatwierdzenia lub opisie zgłoszenia PR.

W ramach tej akcji korygowano nie tylko brakujące wytyczne, ale także te zawierające błędy. Trzy zgłoszenia dotyczyły wytycznych, które już posiadaliśmy, i miały charakter wezwań do „GŁOSOWANIA PRZECIW” lub „EDYCJI”:

W naszym wspólnym komunikacie poinformowanoAGENTS.md agentów, aby przylint:fix zmianie reguł lintowania przeprowadzali operację obejmującą całe repozytorium. Trzy osoby niezależnie od siebie ostrzegały przed takim postępowaniem: repozytorium nie przechodzi pomyślnie lintowania w stanie początkowym, więc poprawka obejmująca całe repozytorium sprawia, że Państwa różnice zostają zagubione wśród niepowiązanych zmian formatowania.
Wspólna funkcja, która rzekomo przechodzi na API w przypadku niepowodzeniagh pr edit. Nie kończy się ona jednak niepowodzeniem: wyświetla komunikat o charakterze niekrytycznym, zwraca kod wyjścia 0 i pozostawia pull request bez zmian. Mechanizm awaryjny oparty na niepowodzeniu, które nigdy nie występuje, nigdy nie zostaje uruchomiony. Trzech autorów napotkało tę sytuację w trzech repozytoriach.
W istniejącym ostrzeżeniu zawartym w dokumentacji naszego agenta pewien błąd w bazie danych został określony jako „bezpieczny”, ponieważ powoduje natychmiastowy błąd. Trzy osoby popełniły ten błąd w trzech różnych tabelach. W jednym przypadku błąd ten przeszedł proces weryfikacji, przeszedł testy CI i spowodował awarię dopiero w czasie wykonywania.

Niektóre uzgodnione zasady powinny zostać uwzględnione w ramach automatycznej kontroli. Powyższe ostrzeżenie dotyczące bazy danych można sprawdzić automatycznie: test odczytujący schemat spowodowałby zakończenie działania całej klasy, podczas gdy dokumentacja jedynie o tym ostrzega. Stwierdzono, że zasada „Nigdy nie edytuj ręcznie wygenerowanego pliku schematu” jest prawdziwa, jednak pozostawiono ją w zawieszeniu, ponieważ sformułowanie tekstowe nie jest właściwym sposobem jej egzekwowania. Dwa inne uzgodnione punkty zostały już opisane jako procedury krok po kroku, co czyni je umiejętnościami. Kilka pozycji opuszczono głosowanie jako zgłoszenia, a nie jako dokumentacja.

Zasada może stanowić domyślne zachowanie, a mimo to wymaga sformułowania. Dwie osoby niezależnie od siebie zapisały: „nigdy nie należy dokonywać commitów ani wysyłać zmian, chyba że zostanie o to poproszone”. Jedna z nich ujęła to najlepiej: „zapisanie plików nie oznacza zgody na ich zatwierdzenie”. Każdy użytkownik powinien już zachowywać się w ten sposób. Dwie osoby zapisały to, ponieważ sytuacja ta i tak wciąż się powtarzała, co stanowi argument przemawiający za wyraźnym sformułowaniem tej zasady.

W procesie zbierania wykryto błąd. Każdy pakiet posiadał znacznik wersji, dzięki czemu mechanizm weryfikacyjny odmawiał porównywania pakietów utworzonych na podstawie różnych reguł zbierania. Znacznik ten pochodził z wersji wtyczki, a nie z eksportera. Wszystkie pięć pakietów zostało utworzonych za pomocą skryptów identycznych pod względem bajtów, a mimo to opatrzonych trzema różnymi wersjami. Mechanizm zabezpieczający nigdy nie zadziałałby w przypadku rzeczywistej zmiany reguł, natomiast uruchamiałby się przy każdej niepowiązanej aktualizacji wtyczki. Ta poprawka była jedną z piętnastu.

Jak często należy to uruchamiać

Pierwsze podsumowanie jest najbardziej pracochłonne: miesiące prywatnych notatek, poruszanych podczas jednej, ściśle wyznaczonej sesji. Następnie należy wprowadzić pięciominutową kontrolę na stojąco podczas regularnego spotkania synchronizacyjnego zespołu: czy pojawiło się coś nowego, co zapisała więcej niż jedna osoba?

Pięć rodzajów awarii, które należy uwzględnić przy projektowaniu:

Tylko do zapisu: reguły są promowane, a nikt nie sprawdza, czy zachowanie agenta uległo zmianie.
Nieaktualna i bez właściciela: reguła współdzielona przetrwała dłużej niż kod, który opisuje.
Promowane na zasadzie „n=1”: zdecydowana opinia jednej osoby staje się zasadą obowiązującą w zespole, ponieważ to właśnie ona jako pierwsza ją sformułowała.
Jeden dokument zawierający cztery rodzaje treści: stałe zasady, procedury, materiały referencyjne oraz historię – wszystko w jednym pliku, którego nikt nie czyta od początku do końca.
Wyprowadzona do tego stopnia, że stała się bezużyteczna: zasada uogólniona tak daleko od zdarzenia, które ją spowodowało, że nie wskazuje już podmiotowi, jak ma postępować.

Co zmienilibyśmy następnym razem

Porównanie naszego procesu z narzędziami, które uczą się samodzielnie, ujawniło cztery niedociągnięcia. Przed kolejnym uruchomieniem wprowadzamy poprawki dotyczące każdego z nich do zbioru danych.

Zasady dotyczące działań samego agenta wymagają zastosowania haka. Dwie z naszych promocji dotyczyły tego, co robi agent, a nie tego, co przewiduje kod: podagenci zatwierdzający zmiany w niewłaściwej gałęzi oraz ogólne zakończenie procesu, które powodowało zamknięcie powłoki, w której był on uruchomiony. CI nigdy nie wykrywa żadnego z tych przypadków. Hook może zatrzymać polecenie przed jego wykonaniem, a wspólna wtyczka przenosi je na każdą maszynę, na której zostanie zainstalowana.

Zasada, o której ludzie wciąż na nowo się przekonują, nie działa. Jest to opisany powyżej tryb awarii typu „tylko do zapisu”, który można zmierzyć za pomocą zbierania danych. Jeśli zasada została ostatnio promowana, a użytkownicy nadal zapisywali ją w swojej prywatnej pamięci, oznacza to, że wspólna linia nie działa. Jest to sygnał, aby przenieść ją z tekstu do haka lub sprawdzania.

Przed zatwierdzeniem pamięci należy sprawdzić, czy nadal jest ona aktualna. Jedna z pamięci zawierała ostrzeżenie dotyczące aktywnego błędu, który został już naprawiony. Gdyby została zatwierdzona, wszyscy otrzymaliby fałszywe ostrzeżenie. Każdy element, który odnosi się do pliku, funkcji lub błędu, zostanie najpierw zweryfikowany pod kątem zgodności z aktualnym kodem.

W zestawieniu uwzględniono wyłącznie to, co uczestnicy zapisali. Liczba wpisów wahała się od 37 do 251 na osobę, co mówi więcej o tym, kto sporządza notatki, niż o tym, kto napotyka problemy. Następnym razem każda osoba może najpierw poprosić swojego agenta o przeczytanie transkrypcji jej ostatnich sesji i sporządzenie listy poprawek, których nie obejmuje pamięć. To ona decyduje, które z nich zachować. Transkrypcje te nie trafiają do wspólnego zbioru.

Rozważaliśmy również powierzenie całej pracy agentowi: monitorowanie sesji, tworzenie własnych reguł i ich automatyczne wdrażanie. Niektóre narzędzia już działają w ten sposób, a nasza mapa pętli sprzężenia zwrotnego agentów zawiera jedno z nich. Rozwiązanie to sprawdza się dobrze w przypadku konfiguracji przeznaczonej dla jednej osoby. Jednak w przypadku reguł, na których opiera się cały zespół, nadal chcemy, aby pracownicy zapoznawali się z każdą z nich i głosowali nad nimi.

Proszę uruchomić jeden ręcznie

Nie potrzebują Państwo specjalnych narzędzi. Nasz eksport polegał na użyciu niewielkiego skryptu, ale każdy etap można wykonać ręcznie:

Eksportuj w trybie prywatnym. Każda osoba powinna skopiować swój folder pamięci automatycznej (w Claude Code: ~/.claude/projects/<project>/memory/), swoje oraz~/.claude/CLAUDE.md wszelkie osobiste umiejętności do jednego folderu przeznaczonego dla danej osoby.
Przed udostępnieniem należy usunąć niepotrzebne informacje. Każda osoba usuwa wszystko, co nie powinno zostać udostępnione: dane uwierzytelniające, dane klientów, wszelkie informacje dotyczące konkretnych współpracowników. Żadna treść nie opuszcza systemu bez uprzedniego przejrzenia jej przez właściciela.
Grupowanie według znaczenia. Recenzent – czy to osoba, czy automat – grupuje wpisy, które wyrażają tę samą treść innymi słowami, i odnotowuje, kto jest autorem każdego z nich.
Proszę policzyć unikalnych autorów. Kandydatem jest sytuacja, w której występują co najmniej dwaj niezależni autorzy. Proszę połączyć urządzenia należące do jednej osoby, pominąć wspólny tekst pochodzący z wyższych poziomów struktury oraz odnotować, które klastry pozostają bez udziału Państwa najaktywniejszego użytkownika.
Klasyfikacja i kierowanie. Proszę oznaczyć każdą pozycję jako ADD, UPVOTE, DOWNVOTE lub EDIT, a następnie przypisać jej miejsce docelowe zgodnie z powyższą tabelą kierowania.
Proszę wymienić sprzeczności osobno. W miarę możliwości proszę je rozstrzygnąć na podstawie zakresu; pozostałe proszę pozostawić nierozstrzygnięte i wyraźnie to zaznaczyć.
Niech zgromadzeni zagłosują. Proszę umieścić propozycje na jednej stronie, a informacje dotyczące jednego autora na drugiej, a następnie wspólnie podjąć decyzję.
Każdą aktualizację należy traktować jako odrębną akcję PR w odniesieniu do repozytorium, którego dotyczy. Proszę nie umieszczać surowych pakietów w gałęzi głównej.

Najczęściej zadawane pytania

Czym jest „zbieranie wspomnień”?

„Zbiórka pamięci” to praktyka zespołowa stosowana w przypadku agentów programowych opartych na sztucznej inteligencji: każdy programista eksportuje pamięć swojego prywatnego agenta oraz osobiste reguły, a jeden recenzent grupuje te wpisy pochodzące z eksportów wszystkich uczestników; reguły, które kilka osób opracowało niezależnie, są następnie przenoszone do plików wspólnych, takich jak CLAUDE.mdlub AGENTS.md. Jest to etap konserwacji na poziomie zespołu w ramach inżynierii kontekstowej.

Ile osób musi wyrazić zgodę, aby dana zasada została wprowadzona do pliku CLAUDE.md?

Korzystamy z usług co najmniej dwóch niezależnych autorów. Należy liczyć poszczególne osoby, a nie wpisy: osoba, która trzykrotnie sformułowała tę samą zasadę lub dokonała eksportu z dwóch urządzeń, nadal liczy się jako jeden autor. Dwie osoby, które skopiowały ten sam opublikowany tekst, również nie są niezależne. Próg ten decyduje o tym, co zostaje zgłoszone; zespół nadal głosuje nad każdym awansem.

Co należy traktować jako część zespołu CLAUDE.md, a co jako osobistą pamięć?

Należy pamiętać, że wszystkie elementy zawarte w tym repozytorium muszą znajdować się w projekcieCLAUDE.md, ponieważ są one ładowane automatycznie. Procedury należy umieszczać w sekcji „umiejętności”, szczegółowe informacje referencyjne – w sekcji „dokumentacja” wraz z odnośnikiem, a wszystko, co może sprawdzić maszyna, – w regule lintowej lub teście. Preferencje dotyczące Państwa własnych narzędzi, sprzętu lub budżetu pozostają sprawą osobistą.

Czy zasady dotyczące zespołu powinny znaleźć się w pliku CLAUDE.md czy w pliku AGENTS.md?

Zasady, których powinno przestrzegać każde narzędzie oparte na sztucznej inteligencji, należy umieścić w AGENTS.md; instrukcje dotyczące konkretnie Claude’a należy umieścić w CLAUDE.md. Claude Code może odczytywać pliki bezpośrednioAGENTS.md lub poprzez import@AGENTS.md, dzięki czemu jeden plik może służyć wszystkim narzędziom wykorzystywanym przez Państwa zespół.

Co należy zrobić, gdy relacje dwóch programistów są ze sobą sprzeczne?

Proszę najpierw sprawdzić zakres: obie wersje mogą być poprawne w różnych repozytoriach, a późniejsza zmiana narzędzia mogła już tę kwestię rozstrzygnąć. Jeśli jedna ze stron jest nieaktualna, proszę ją zastąpić, a nie nadpisywać. Jeśli rozbieżność dotyczy raczej preferencji niż faktycznego stanu kodu źródłowego, proszę pozostawić ją nierozstrzygniętą i uwzględnić w prywatnych zasadach każdej osoby.

Jak często zespół powinien przeprowadzać operację „memory harvest”?

Proszę przeprowadzić jedną sesję o ograniczonym czasie trwania w celu wyczyszczenia zaległości, a następnie podczas regularnych spotkań synchronizacyjnych zespołu przeprowadzać pięciominutową kontrolę na stojąco w celu zidentyfikowania nowych kandydatów. Pierwsza selekcja jest najbardziej kosztowna; później liczba kandydatów powinna być niewielka.

Niech to będzie decyzja zespołowa

W ramach procesu gromadzenia wiedzy zespół decyduje, które zasady staną się wspólne; recenzent jedynie przedstawia propozycje. Eksport, grupowanie i zliczanie można w całości zautomatyzować. Głosowanie nie może i nie powinno być zautomatyzowane. To, które zasady są wiążące dla wszystkich, które pozostają osobiste, a które kwestie sporne pozostają otwarte, to decyzje należące do osób, które będą się nimi kierować. To samo stwierdzenie zawarte jest w raporcie „Istnieje, ale pomieszczenia nie ma”: zbiorczy obraz ma sens dopiero wtedy, gdy osoby odpowiedzialne za poprawki podejmą wspólną decyzję.

Jest to retrospektywa oparta na różnych źródłach danych. Kiedy nasi agenci AI zgłaszali własne punkty do omówienia podczas retrospektywy, dane pochodziły z ich sesji. Tym razem pochodziły one z naszych prywatnych notatek, a system „Room” wykonał tę samą pracę: odczytał wzorzec, wybrał poziom szczegółowości i przypisał właściciela do każdego punktu. Jeśli Państwa zespół organizuje już regularne retrospektywy, „zbieranie wspomnień” może stanowić jeden z punktów porządku obrad. Pełny opis tej praktyki znajduje się w naszym przewodniku po retrospektywach agentów sztucznej inteligencji.

Przeprowadzili Państwo własną analizę danych lub uważają Państwo, że nasz próg jest nieprawidłowy? Prosimy o kontakt: ai-discussion@teamretro.com.