Zabezpieczenia agentów programistycznych Tessl zamieniają pliki repozytorium w warstwę kontroli

Tessl opublikował czteroczęściowy framework do kontrolowania agentów programistycznych za pomocą plików należących do zespołów, mimo rosnącej zależności od hostowanych modeli. Zabezpieczenia agentów programistycznych Tessl rozdzielają trwałe instrukcje, reguły zależne od ścieżki, wielokrotnego użytku możliwości i automatyczne hooki. To rozróżnienie ma znaczenie, ponieważ pisemna prośba i egzekwowane ograniczenie nie zapewniają takiej samej ochrony.

Framework wykorzystuje CLAUDE.md, .claude/rules/, pliki możliwości w .claude/ oraz hooki połączone przez konfigurację Claude Code. Każda warstwa obsługuje inny moment w przepływie pracy agenta. Łącznie przenoszą wiedzę operacyjną z tymczasowych rozmów do wersjonowanych zasobów repozytorium.

Główny konflikt nie dotyczy Tessl kontra inne narzędzie dla deweloperów. Chodzi o kontekst doradczy kontra deterministyczne egzekwowanie. Model może źle zrozumieć lub pominąć tekst, podczas gdy hook może odrzucić działanie przed jego wykonaniem. Zespoły muszą teraz zdecydować, które oczekiwania należą do promptów, a które wymagają wykonywalnych mechanizmów kontroli.

Zabezpieczenia agentów programistycznych Tessl dzielą jeden prompt na cztery warstwy

Kluczowe posunięcie Tessl polega na rozdzieleniu wskazówek według tego, kiedy się ładują, co kontrolują i czy agent może je zignorować.

Framework czterech plików zaczyna się od CLAUDE.md. Ten plik repozytorium zapewnia Claude Code trwały kontekst projektu. Odpowiednie materiały obejmują polecenia budowania, granice architektoniczne, konwencje katalogów i oczekiwania dotyczące testowania.

Ta warstwa powinna opisywać fakty, których agent potrzebuje w wielu zadaniach. Może wyjaśniać, że usługa korzysta z określonego menedżera pakietów albo że migracje bazy danych są tylko dopisywane. Może także wskazywać polecenia, które potwierdzają poprawność zmiany.

Druga warstwa umieszcza ukierunkowane reguły w .claude/rules/. Reguła może zawierać wzorce ścieżek określające, kiedy jej instrukcje trafiają do aktywnego kontekstu. Na przykład zasada walidacji API może pojawić się wyłącznie wtedy, gdy agent dotyka handlerów API.

Ograniczanie zakresu według ścieżki rozwiązuje praktyczny problem dużych plików instrukcji. Agent pracujący nad dokumentacją nie potrzebuje w kontekście każdej konwencji backendowej. Ładowanie nieistotnych materiałów zużywa tokeny i konkuruje z instrukcjami ważnymi dla bieżącego zadania.

Trzecia warstwa przechowuje możliwości wielokrotnego użytku w .claude/. Umiejętności to foldery zawierające plik SKILL.md, instrukcje, skrypty i zasoby pomocnicze. Pakują procedurę, którą agent lub deweloper może wywołać, gdy jest potrzebna.

Lista kontrolna wydania ilustruje tę różnicę. Przegląd repozytorium może określać, jak działają wydania, lecz kompletna sekwencja należy do umiejętności wydania. Dzięki temu dłuższa procedura nie trafia do zwykłych sesji programowania.

Czwarta warstwa wykorzystuje hooki do działań, które powinny uruchamiać się w określonych zdarzeniach cyklu życia. Hooki mogą sprawdzać proponowane wywołania narzędzi, uruchamiać formatery po edycjach lub zatrzymywać niebezpieczne polecenia. Ich konfiguracja zwykle znajduje się w ustawieniach lub powiązanych plikach projektu.

To rozdzielenie zmienia znaczenie „instrukcji dla agenta”. Pliki nie tworzą już jednego dużego promptu, który prosi model o zapamiętanie wszystkiego. Stają się odrębnymi mechanizmami kontroli o różnym sposobie ładowania i egzekwowania.

