Repozytorium może zabraniać agentowi wdrażania na produkcję, pozostawiając mu dostępne polecenie i poświadczenia produkcyjne. Zdanie przekazuje zamiar, ale nie odbiera możliwości. Czteroczęściowy model Tessl pomaga oddzielić taką poradę od procedur i zabezpieczeń o innym sposobie ładowania oraz egzekwowania.
Dzieli pliki zespołu na stały kontekst, reguły ścieżek, wielokrotnego użytku skills i hooki cyklu życia. Konkretne przykłady dotyczą Claude Code, nie uniwersalnego formatu konfiguracji. Pytanie architektoniczne brzmi: jaka wiedza ma być obecna zawsze, jaka procedura tylko w razie potrzeby, a którą niebezpieczną operację trzeba zablokować poza osądem modelu?
Cztery warstwy to różne umowy, nie kopie jednej polityki
CLAUDE.md dostarcza wiedzę potrzebną w wielu zadaniach: polecenia budowania, konwencje katalogów, granice architektury i oczekiwania testowe. Mogą tam trafić menedżer pakietów usługi lub zasada wyłącznie dopisywanych migracji. Plik główny lepiej służy jako przegląd lub indeks niż podręcznik wszystkich wyjątków.
Reguły w .claude/rules/ mogą ładować instrukcje według wzorców ścieżek. Walidacja API nie musi zajmować uwagi przy zmianie dokumentacji. Reguła przekrojowa obejmie handlery albo migracje wielu pakietów bez powielania akapitu w kolejnych katalogach.
Wielokrotnego użytku zdolności pakują dłuższą procedurę w folder z SKILL.md, metadanymi, instrukcjami oraz skryptami lub materiałami pomocniczymi. Przegląd odsyła do procesu wydania, a odpowiednia skill zawiera uporządkowane kontrole. Claude Code najpierw ładuje nazwę i opis; pełna treść trafia do kontekstu, gdy jest przydatna lub jawnie wywołana.
Hooki przypisują zachowanie zdarzeniom cyklu życia przez ustawienia lub powiązaną konfigurację. Kontrola przed narzędziem sprawdza proponowaną operację, po edycji formatuje albo waliduje, a przed zakończeniem wymaga dowodu. To inne zadania niż dodanie instrukcji, którą model ma pamiętać.
Argument własności Tessl polega na przekształceniu wiedzy w wersjonowany zasób repozytorium. Inżynierowie mogą przeglądać różnice, przypisywać opiekunów, oceniać zmiany, cofać złą regułę i dawać nowej sesji ten sam kontekst. Dostawca nadal kontroluje hostowany model i runtime. Własność plików nie oznacza własności wszystkich mechanizmów egzekwowania.
Stały kontekst kosztuje, gdy staje się bazą polityk
Zespoły zaczynają często od jednego pliku, bo od razu poprawia wybór poleceń i nazewnictwo. Następnie kumulują się bezpieczeństwo, wydania, konwencje frontendowe i wyjątki osobiste, aż każda sesja ładuje wszystko. Stały materiał konkuruje ze szczegółami zadania, kodem, wynikami narzędzi i historią rozmowy. Więcej tekstu nie gwarantuje silniejszego przestrzegania.
Cytowane wskazówki Anthropic zalecają CLAUDE.md poniżej 200 wierszy, opiekuna i przegląd jak kodu. Chodzi o uwagę i utrzymanie, nie gwarancję zależną od liczby wierszy. Krótką instrukcję też można źle zrozumieć; ważne ograniczenie nie zyskuje mocy przez przesunięcie wyżej.
Zagnieżdżone pliki instrukcji mogą ładować się przy dostępie do danej części drzewa. Reguły ścieżek rozwiązują inny przypadek: jedno zagadnienie obejmuje wiele katalogów. Oba ograniczają niepotrzebny kontekst, ale trzeba znać konkretne zasady ładowania, dopasowania i pierwszeństwa danego runtime.
Klasyfikacja jest funkcjonalna. Fakty projektu i konwencje wymagające oceny należą do kontekstu, powtarzalna operacja wieloetapowa do skill, a zakazana czynność do uprawnień, blokującej kontroli lub silniejszej izolacji. Długie sesje, sprzeczności i wrogi tekst mogą wpływać na posłuszeństwo. Zdanie w repozytorium dowodzi istnienia polityki, nie skuteczności jej egzekwowania.
Hook może zawsze startować, ale nie zawsze rozstrzyga deterministycznie
Stałe instrukcje, reguły i procedury interpretuje model. Hook jest inny: uruchamia go runtime przy skonfigurowanym zdarzeniu, bez czekania na przypomnienie listy. PreToolUse może sprawdzić wywołanie przed wykonaniem i zwrócić blokadę, gdy polecenie narusza politykę.
O sposobie decyzji rozstrzyga jednak handler. Handlery poleceń wykonują skrypty; warianty promptowe i agentowe mogą korzystać z oceny modelu. Niezawodnie uruchamiany hook nadal może dać probabilistyczny wynik. Warunki sprawdzalne bezpośrednio przez program lepiej realizować kontrolą polecenia niż opinią kolejnego modelu.
Przy plikach generowanych wskazówka tłumaczy zakaz edycji, a świadoma celu kontrola przed akcją odrzuca zapis. Przy wdrożeniu skill opisuje dozwoloną drogę, a uprawnienia lub hooki uniemożliwiają bezpośredni skrót. Wyjaśnienie i bariera wzmacniają się, bo rozwiązują inne problemy.
Uprawnienia określają zgody i odmowy dla narzędzi oraz poleceń; w cytowanym Claude Code pasujące odmowy wygrywają ze zgodami. Hooki badają bogatsze warunki, ale dopuszczone narzędzie lub pozytywny test nie oznacza nieograniczonego systemu operacyjnego. Ograniczone poświadczenia, kontenery, chronione gałęzie i montowania tylko do odczytu nadal mają znaczenie przy poważnych skutkach.
Automatyzacja po edycji wymaga proporcji. Formatowanie lub ukierunkowany walidator mogą być tanie za każdym razem, pełna seria testów może przeszkadzać. Większe kontrole pasują do commitu lub zakończenia. Hook zatrzymania nie może bez końca żądać dalszej pracy bez użytecznej drogi, inaczej bramka zmieni się w kosztowną pętlę.
Płaszczyznę sterowania też przeglądaj jako potencjalnie szkodliwy kod
Hooki są wykonywalną infrastrukturą. Wadliwy skrypt może ujawnić dane, zablokować legalną pracę albo spowalniać każde zdarzenie. Własność repozytorium daje odpowiedzialność za utrzymanie, lecz nie czyni obcej konfiguracji wiarygodną. Zaufanie do workspace, przegląd i izolowane wykonanie pozostają potrzebne.
Możliwość edycji tworzy kolejną granicę. Jeśli agent może zmieniać pliki, które go ograniczają, zwykła poprawka może osłabić sąsiednią regułę lub wyłączyć kontrolę. Krytyczne ustawienia wymagają silniejszej własności i oceny, chronionych gałęzi albo odczytu bez zapisu, nie polegania na chęci zachowania własnych ograniczeń.
Blokada wzorca polecenia może przeoczyć równoważne zadanie pakietu, pośredni skrypt lub inne narzędzie o tym samym skutku. Testy powinny próbować zakazanych działań alternatywnie, nie tylko odtwarzać przykład. Legalna praca też wymaga testów: zbyt szerokie odmowy zachęcają do wyjątków, obejść lub wyłączenia całego mechanizmu.
Niezaufane zgłoszenia, dokumentacja, zależności i wygenerowane artefakty mogą zawierać prompt injection. Model może interpretować je obok instrukcji repozytorium. Deterministyczne uprawnienia i izolacja ograniczają wynikające zdolności; sama proza nie utworzy takiej granicy bezpieczeństwa.
Skills zachowują procedury, jeśli są utrzymywane i uruchamiane
Skills pozwalają przeglądać wiedzę o wydaniach, migracjach, aktualizacjach zależności i incydentach poza czatem pojedynczego inżyniera. Walidator repozytorium wykonuje deterministyczną część, a agent ocenia. Wyszukiwalna baza techniczna zachowuje decyzje i dokumenty wspierające; skill określa zamianę wybranej wiedzy w procedurę.
Obecność nie oznacza aktywacji. Opis musi wyjaśniać zastosowanie, a ocena potwierdzać rzeczywiste ładowanie właściwej procedury. Jawne wywołanie ogranicza niejednoznaczność przy wrażliwej pracy. Polecenia i architektura się zmieniają, więc opiekunowie, przykłady i cykle przeglądu są utrzymaniem, nie kosmetyką.
Powielenie reguły w pliku głównym, zakresowych i kilku skills tworzy konkurujące źródła autorytetu. Jedno główne miejsce każdego faktu oraz odnośniki lub krótkie indeksy ułatwiają późniejsze zmiany. Ustawienia osobiste i zarządzane organizacyjnie nadal mogą kolidować z repozytorium. Operator musi widzieć, które pliki się załadowały i jakie reguły lub prawa wpłynęły na działanie.
Przenośność i zarządzanie trzeba wykazać zachowaniem
Inne agenty mają podobne instrukcje, workflow i kontrolę zdarzeń, ale inne katalogi oraz semantykę. Zainteresowanie produktowe Tessl wielokrotnym użyciem kontekstu nie czyni ścieżek Claude Code standardem. Nawet wspólny Markdown musi zachować uruchamianie, zakres, pierwszeństwo i blokowanie, aby przenośność była znacząca.
Powtarzalne oceny powinny startować w czystym środowisku, dawać te same zadania w wielu próbach i zapisywać konfigurację, decyzje narzędzi i wyniki. Trzeba sprawdzać przestrzeganie, prawidłową aktywację, blokowanie oraz zwykłą udaną pracę. Niezależne powtórzenie znaczy więcej niż przekonująca demonstracja.
Model wzmocniłyby trzy rzeczy: praktyczne oceny instrukcji, formaty zdolności o precyzyjnej semantyce między runtime i interfejsy odróżniające radę, gwarantowane wyzwolenie oraz realną odmowę. Logi mają wyjaśniać zgodę lub odrzucenie. Liczba plików i objętość dokumentacji nie zastąpią wyników.
Użytecznym produktem jest zrozumiała mapa kontroli. Inny inżynier powinien wskazać kontekst decyzji, procedurę pojawiającą się na żądanie i zewnętrzną granicę zatrzymującą poważny błąd. Własne pliki czynią mapę przeglądalną i odtwarzalną. Bezpieczna autonomia nadal zależy od sprawdzonego egzekwowania i otaczającej infrastruktury.
Źródła i dalsza lektura
Cztery warstwy Tessl · Wskazówki Anthropic · Pamięć projektu i ładowanie · Handlery hooków · Uprawnienia narzędzi · Pakowanie i wywoływanie skills · Dalsza lektura: przeszukiwalne bazy techniczne