Tak mam ustawionego Codexa. Możesz trochę zgapić.

Problem, który rozwiązuje / interpretacja: Taka kolejność pomaga ocenić rozwiązanie według skutku, a nie według liczby elementów lub szybkości napisania. Wymóg nazwania założeń pozwala rozpoznać, co wymaga potwierdzenia.

Kiedy Codex używa: Przy wyborze zakresu, proponowaniu rozwiązania, rozstrzyganiu konfliktu instrukcji i pytaniu o doprecyzowanie. Pyta tylko wtedy, gdy od odpowiedzi rzeczywiście zależy zakres, cel, konto, ryzyko albo działanie zewnętrzne.

Co czytelnik dopasowuje: Kolejność priorytetów może odzwierciedlać własną pracę, ale warto zachować kryterium poprawności i sprawdzalności. Szczegóły jednego produktu lub repozytorium należą do jego lokalnego AGENTS.md.

Efekt: Codex może dobrać najmniejszy sensowny zakres, a Ty wiesz, jakie założenia wymagają potwierdzenia.

Problem, który rozwiązuje / interpretacja: Nie trzeba ponownie pytać o każdą zwykłą naprawę, nieudany test lub uwagę z przeglądu. Ponowna decyzja jest potrzebna dopiero przy zmianie celu, zakresu, kryteriów odbioru, istotnego ryzyka albo osobnej bramce człowieka. Blokada sandboxa, konta lub polityki pozostaje blokadą tego konkretnego mechanizmu — nie wolno jej obchodzić ani przedstawiać jako ogólnej potrzeby ponownej zgody.

Kiedy Codex używa: Przed zmianą w środowisku współdzielonym i przez cały zatwierdzony etap, gdy wykonuje naprawy, testy, regresje, niezależny przegląd, synchronizację dokumentacji lub odwracalne poprawki zatwierdzonego lokalnego demo.

Co czytelnik dopasowuje: Wpisz własne bramki, źródło kontraktu i działania zewnętrzne. Nie zamieniaj opisu pakietu w uniwersalne upoważnienie.

Efekt: masz jedną, sprawdzalną granicę pracy, a Codex może dokończyć zwykłe kroki bez mnożenia pytań.

Problem, który rozwiązuje / interpretacja: Delegowanie nie przenosi odpowiedzialności za całość. Krótki, samowystarczalny brief ogranicza zgadywanie, nakład pracy oraz ryzyko, że kilka osób zmieni ten sam obszar bez koordynacji.

Kiedy Codex używa: Gdy podzadanie ma wyraźny wynik i można je wykonać niezależnie: analiza pliku, mechaniczna zmiana, prosty refaktor, test, log lub dokumentacja. Drobne zadanie prowadzący wykonuje sam; zajmuje się też architekturą i trudnym debugowaniem. Wybiera obsługiwany i dozwolony model oraz poziom rozumowania stosownie do potrzeb i ryzyka zadania. Agent pomocniczy dostaje domyślnie brak historii oraz samowystarczalny brief: zadanie, kontekst, pliki, ograniczenia, wynik, granice bezpieczeństwa, znane ustalenia i kryteria odbioru. Pełną historię przekazuje się tylko z uzasadnionej potrzeby.

Co czytelnik dopasowuje: Nazwy modeli i domyślne poziomy rozumowania trzymaj w konfiguracji, nie w tej regule. Dostępny model pomocniczy, poziom rozumowania i mechanizm delegacji dopasuj do własnego środowiska; regułę można usunąć, gdy środowisko nie obsługuje agentów pomocniczych. Zachowaj wymagane elementy briefu i niezależność wymaganej recenzji.

Efekt: pomocniczy agent dostaje zamknięte zadanie, a odpowiedzialność za całość pozostaje po stronie prowadzącego.

Problem, który rozwiązuje / interpretacja: Framework nie jest źródłem prawdy o komendach ani architekturze danego repozytorium. Stopniowe czytanie ogranicza pracę w złym miejscu i nie zaciera ważnych informacji w długich logach.

Kiedy Codex używa: Przed kodowaniem, przy diagnozie, doborze testu oraz podczas wyszukiwania dokumentacji i historii decyzji. zwykłe pliki Markdown nie są automatycznie ładowane jako instrukcje: trzeba je wskazać, znaleźć albo otworzyć, gdy są potrzebne. Sprawdza też uprawnienie przed działaniem wymagającym bramki i nigdy nie traktuje podsumowania jako zgody na kolejną akcję. Ogranicza wynik narzędzi, ale nie obniża sztucznie jakości modelu ani okna kontekstu tylko po to, aby oszczędzić tokeny.

Co czytelnik dopasowuje: W projektowym pliku wpisz prawdziwe komendy, strukturę, źródła prawdy i kryteria odbioru. Globalnie zostaw metodę szukania i zasadę, by nie zgadywać na podstawie samego stosu technologicznego.

Efekt: zmiana opiera się na rzeczywistych zasadach projektu i ma właściwe sprawdzenie.