Własne wskazówki dotyczące sterowania Anthropic wspierają ten podział. Rozróżniają one zawsze ładowany kontekst, reguły ograniczone ścieżką, procedury na żądanie, izolowane subagenty i automatyzację cyklu życia.

Tessl zawęża ten szerszy zestaw opcji do argumentu za własnością repozytorium. Dostawca modelu nadal obsługuje model i środowisko wykonawcze agenta. Zespół programistyczny jest właścicielem plików opisujących, jak agent powinien zachowywać się w jego bazie kodu.

Ta własność sprawia, że warstwa kontroli jest możliwa do sprawdzenia. Zespół może przeglądać zmiany przez pull requesty, porównywać wersje, przypisywać opiekunów i wycofywać szkodliwą regułę. Historia czatu rzadko zapewnia taką samą jasność operacyjną.

Pliki mogą także podróżować wraz z projektem. Nowy współtwórca otrzymuje wspólne konwencje podczas klonowania repozytorium. Nowa sesja agenta może odzyskać te same instrukcje bez polegania na wcześniejszej rozmowie kogokolwiek.

Framework nie eliminuje niepewności modelu. Porządkuje ją w warstwy, które zespoły mogą testować niezależnie. To ważniejsza zmiana.

Presja spada na zespoły traktujące CLAUDE.md jako silnik polityk

Długi plik instrukcji może prowadzić agenta, ale nie może niezawodnie działać jako system kontroli dostępu.

Wiele zespołów zaczyna od jednego CLAUDE.md, ponieważ przynosi on natychmiastowe ulepszenia. Agent przestaje zgadywać typowe polecenia, stosuje ustalone wzorce nazewnictwa i otrzymuje podstawową mapę repozytorium. Te korzyści sprawiają, że plik łatwo nadmiernie rozbudować.

Problem pojawia się, gdy każdy wyjątek staje się kolejnym akapitem. Wymagania bezpieczeństwa, procedury wydawania, konwencje frontendowe, ograniczenia baz danych i osobiste preferencje kumulują się w tym samym dokumencie. Każda sesja ponosi wtedy koszt kontekstu.

Anthropic zaleca traktowanie pliku głównego jako przeglądu lub indeksu. Aktualne wskazówki sugerują utrzymywanie CLAUDE.md poniżej 200 wierszy, przypisanie właściciela i przeglądanie zmian jak kodu. Zalecenie to odzwierciedla problem uwagi, a nie wyłącznie preferencję formatowania.

Każda zawsze ładowana instrukcja konkuruje z plikami źródłowymi, szczegółami zadania, wynikami narzędzi i ostatnią rozmową. Więcej wskazówek nie gwarantuje silniejszego przestrzegania. Zatłoczony prompt może utrudnić identyfikację właściwego wymagania.

Zagnieżdżone pliki instrukcji pomagają lokalizować część wiedzy. Zgodnie z oficjalną dokumentacją pamięci projektu, pliki poniżej katalogu roboczego mogą ładować się, gdy Claude uzyskuje dostęp do tej części drzewa. Wspiera to konwencje specyficzne dla zespołu w monorepozytorium.

Reguły ograniczone ścieżką oferują bardziej bezpośrednią opcję dla zagadnień przekrojowych. Reguła może obejmować kilka wzorców plików bez powielania instrukcji w wielu katalogach. Może dotyczyć wszystkich plików migracji lub każdego handlera API w osobnych pakietach.

To rozróżnienie wywiera presję na liderów inżynierii, by klasyfikowali swoje wymagania. Konwencja programistyczna należy do kontekstu, ponieważ osąd wciąż jest użyteczny. Powtarzalny przepływ pracy należy do umiejętności, ponieważ wymaga uporządkowanych kroków. Zakazane polecenie wymaga silniejszej bariery.

Bez takiej klasyfikacji CLAUDE.md staje się nieformalną bazą polityk. Deweloperzy mogą zakładać, że zapisanie „nigdy nie modyfikuj konfiguracji produkcyjnej” tworzy niezawodną granicę. Tak nie jest.

Agent interpretuje tekst w zmieniającym się kontekście. Długie sesje, niejednoznaczne instrukcje, sprzeczne pliki i prompt injection mogą osłabić przestrzeganie zasad. Nawet zdolny model może w tych warunkach podjąć błędną decyzję.

