Dostarcz agentowi przydatny kontekst repozytorium

Zacznij od bieżącej kopii repozytorium

Agent musi wiedzieć, które repozytorium i branch zmienia. Musi też wiedzieć, czy katalog roboczy zawiera niezwiązane zmiany. Te fakty wpływają na bezpieczny zakres edycji i interpretację końcowego diffu.

Poproś agenta o sprawdzenie instrukcji projektu i konfiguracji pakietu przed implementacją. Polecenie zapamiętane z innego repozytorium może tutaj nie działać. Znana nazwa frameworka nie potwierdza zainstalowanej wersji ani konwencji projektu.

Dla małej zmiany przekaż odpowiedni moduł, kod wywołujący, testy i decyzję architektoniczną. Dodawaj informacje wtedy, gdy badanie wykaże konkretną potrzebę.

Zapisuj trwałe reguły w instrukcjach repozytorium

Plik instrukcji może opisywać wspierane polecenia, granice modułów, wymagania przeglądu i działania wymagające decyzji właściciela. Konwencja AGENTS.md daje narzędziom programistycznym rozpoznawalne miejsce na te informacje. Obsługa i pierwszeństwo instrukcji mogą się różnić, więc sprawdź zachowanie swojego narzędzia.

Trwałe reguły projektu trzymaj w repozytorium. Bieżące zadanie opisz w jego zleceniu. Nie zamieniaj pliku instrukcji w historię wszystkich rozmów ani listę tymczasowych planów.

Przydatna instrukcja brzmi: „Uruchom testy integracyjne autoryzacji, gdy trasa zmienia zasady dostępu”. Niejasna instrukcja mówi: „Zawsze uważaj na bezpieczeństwo”. Pierwsza określa warunek i działanie, które recenzent może sprawdzić.

Porównuj instrukcje z kodem

Instrukcje dezaktualizują się po zmianie poleceń, katalogów lub architektury. Jeśli przewodnik wskazuje brakujący skrypt, sprawdź konfigurację pakietu. Jeśli dokument mówi, że usługa ma dostęp tylko do odczytu, sprawdź uprawnienia, zanim na tym polegasz.

Zapisz sprzeczność. Użyj bezpośrednich dowodów z aktualnej wersji, aby zrozumieć zachowanie implementacji. Nie odrzucaj po cichu świadomie przyjętej polityki tylko dlatego, że stary kod ją narusza. Polityka i bieżące zachowanie odpowiadają na różne pytania.

Przykładowo przewodnik może zabraniać bezpośredniego zapisu na wspólny branch, chociaż stary skrypt nadal to robi. Właściwą reakcją jest zachowanie polityki i poprawienie skryptu. Istniejący kod nie daje pozwolenia na powtórzenie zabronionego działania.

Dbaj o przydatność i bezpieczeństwo kontekstu

Całe repozytorium może zawierać dane uwierzytelniające, prywatne dane testowe, eksporty klientów i stare logi wsparcia. Dostęp do repozytorium nie oznacza automatycznie, że każdy plik można przekazać usłudze modelu.

Używaj zatwierdzonych narzędzi i zasad przetwarzania danych. Wyklucz sekrety z kontekstu. Tam, gdzie to możliwe, zastępuj przykłady klientów wymyślonymi danymi. Sprawdzaj podłączone narzędzia, nie tylko przesłane pliki. Konektor wyszukiwania może pobrać informacje nieobecne w początkowym prompcie.

Instrukcja repozytorium „nie czytaj sekretów” jest przydatną wskazówką. Nie zastępuje ograniczenia dostępu do magazynu sekretów i katalogów z danymi wrażliwymi.

Zostaw przydatny zapis dla kolejnej osoby

Po zakończeniu opisz w pull requeście zmienione zachowanie, weryfikację i nierozstrzygnięte ograniczenia. Aktualizuj trwałą dokumentację projektu, gdy zmienia się wspierany sposób pracy. Nie kopiuj całej rozmowy z agentem do repozytorium.

Zapis powinien pozwalać przyszłej osobie utrzymującej system powtórzyć pracę bez odtwarzania długiej rozmowy. Linkuj do dokumentów kanonicznych i zachowuj jeden autorytatywny opis każdej trwałej reguły.

Dobry kontekst ogranicza powtarzanie tych samych badań. Ułatwia też wykrywanie błędów, ponieważ oczekiwane zachowanie i działające polecenia są jasno określone.