Problem, który rozwiązuje / interpretacja: Checkpoint jest krótkim stanem operacyjnym dla kolejnej sesji lub osoby. Nie tworzy nowego uprawnienia i nie powinien zmienić się w drugi dziennik po każdej małej korekcie.

Kiedy Codex używa: Na granicy etapu, przed handoffem albo przed przełączeniem projektu. Jeśli nie ma planu lub zapis nie jest dozwolony, przekazuje ten stan w zadaniu.

Co czytelnik dopasowuje: Użyj jednego istniejącego miejsca na plan i nazwij format odpowiedni dla zespołu. Nie usuwaj informacji o niezatwierdzonych zmianach, dowodach i zgodach.

Efekt: następna osoba lub sesja może bez zgadywania sprawdzić stan i wykonać kolejny krok.

Problem, który rozwiązuje / interpretacja: Ustala granicę między szybkim dopracowaniem widoku a pełną finalizacją. Akceptacja nazwanego etapu uruchamia czynności końcowe tego etapu, ale nie daje sama z siebie prawa do merge’a, publikacji lub wdrożenia.

Kiedy Codex używa: Przy decyzji o nowym interfejsie lub technologii oraz podczas demo. Zmiany ryzykowne dla backendu, logiki, danych, uprawnień lub migracji sprawdza od razu. Zwroty „OK, jest dobrze”, „zatwierdzam demo” i „finalizuj” rozpoczynają finalizację nazwanego etapu: testy, regresje, porządki, recenzję, kontrolę konfliktów i dokumentację. Nie są zgodą na merge, publikację ani wdrożenie.

Co czytelnik dopasowuje: Wskaż własne źródło wskazówek UX i słowa, których zespół używa do zatwierdzania etapu. Nie zamieniaj ich w ogólną zgodę na zewnętrzne działania.

Efekt: małe poprawki są szybkie, a działania zewnętrzne nadal wymagają osobnej zgody.

Problem, który rozwiązuje / interpretacja: Jedna kontrola nie odpowiada na wszystkie pytania: test, odczyt artefaktu, badanie źródeł i przejście przez prawdziwy interfejs dają różne dowody. Wymagana recenzja nie może zostać zastąpiona samooceną autora.

Kiedy Codex używa: Przy sprawdzaniu faktów zmiennych w czasie, wyborze testów, finalizacji istotnej zmiany oraz doborze narzędzia. Preferuje narzędzia projektu, potem wyspecjalizowane API i konektory, a interfejs przeglądarkowy lub kontrolę komputera tylko w opisanych przypadkach.

Co czytelnik dopasowuje: Dodaj własne repozytoryjne kontrole tylko do pliku projektu. Zachowaj informowanie o rozbieżnościach, niezweryfikowanych elementach i ryzykach; jeżeli niezależna recenzja jest wymagana, wskaż jej brak zamiast deklarować techniczną akceptację.

Efekt: wynik ma dowody dopasowane do ryzyka, a niepewność i braki są widoczne.

Problem, który rozwiązuje / interpretacja: Prawidłowe polecenie wykonane na niewłaściwym koncie lub w niewłaściwym projekcie nadal jest błędem. Ogólne przyzwolenie i milczenie nie wyznaczają celu operacji nieodwracalnej, produkcyjnej, finansowej, regulowanej, wrażliwej dla bezpieczeństwa lub komunikacyjnej.

Kiedy Codex używa: Przed podłączeniem, rozłączeniem, zmianą lub przełączeniem konta bądź konektora oraz przed działaniem w systemie zewnętrznym. Najpierw stosuje inspekcję tylko do odczytu, aby ustalić aktywny kontekst, usługę, konto, workspace, projekt i repozytorium. Mapa routingu pozostaje w prywatnej wersji i przed wspólną lub zewnętrzną akcją musi zostać sprawdzona.

Co czytelnik dopasowuje: Prywatną mapę kont uzupełnij wyłącznie w niepublicznej kopii. Zastąp znaczniki własnymi tożsamościami, ale nie przenoś ich do artykułu, szablonu lub współdzielonego repozytorium.

Efekt: działanie trafia do właściwego kontekstu i nie wykorzystuje prywatnych danych bez zgody.

Problem, który rozwiązuje / interpretacja: Zgoda na odczyt, diagnozę lub plan nie jest zgodą na zmianę. Wspólne zasoby mają właścicieli, odbiorców i zależności, dlatego odrębnie chroni się m.in. przed commitem, publikacją, wiadomością czy zmianą infrastruktury bez dokładnej autoryzacji.

Kiedy Codex używa: Za każdym razem przed edycją środowiska firmowego lub współdzielonego oraz przed czynnością zewnętrzną dotyczącą takiego środowiska. Po zgodzie wykonuje najmniejszą zmianę, którą można przejrzeć i prześledzić.

Co czytelnik dopasowuje: Nazwę listy, proces zatwierdzania i definicję środowiska zespołowego dostosuj do organizacji. Zachowaj zakaz pozostawiania prywatnych instrukcji AI, pamięci, eksperymentów, helperów i tymczasowych artefaktów, jeśli nie są elementem zatwierdzonej zmiany.

Efekt: zespół widzi plan zmiany przed edycją i może bezpiecznie ją ocenić.