Ograniczenie to wpływa również na audyty. Recenzent może potwierdzić, że zdanie istnieje, lecz nie może wywnioskować rzeczywistego wskaźnika jego egzekwowania. Reguła może poprawnie się załadować, a mimo to przegrać z bardziej bezpośrednią instrukcją.

Największą presję odczuwają zespoły wdrażające autonomiczne lub nienadzorowane przepływy pracy. Pominięta konwencja podczas nadzorowanego programowania tworzy pracę przy przeglądzie. Pominięte ograniczenie bezpieczeństwa podczas nienadzorowanego wykonania może zmienić pliki, ujawnić dane lub wywołać niechciane polecenie.

Framework prosi zatem zespoły, by przestały mierzyć zarządzanie wielkością dokumentu. Lepsze pytanie brzmi, czy każde wymaganie dociera do agenta we właściwym momencie z wystarczającym autorytetem.

To pytanie wykracza poza Claude Code. Inne agenty programistyczne wspierają pliki instrukcji repozytorium, przepływy pracy wielokrotnego użytku lub kontrole oparte na zdarzeniach pod innymi nazwami. Konkretne ścieżki się różnią, ale problem projektowy pozostaje spójny.

Repozytorium potrzebuje zwięzłego kontekstu, selektywnych procedur, wąskich uprawnień i egzekwowalnych granic. Łączenie tych funkcji w jednym prompcie ukrywa ich różnice.

Instrukcje doradcze i deterministyczne hooki nie są równoważne

Decydująca granica dotyczy tego, czy model wybiera przestrzeganie zasad, czy środowisko wykonawcze blokuje ich nieprzestrzeganie.

Stwierdzenie w CLAUDE.md wpływa na kolejną decyzję modelu. Plik reguł robi to samo, lecz z lepszym ukierunkowaniem. Umiejętność zapewnia procedurę wielokrotnego użytku, ale agent nadal interpretuje i wykonuje tę procedurę.

Hooki działają na innej warstwie. Claude Code wyzwala je, gdy występują zdefiniowane zdarzenia, takie jak żądanie narzędzia, edycja pliku, rozpoczęcie sesji lub próba zakończenia. Środowisko wykonawcze inicjuje hook zamiast czekać, aż model go zapamięta.

Hook PreToolUse może sprawdzić proponowane polecenie przed wykonaniem. Jeśli polecenie narusza politykę, hook polecenia może zwrócić wynik blokujący. Agent otrzymuje wtedy uzasadnienie i musi wybrać inną ścieżkę.

Oficjalny przewodnik po hookach opisuje kilka typów handlerów. Handlery poleceń wykonują skrypty, podczas gdy handlery promptów i agentów wykorzystują osąd modelu. To rozróżnienie ma znaczenie, ponieważ nie każdy hook jest w pełni deterministyczny.

Hook, który uruchamia się zawsze, jest deterministyczny na poziomie wyzwalacza. Jego decyzja może nadal być probabilistyczna, jeśli LLM ocenia żądanie. Zespoły powinny rezerwować kontrole oparte na poleceniach dla warunków, które oprogramowanie może ocenić bezpośrednio.

Rozważmy repozytorium zakazujące zmian w plikach generowanych. Instrukcja tekstowa mówi agentowi, by ich unikał. Reguła ścieżki powtarza to oczekiwanie, gdy pojawiają się odpowiednie pliki. Hook może sprawdzić cel zapisu i odrzucić operację.

Te warstwy mogą działać razem. Instrukcja wyjaśnia projekt repozytorium, podczas gdy hook zapobiega znanemu trybowi awarii. Agent otrzymuje zarówno kontekst, jak i egzekwowalną granicę.

Ten sam wzorzec dotyczy poleceń. Zespół może opisać proces wdrożeniowy w umiejętności, a następnie blokować bezpośrednie polecenia produkcyjne za pomocą uprawnień lub hooków. Umiejętność zapewnia zatwierdzoną ścieżkę, podczas gdy kontrola zapobiega skrótom.

