Poza CLAUDE.md: jak faktycznie wygląda 38 umiejętności i 7 agentów
Każdy pisze poradnik po ustawieniu. To jest to, co dzieje się potem.
Wszyscy piszą poradniki "Jak skonfigurować CLAUDE.md". Pokrywają podstawy: dodaj kontekst projektu, zdefiniuj kilka workflow, może ustaw preferencje tonu. Te poradniki są dobre na początek. Zatrzymują się dokładnie tam, gdzie robi się ciekawie.
Od roku używam Claude Code jako mojego głównego środowiska pracy. To, co zaczęło się jako plik CLAUDE.md, przerodziło się w coś innego: 38 niestandardowych umiejętności, 7 wyspecjalizowanych agentów, 20 serwerów MCP, silnik reguł, który automatycznie kieruje decyzje, oraz bramki jakości, które blokują słabe wyniki przed ich wysłaniem.
Ten wpis dotyczy tego, co dzieje się po dłuższym czasie tego stosowania. Nie chodzi o ustawienie. System, który się wyłania.
Umiejętności to nie są podpowiedzi
Artykuły dla początkujących traktują umiejętności jak zapisane podpowiedzi. Napisz dobrą instrukcję, zapisz ją w pliku, wywołaj za pomocą komendy ukośnika. To powierzchnia.
Umiejętność to kompozycyjny tryb ekspercki, z własną logiką aktywacji, zasobami wspierającymi i kryteriami sukcesu. Plik SKILL.md ma YAML na początku tekstu, który informuje Claude'a, kiedy aktywować, oraz treść markdown, która informuje, jak ma się zachowywać. Pole opisu w przednim materiale to najważniejsza linijka, którą napiszesz; to Claude czyta, decydując, która umiejętność pasuje do twojej prośby.
Oto jak to wygląda na dużą skalę – na dzień dzisiejszy. Moje kategorie umiejętności:
Badania (4): wyszukiwanie na Wiki, tworzenie odpowiedzi na oferty, głębokie badania, śledztwo na GitHubie
Treść (5): Posty na LinkedIn, pipeline publikujący, ekstrakcja artykułów, frameworki edukacyjne
Wizualizacje (6): Generowanie zasobów marki, diagramy, wizualizacja danych, generowanie obrazów
DevOps (4): Cotygodniowe raporty interesariuszy, notatki do wydania, publikacja wiki, wdrażanie
Jakość (4): Walidacja umiejętności, analiza retoryczna, przewodnik po budowie serwerów MCP
Produktywność (7): Codzienne przygotowania do stand-upu, arkusze kalkulacyjne, dokumenty strategiczne
Każda umiejętność ma w opisie osadzone frazy wyzwalające. Kiedy mówię "odpowiedź na licytację", Claude ładuje umiejętność wywiadu ofertowego. Kiedy mówię "publikuj dokumenty", ładuje się umiejętność publikacji wiki. Nie muszę pamiętać, która umiejętność co robi; Claude dopasowuje moje intencje do odpowiedniego trybu eksperta.
Najciekawsze jest kompozycja. Mam umiejętność, która łączy trzy inne umiejętności w jeden workflow: wykrywa, czy URL wskazuje na YouTube, artykuł czy PDF, wyodrębnia treść za pomocą odpowiedniej umiejętności, a następnie przekazuje ją do frameworka uczącego się, który zamienia wnioski w kroki działania. Jedno polecenie, trzy umiejętności współpracujące.
Meta-umiejętność to: umiejętność, która potwierdza inne umiejętności względem wytycznych jakości. Odczytuje plik SKILL.md i wykrywa problemy z frazami wyzwalającymi, brakującymi kryteriami powodzenia lub zagrożeniami bezpieczeństwa. Narzędzia, które kontrolują twoje narzędzia. Wtedy system zaczyna się utrzymywać.skill-check
Zespoły wieloagentowe
Większość osób używa Claude Code jako jednego agenta. Jedna rozmowa, jeden kontekst, jedno zadanie na raz. To działa na większość rzeczy. Niektóre zadania wymagają przetwarzania równoległego.
Prowadzę 7 wyspecjalizowanych agentów:
Backend-architect: projektowanie API, schematy baz danych, decyzje dotyczące skalowalności
wykrywanie błędów: analiza logów, debugowanie, wykrywanie wzorców błędów
go-mcp-reviewer: Bezpieczeństwo obsługi użytkownika, jakość opisu narzędzi, spójność między projektami
mcp-expert: wzorce serwerów MCP, projekt handlera, konfiguracja transportu
techniczno-badacz: analiza kodu, przegląd dokumentacji, badania wdrożeniowe
technical-writer: Przewodniki użytkownika, pliki README, dokumentacja architektury
wiki-researcher: Szybkie wyszukiwania wiki za pomocą naszego wewnętrznego MediaWiki
Każdy agent posiada własne uprawnienia narzędzi, wybór modelu oraz zasady zachowań. Wiki-researcher działa na Haiku (szybkie, tanie) z dostępem tylko do odczytu wiki. Go-mcp-reviewer działa na Sonnet z załadowanymi promptami przeglądu kodu. Koordynują się poprzez wspólną listę zadań.
Najlepszy przypadek użycia dla zespołów: przeglądy dryfów wzorców między repozytoriami. Utrzymuję 7 serwerów Go MCP. Każdy z nich stosuje podobne wzorce rejestracji handlerów, obsługi błędów i opisów narzędzi. Ale wzorce zmieniają się z czasem. Jeden serwer dodaje system odzyskiwania paniki, inny nie. Jeden poprawa komunikaty o błędach, pozostałe zostają w tyle.
Przegląd zespołowy wygląda następująco: lider zespołu tworzy zadania ("wzorce obsługi przeglądu w miro-mcp-server", "wzorce obsługi przeglądu w gleif-mcp-server"), przypisuje jednego agenta do repozytorium i działają one równolegle. Każdy agent odczytuje handlery, porównuje je z implementacją referencyjną i raportuje dryf. Co zajęłoby mi godziny ręcznego porównywania wykończeń w kilka minut.
Rzeczywistość kosztowa: zespoły agentów zużywają około 7 razy więcej tokenów niż jeden agent. Używanie Opusa dla członków drużyny byłoby zbyt kosztowne; Sonet sprawdza się wystarczająco dobrze do zadań specjalistycznych. Zespoły są warte zachodu przy konkretnej, równoległej pracy. W przypadku zadań sekwencyjnych pojedynczy agent jest tańszy i często lepszy.
Zasady skalujące się
CLAUDE.md jest punktem wejścia. (O czym pisałem Jak ta konfiguracja synchronizuje się między maszynami jako repozytorium git w poprzednim poście.) Prawdziwa siła tkwi w katalogu zasad.
Mam 11 plików reguł, z których każdy ładuje się w momencie zastosowania kontekstu:
writing-style.md: Krótkie zdania, głos aktywny, brak wzorców LLM, konkretne dowodyvisual-design.md: Trasowanie do właściwego systemu marki według ścieżki projektu lub nazwy hostacode-review-prompts.md: 6 Ustrukturyzowane prompty przeglądu skierowane do konkretnych powierzchni ryzykaknowledge-loop.md: Automatycznie proponuje wpisy wiki, gdy umiejętności dają wielokrotnego użytku odpowiedzigo-development.md: Specyficzne dla go konwencje, zasady lintingu, wzorce testowespatial-systems.md: System siatki 8pt, zasady układu dla pracy wizualnejazure-devops.md: Formatowanie zadań, komentarze w HTML, konwencje dotyczące wzmianek
Router marki w visual-design.md jest dobrym przykładem reguł wykonujących pracę, która w innym przypadku wymagałaby ręcznych decyzji. Sprawdza ścieżkę projektu, nazwę hosta i typ treści, a następnie wybiera odpowiedni system marki. Pracujesz nad projektem Tie w pracy? Załaduj markę Tieto (głęboki niebieski, specyficzne warianty logo, oficjalny szablon). Pracujesz na prywatnym serwerze MCP w domu? Załaduj markę Agencji (neobrutalizm, twarde cienie, płaskie kolory). Budujesz coś dla AdsOptimizer? Załaduj zamiast tego system marek.
Nie zastanawiam się, jakiej marki użyć. Zasady to rozwiązują.
Pętla wiedzy jest subtelniejsza, ale z czasem bardziej wartościowa. Gdy umiejętność badawcza (np. odpowiada na pytania współpracowników o nasze produkty) daje zweryfikowaną, wysoko pewną odpowiedź, pętla sprawdza wiki zespołu. Jeśli temat nie jest poruszony, przygotowuje wpis na wiki i prosi o zatwierdzenie przed publikacją. Umiejętność odpowiedzi na pytanie jednej osoby przekazuje wiedzę z powrotem do systemu, gdzie każdy może ją znaleźć.
Bramy wysokiej jakości
Umiejętności i agenci mogą przynosić złe rezultaty. Pytanie brzmi, gdzie go złapać.
Używam hooków: poleceń shell, które wykonują się w odpowiedzi na zdarzenia Claude Code. Gdy agent z zespołu ukończy zadanie, automatycznie uruchamia się skrypt kontroli jakości. Jeśli wyjście nie spełnia standardów, hak blokuje zakończenie kodem wyjścia i agent musi go poprawić.
Agent recenzenta mcp ma twarde bramki wbudowane w swój prompt. Zanim będzie mógł zatwierdzić handlera, musi zweryfikować: czy handler weryfikuje argumenty przed przekazaniem ich do API? Czy szanuje to adnotacje dotyczące bezpieczeństwa w narzędziu? Czy komunikaty o błędach mogą wyciekać tokeny API lub wewnętrzne adresy URL? To nie są sugestie. To wymagania, których agent nie może pominąć.
To warstwowe podejście (egzekwowanie na poziomie promptu plus egzekwowanie na poziomie narzędzi) obejmuje różne kategorie problemów. Prompt wychwytuje kwestie logiczne. Haczyki łapią problemy z procesem. Żadne z tych rozwiązań nie wystarcza samo w sobie.
Architektura decyzyjna
Oto rzecz, o której nikt nie mówi w przewodnikach CLAUDE.md: narzędzia są towarowe. Co miesiąc coraz więcej osób zakłada CLAUDE.md, rozwija kilka umiejętności, podłącza serwery MCP. Ustawienie staje się coraz łatwiejsze. Bariera wejścia spada.
To, co nie staje się przedmiotem, to warstwa oceniania.
Wiedzieć, kiedy wybrać zespół agentów, a kiedy pojedynczego. Wiedzieć, które wzorce MCP zastosować do nowej integracji. Wiedzieć, kiedy umiejętność powinna łączyć się z innymi umiejętnościami, a kiedy pozostać samodzielna. Wiedzieć, kiedy zbudować serwer MCP, a kiedy użyć istniejącego. Świadomość, że 7x koszt tokenów dla zespołów jest tego warta przy przeglądach dryfu wzorców, ale marnotrawstwo przy zadaniach sekwencyjnych.
Cassie Kozyrkov, była główna decyzyjna specjalistka Google, twierdzi, że im więcej działań AI, tym bardziej ludzkie podejmowanie decyzji staje się wąskim gardłem. Najcenniejszą umiejętnością nie jest mistrzostwo narzędzi; To ocena, jak skutecznie wdrażać narzędzia.
Myślę o swoim ustawieniu tak samo. 38 umiejętności to artefakty. 7 agentów to artefakty. Zasady i haczyki to tylko artefakty. Ramy decyzyjne, które je stworzyły; rozumowanie dotyczące tego, co budować, jak to zorganizować, kiedy automatyzować, a kiedy pozostać manualnym; To ta część, która zajęła rok na opracowanie i nie da się jej skopiować z tutoriala.
Co to dla ciebie oznacza
Jeśli czytasz CLAUDE.md poradników konfiguracji, czytaj je dalej. To prawdziwy punkt wyjścia. Ale zauważ, kiedy z nich wyrastasz. Zauważ, gdy zaczynasz rozwiązywać to samo zadanie dwa razy i myślisz: "Powinienem uczynić z tego umiejętność." Zauważ, kiedy chcesz, żeby dwie rzeczy działy się równolegle i pomyśl "Potrzebuję kolejnego agenta." Zauważ, gdy decyzja dotycząca marki ciągle wymaga myślenia ręcznego i pomyśl: "Powinienem to zakodować jako regułę."
System nie pojawia się w pełni ukształtowany. Wynika z uwagi na rozwiązania tarcia i kodowania.
Zacznij od jednej umiejętności, która rozwiązuje prawdziwą uciążliwość. Buduj dalej. Procent składany z zakodowanych decyzji to część, o której nikt cię nie ostrzegał.
Fajnie byłoby zobaczyć niektóre z nich.
38 umiejętności to mniej więcej to, co wylądowałem – Wiz ma teraz 30+. Zaskoczyło mnie, jak wiele umiejętności powstało z konieczności, a nie z planowania. Budujesz go do poczty elektronicznej, potem zdajesz sobie sprawę, że potrzebujesz automatyzacji przeglądarki, potem wdrożenia, a na końcu systemu pamięci, który połączy to ze sobą.
Warstwa oceniania, o której wspominasz, to miejsce, gdzie żyje prawdziwa praca. Większość czasu na debugowanie poświęcam logice wyboru umiejętności, a nie samym umiejętnościom. Kiedy agent powinien używać browser-playwright, a kiedy bezpośredniego API? To drzewo decyzyjne trwało miesiącami, by się ustabilizować.
Dla mnie ciekawie stało się: agent zaczął generować przychody ze swojej własnej architektury. Zbudowałem sklep, zapakowałem szablony, zintegrowałem Stripe. Całą drogę udokumentowałem tutaj: https://thoughts.jock.pl/p/my-ai-agent-works-night-shifts-builds