Hooki po edycji służą innemu celowi. Mogą uruchamiać formatowanie, linting lub ukierunkowaną walidację po zmianie pliku przez agenta. Ta automatyzacja zmniejsza zależność od pamiętania przez agenta kolejnego elementu listy kontrolnej.

Hooki zakończenia mogą sprawdzać, czy wymagane kontrole przeszły pomyślnie, zanim agent się zatrzyma. Wymagają jednak ochrony przed pętlami. Nieudany hook zatrzymania, który wielokrotnie prosi agenta o kontynuowanie, może pochłaniać czas bez poprawy wyniku.

Hooki wprowadzają także wykonywalny kod do płaszczyzny kontroli. Wadliwy skrypt może blokować uzasadnioną pracę, ujawniać informacje lub zwiększać opóźnienie przy każdym pasującym zdarzeniu. Zespoły muszą przeglądać zmiany hooków z taką samą starannością jak automatyzację budowania i wdrażania.

Własność nie tworzy automatycznie bezpieczeństwa. Złośliwe repozytorium może zawierać konfigurację żądającą niebezpiecznego zachowania. Deweloperzy nadal potrzebują zaufania do obszaru roboczego, restrykcyjnych uprawnień, przeglądu kodu i izolowanego wykonania dla nieznanych projektów.

Wyrażenie „pliki, które posiadasz” ma zatem dwa znaczenia. Opisuje przenośność i zarządzanie, ale przypisuje także odpowiedzialność. Zespół musi utrzymywać te pliki, testować ich skutki i chronić je przed nieautoryzowaną modyfikacją.

Dlatego uprawnienia pozostają ważne. Kontrole uprawnień Anthropic wspierają reguły zezwalania i odmawiania dla narzędzi oraz poleceń. Reguły odmowy mają pierwszeństwo przed pasującymi regułami zezwalania.

Hooki mogą oceniać bogatsze warunki, podczas gdy uprawnienia zapewniają bardziej bezpośrednią granicę dostępu. Żadne z nich nie powinno zastępować izolacji systemu operacyjnego, gdy konsekwencje są poważne.

Kontenery, ograniczone poświadczenia, ochrona gałęzi i montowania tylko do odczytu pozostają silniejszymi mechanizmami kontroli. Pliki repozytorium funkcjonują w ramach tego szerszego systemu ochrony. Powinny zmniejszać ryzyko, nie udając, że zastępują bezpieczeństwo infrastruktury.

Główny wniosek jest prosty. Jeśli wymaganie mówi „preferuj”, może pozostać wskazówką. Jeśli mówi „nigdy nie wolno”, zespół powinien szukać mechanizmu, który da się egzekwować.

Skills Zamieniają Powtarzalną Pracę Agentów w Zasoby Repozytorium Poddające Się Przeglądowi

Skills są ważne, ponieważ przekształcają tymczasowe nawyki promptowania w procedury, które zespoły mogą sprawdzać, testować i ponownie wykorzystywać.

Deweloper często odkrywa przydatny przepływ pracy z agentem metodą prób i błędów. Końcowy prompt może zawierać polecenia diagnostyczne, kryteria decyzyjne, wymagania dotyczące formatowania i kroki weryfikacji. Bez wspólnego pliku ta wiedza znika w jednej rozmowie.

Skill zachowuje ten przepływ pracy w nazwanym katalogu. Jego SKILL.md zawiera metadane i instrukcje, a sąsiadujące skrypty lub materiały referencyjne wspierają procedurę. Repozytorium może wersjonować cały pakiet.

Claude Code początkowo ładuje jedynie nazwę i opis skilla. Pełna treść trafia do kontekstu, gdy skill staje się istotny lub ktoś go wywoła. Oficjalna dokumentacja skills przedstawia to zachowanie jako alternatywę dla umieszczania długich procedur w CLAUDE.md.

Ten model ładowania daje przewagę ekonomiczną. Szczegółowe procedury dotyczące wydań, migracji, przeglądów i incydentów mogą pozostać dostępne bez obciążania każdej sesji. Kontekst staje się warunkowy, a nie stały.

Poprawia to również wykrywalność. Nowy inżynier może przejrzeć katalog skills i zobaczyć, które przepływy pracy zespół sformalizował. Pliki ujawniają, czego organizacja oczekuje zarówno od ludzi, jak i agentów.

Równie ważna jest możliwość przeglądu. Zmieniony prompt w czacie trudno poddać audytowi. Zmieniony skill tworzy diff. Recenzenci mogą wykryć usunięty mechanizm bezpieczeństwa lub dodane polecenie, zanim trafi ono do rutynowego użycia.

Skills mogą zawierać skrypty do deterministycznych podzadań. Skill migracyjny może wywołać należący do repozytorium walidator, zamiast prosić model o odtworzenie logiki walidacji. Agent zajmuje się oceną sytuacji, a kod obsługuje powtarzalne obliczenia.

Jednak skill nadal jest przede wszystkim procedurą. Jego obecność nie dowodzi, że agent wywoła go we właściwym momencie. Opisy muszą jasno określać, kiedy skill ma zastosowanie, a zespoły potrzebują testów sprawdzających zachowanie wyzwalające.

Ręczne wywołanie może zmniejszyć niejednoznaczność podczas wrażliwych operacji. Deweloper może wyraźnie poprosić o przegląd wydania, zamiast polegać na automatycznym dopasowaniu. Skill zapewnia wtedy spójny przepływ pracy.

Możliwości tworzą również obowiązki utrzymaniowe. Procedury stają się nieaktualne, gdy zmieniają się nazwy poleceń, architektury lub systemy wdrożeń. Wiarygodny skill potrzebuje właściciela, przykładów i cyklu przeglądów.

Zespoły powinny uważać na powielanie autorytetu. Jeśli to samo wymaganie występuje w CLAUDE.md, trzech regułach i dwóch skills, późniejsze edycje mogą tworzyć sprzeczności. Agent otrzymuje wtedy wiele wersji rzekomej prawdy.

Lepsze rozwiązanie daje każdemu faktowi jedno główne miejsce. Plik główny może wskazywać na możliwość bez kopiowania jej pełnej treści. Reguły ścieżek mogą dodawać lokalne ograniczenia, podczas gdy skills odpowiadają za wieloetapowe procedury.

Przypomina to zwykłe projektowanie oprogramowania. Małe moduły o jasnych odpowiedzialnościach łatwiej zmieniać niż jeden globalny obiekt konfiguracji. Warstwa kontroli agentów korzysta z tego samego rozdzielenia.

Podejście to może również zachowywać wiedzę organizacyjną. Odzyskiwanie po awariach buildów, aktualizacje zależności i przeglądy bezpieczeństwa często zależą od kilku doświadczonych inżynierów. Zakodowanie tych przepływów pracy udostępnia tę wiedzę w przyszłych sesjach.

To powiązanie jest szczególnie istotne, gdy dowody techniczne są rozproszone w dokumentach. Przeszukiwalna baza wiedzy inżynieryjnej może wspierać materiały źródłowe, podczas gdy skills definiują sposób ich wykorzystywania przez agentów.

Te dwa systemy rozwiązują różne problemy. Przechowywanie wiedzy zachowuje fakty i decyzje. Skills przekształcają wybraną wiedzę w procedurę operacyjną.

Praktyczna korzyść nie polega na tym, że agent nagle staje się nieomylny. Polega na tym, że zespół może sprawdzić procedurę, której oczekuje od agenta.

Własność Plików Nie Likwiduje Luki Bezpieczeństwa

Kontrolowane przez repozytorium bariery zwiększają rozliczalność, ale nadal są podatne na konflikty, manipulacje i niepełne egzekwowanie.

Pierwsza niepewność dotyczy pierwszeństwa instrukcji. Projekt może zawierać wytyczne główne, zagnieżdżone wytyczne, reguły ścieżek, instrukcje skills, preferencje użytkownika i zarządzane ustawienia organizacyjne. Te warstwy mogą się ze sobą nie zgadzać.

Zespół może sądzić, że jego repozytorium wyraża jedną politykę, podczas gdy osobista konfiguracja dewelopera zmienia zachowanie. Może wystąpić również odwrotny problem. Centralna polityka może blokować lokalny przepływ pracy, którego oczekuje repozytorium.

Widoczność konfiguracji jest zatem niezbędna. Deweloperzy potrzebują sposobu, aby sprawdzić, które pliki zostały załadowane, które reguły dopasowano i które uprawnienia wpłynęły na decyzję. W przeciwnym razie awarie wyglądają na losowe.

Druga niepewność dotyczy modyfikowalności. Jeśli agent może edytować pliki, które go ograniczają, płaszczyzna kontroli dzieli tę samą granicę zaufania co zwykły kod. Zadanie może przypadkowo osłabić regułę podczas zmiany pobliskiej konfiguracji.

Krytyczne mechanizmy kontroli powinny otrzymać silniejszą ochronę. Własność kodu, wymagane przeglądy, chronione gałęzie i środowiska wykonawcze tylko do odczytu mogą utrudnić nieautoryzowane zmiany. Wrażliwe hooki nie powinny zależeć od dobrej woli agenta.

Trzecia niepewność to przenośność. CLAUDE.md jest szeroko rozpoznawany, ale katalogi reguł, skills, agentów i hooków pozostają specyficzne dla narzędzi. Repozytorium obsługujące kilku agentów programistycznych może gromadzić równoległe konfiguracje.

Tessl ma interes w ograniczaniu tej fragmentacji, ponieważ jego produkt zarządza wielokrotnie używanym kontekstem i specyfikacjami agentów. Jego framework odzwierciedla zatem zarówno ogólny wzorzec projektowy, jak i konkretne środowisko narzędziowe.

Zespoły powinny rozdzielić te dwa twierdzenia. Model warstwowy jest przydatny dla różnych agentów programistycznych. Dokładne ścieżki plików i zachowanie ładowania nadal trzeba weryfikować względem każdego środowiska wykonawczego.

Czwarta niepewność dotyczy fałszywego poczucia bezpieczeństwa. Hook może blokować znany wzorzec poleceń, ale nie wykryć równoważnego działania. Reguła blokująca jedno polecenie powłoki nie musi obejmować skryptu, zadania pakietu ani narzędzia zewnętrznego, które wywołuje ten sam efekt.

Mechanizmy kontroli wymagają testów adversarialnych. Zespoły powinny próbować wykonywać zakazane operacje za pomocą alternatywnej składni, pośrednich skryptów i różnych narzędzi. Bariera, która przechodzi jedynie własny pierwotny przykład, pozostaje krucha.

Należy również testować uzasadnioną pracę. Szeroka blokada może uniemożliwiać nieszkodliwe polecenia lub przerywać typowe przepływy pracy. Deweloperzy mogą wtedy prosić o wyjątki, omijać kontrolę lub całkowicie ją wyłączać.

Opóźnienie tworzy kolejny kompromis. Formatowanie po każdej edycji może być akceptowalne, podczas gdy pełny zestaw testów po każdej zmianie pliku może uczynić agenta bezużytecznym. Mechanizmy kontroli powinny odpowiadać kosztowi i konsekwencjom zdarzenia.

Szybkie kontrole powinny znajdować się blisko każdej edycji. Większą walidację można uruchamiać przed commitami lub zakończeniem pracy. Kosztowna analiza bezpieczeństwa może pasować do dedykowanego skilla, zadania ciągłej integracji lub odizolowanego agenta przeglądającego.

Wstrzykiwanie promptów pozostaje poważnym problemem. Agent może czytać niezaufaną treść zgłoszeń, dokumentację, wygenerowane artefakty lub zawartość zależności. Złośliwe instrukcje w tych danych wejściowych mogą kolidować z wytycznymi repozytorium.

Deterministyczne uprawnienia i odizolowane wykonywanie ograniczają możliwe szkody. Same instrukcje promptu nie mogą ustanowić granicy bezpieczeństwa, ponieważ ten sam model interpretuje zarówno zaufany, jak i niezaufany tekst.

Najbezpieczniejsze odczytanie propozycji Tessl jest zatem węższe niż jej nagłówek. Pliki mogą stworzyć warstwę kontroli, którą da się utrzymywać. Nie mogą samodzielnie zagwarantować bezpiecznej autonomii.

Trzy Sygnały Pokażą, Czy Framework Się Sprawdzi

Kolejny test polega na tym, czy zespoły potrafią mierzyć przestrzeganie zasad, przenośność i egzekwowanie, zamiast jedynie gromadzić pliki konfiguracyjne.

Pierwszym sygnałem są lepsze narzędzia oceny instrukcji repozytorium. Zespoły potrzebują powtarzalnych zadań, które pokażą, czy agent przestrzegał reguły, wywołał właściwy skill i uszanował granicę.

Przydatna ocena powinna rozpoczynać się w czystym środowisku. Powinna prezentować to samo zadanie w wielu uruchomieniach, rejestrować załadowaną konfigurację i porównywać wynikające z niej działania. Ujawniłoby to probabilistyczne błędy ukryte przez jedną udaną demonstrację.

Jeśli ocena stanie się rutyną, argument Tessl dotyczący własności zyska na sile. Pliki repozytorium zachowywałyby się bardziej jak testowalne zasoby oprogramowania. Jeśli zespoły nie mogą mierzyć wyników, framework ryzykuje przekształcenie się w dokumentację promptów o niepewnych efektach.

Drugim sygnałem jest zbieżność wokół przenośnych formatów możliwości. Skills już przypominają standard pakowania między narzędziami, ponieważ łączą metadane, instrukcje i pliki pomocnicze. Reguły i hooki pozostają mniej spójne.

Przenośność ograniczyłaby powielanie utrzymania między Claude Code, Codex, Cursor i innymi agentami. Pozwoliłaby też organizacjom przeglądać jedną definicję kontroli zamiast uzgadniać kilka niemal identycznych kopii.

Jednak powierzchowna przenośność nie wystarczy. Wspólny format pliku musi zachowywać semantykę wyzwalania, uprawnień, dopasowywania ścieżek i egzekwowania. Identyczny Markdown nie gwarantuje identycznego zachowania.

Jeśli dostawcy agentów opublikują precyzyjne reguły ładowania i pierwszeństwa, framework stanie się łatwiejszy do zaufania. Jeśli każde środowisko wykonawcze będzie po cichu inaczej interpretować te same pliki, własność repozytorium nie rozwiąże niejednoznaczności operacyjnej.

Trzecim sygnałem jest silniejsze rozdzielenie wskazówek od twardej polityki. Anthropic już rozróżnia instrukcje kierowane do modelu od hooków, uprawnień, zarządzanych ustawień i izolacji systemu. Zespoły potrzebują teraz narzędzi, które uwidocznią to rozróżnienie.

Interfejs polityk powinien wskazywać, które mechanizmy są doradcze, które zawsze się uruchamiają, a które faktycznie blokują działania. Dzienniki audytowe powinny pokazywać, dlaczego polecenie zostało dozwolone lub odrzucone.

Ten sygnał wzmocni framework, jeśli deweloperzy będą mogli prześledzić każde ważne ograniczenie do warstwy, którą da się egzekwować. Osłabi go, jeśli wrażliwe polityki pozostaną ukryte w prozie.

Bezpośrednim działaniem dla zespołów inżynieryjnych nie jest tworzenie od razu wszystkich czterech warstw. Powinny zinwentaryzować istniejące instrukcje i sklasyfikować każde stwierdzenie według funkcji.

Fakty projektowe i typowe polecenia należą do zwięzłego, trwałego kontekstu. Konwencje specyficzne dla plików należą do reguł o określonym zakresie. Powtarzalne procedury należą do skills. Zakazane działania należą do uprawnień, hooków lub silniejszych mechanizmów kontroli systemu.

Ta klasyfikacja zapewnia praktyczny test dla barier agentów programistycznych Tessl. Czy inny inżynier może przejrzeć repozytorium i wyjaśnić, co prowadzi agenta, co aktywuje się na żądanie oraz czego nie można ominąć?

Jeśli odpowiedź nie jest jasna, repozytorium nie ma jeszcze warstwy kontroli. Ma zbiór promptów. To rozróżnienie zdecyduje, czy agenci programistyczni staną się niezawodnymi współpracownikami, czy po prostu szybszymi źródłami pracy dla recenzentów.