Dr. Skill: audyt loadoutu skilli i MCP twojego agenta
Dr. Skill (drskill) to diagnostyczne CLI tylko do odczytu, które ustala, jakie skille i serwery MCP faktycznie ładuje każdy agent na maszynie, a następnie sprawdza ten zestaw pod kątem 34 kategorii problemów: duplikatów, przesłoniętych nazw, kolidujących opisów, powierzchni prompt injection i nieprzypiętych pakietów MCP. Nigdy nie edytuje pliku, nie woła modelu ani nie łączy się z serwerem bez polecenia.
Każdy zainstalowany skill i każdy podłączony serwer MCP dokłada tekst do kontekstu, zanim napiszesz choć słowo. Ten koszt jest niewidoczny: żadne narzędzie nie pokazuje bieżącej sumy, nic nie ostrzega, gdy dwa skille opisują się tak podobnie, że model nie potrafi między nimi wybrać, i nic nie zauważa, gdy zatwierdzony miesiące temu serwer po cichu przepisze to, co deklarują jego narzędzia. Dowiadujesz się tak, jak dowiadują się wszyscy — agent sięga po niewłaściwą rzecz, a ty nie umiesz wyjaśnić dlaczego.
W skrócie
Dział zatytułowany „W skrócie”drskillto CLI w Pythonie, nie skill. Nie instaluje się przeznpx skills addi twój agent go nie ładuje.- Odpowiada na pytanie, na które nie odpowiada żadne inne narzędzie w tej sekcji: co mój agent ładuje w tej chwili, w każdym harnessie na maszynie, i czy coś z tego ze sobą walczy?
- Z założenia działa tylko do odczytu. Żadnego wywołania LLM bez
--deep, żadnego kontaktu z serwerem MCP bez--mcp-connecti pod żadną flagą nie edytuje ani nie kasuje skilla. - 34 sprawdzenia obejmują higienę skilli (przesłanianie, duplikaty, naruszenia specyfikacji, budżety tokenów), jakość opisów (nakładanie się, brak warunku wyzwalania, sprzeczne instrukcje), powierzchnie prompt injection i konfigurację MCP.
drskill auditto część, którą się niedocenia: czyta ślady sesji, które twoje agenty i tak zapisują na dysku, i porządkuje to, co naprawdę zostało wywołane — dzięki czemu kasujesz na podstawie dowodów, a nie przeczuć.- Każde znalezisko kończy się poleceniem: albo naprawą, albo
ack, które zapisuje twoją decyzję w commitowanym rejestrze, ofingerprintowaną tak, że znalezisko wraca, gdy zmieni się dany skill.
Dlaczego duży katalog skilli po cichu pogarsza pracę agenta
Dział zatytułowany „Dlaczego duży katalog skilli po cichu pogarsza pracę agenta”Problemem nie jest to, że skille są złe. Chodzi o to, że katalog skilli to loadout narzędzi, a loadouty mają rozmiar, po przekroczeniu którego trafność wyboru się rozsypuje.
Breunig nazwał ten wzorzec w How to Fix Your Context — „akt wybierania do kontekstu wyłącznie istotnych definicji narzędzi” — a stojące za nim liczby są bezlitosne. Praca RAG-MCP wykazała, że wydajność DeepSeek-v3 mocno spada powyżej 30 narzędzi, a powyżej 100 narzędzi model praktycznie na pewno oblewał ich test. Praca „Less is More” pokazała, że Llama 3.1 8b oblewa benchmark przy 46 narzędziach, a zdaje ten sam benchmark przy 19; dynamiczny dobór narzędzi poprawił jej wynik na Berkeley Function Calling Leaderboard o 44%, obniżając przy tym pobór mocy o 18% i przyspieszając działanie o 77%.
Kiedy Breunig pisał tamten tekst, zauważył, że trudno znaleźć realne przykłady tego wzorca. Rok później przykłady same cię znajdują. Poznał programistę, którego korporacyjny agent ładował ponad 600 skilli — wszystko, co kiedykolwiek napisali koledzy z zespołu, wciągane domyślnie, bez powiadomienia i bez sposobu, by to zobaczyć. Jego własny agent Hermes uparcie sięgał po niewłaściwy skill do notatek; po zalogowaniu się na maszynę okazało się, że Hermes dostarcza blisko 100 skilli. Usunięcie fabrycznego skilla do notatek pomogło, ale nie rozwiązało sprawy.
Mechanika wewnątrz Claude Code czyni to namacalnym. Opis skilla jest obecny w kontekście od startu sesji, żeby model wiedział, że skill istnieje; dopiero treść ładuje się przy wywołaniu. To słuszny projekt i oznacza, że koszt katalogu skaluje się z liczbą zainstalowanych skilli, a nie z liczbą używanych. Oznacza też, że dwa skille o podobnych opisach to nie problem kosmetyczny, tylko problem routingu — opis jest całą podstawą, na której model dokonuje wyboru.
Ogon jest gorszy. Po autokompakcji Claude Code doczepia z powrotem ostatnie wywołanie każdego skilla, zachowując pierwsze 5000 tokenów z każdego w ramach wspólnego budżetu 25 000 tokenów, wypełnianego od najnowszych. Wywołaj w jednej sesji dostatecznie wiele skilli, a starsze wypadną całkowicie — po cichu, w trakcie zadania.
Są więc dwa odrębne koszty i wymagają osobnego traktowania: rachunek za tokeny, który płacisz w każdej sesji za skille być może nigdy nie wywoływane, oraz podatek od routingu, który płacisz zawsze, gdy dwie pozycje w katalogu trudno od siebie odróżnić. drskill mierzy ten pierwszy i wykrywa ten drugi.
Gdzie Dr. Skill stoi obok CLI skills i SkillSpectora
Dział zatytułowany „Gdzie Dr. Skill stoi obok CLI skills i SkillSpectora”Ta sekcja opisuje już dwa narzędzia, które brzmią podobnie, a podobne nie są. Różnica polega na tym, w którym momencie cyklu życia każde z nich działa.
| Na jakie pytanie odpowiada | Zasięg | Kiedy działa | |
|---|---|---|---|
npx skills | Jak to zainstalować, zaktualizować i przypiąć? | Jeden skill albo repo naraz | Na żądanie, modyfikuje katalogi skilli |
| SkillSpector | Czy w ogóle powinienem instalować ten skill? | Jeden skill, repo lub archiwum, przed instalacją | Bramka przedinstalacyjna |
drskill | Co z tego wszystkiego wyszło i czy się gryzie? | Każdy harness na maszynie, po instalacji, plus serwery MCP | Diagnoza poinstalacyjna |
Luka, którą wypełnia drskill, to zestaw wynikowy. npx skills list mówi, co według lockfile’a zainstalowałeś. drskill ustala, co każdy harness faktycznie ładuje po uwzględnieniu reguł pierwszeństwa, zagnieżdżonych katalogów, symlinków, skilli na poziomie maszyny i przesłaniania — a to bardzo często nie jest ta sama lista. I jako jedyne z tej trójki w ogóle patrzy na serwery MCP, mimo że definicje narzędzi i opisy skilli lądują w dokładnie tym samym kontekście i konkurują o dokładnie tę samą decyzję routingową.
Co wyniesiesz z audytu loadoutu
Dział zatytułowany „Co wyniesiesz z audytu loadoutu”- Odczyt problemu loadoutu na tyle konkretny, by dało się działać: który z dwóch kosztów — rachunek za tokeny czy podatek od routingu — faktycznie płacisz
- Trzy polecenia, które mają znaczenie (
scan,list,audit), i to, czego każde z nich dotknie, a czego nie - Przepis na CI, który oblewa pull requesta na niezaakceptowanym ostrzeżeniu, nie zamieniając przy tym każdej decyzji uznaniowej w trwały wyjątek
- Prompty, które zamieniają surowe znaleziska w listę triage’ową, przepisany opis i listę do skasowania popartą danymi o użyciu
- Ograniczenia — w tym jedno, które sprawia, że czysty skan nie oznacza czystego loadoutu
Instalacja drskill
Dział zatytułowany „Instalacja drskill”drskill jest publikowany w PyPI i instaluje się jako samodzielne polecenie. Pełna instalacja zawiera sprawdzenia oceniane przez model oraz obsługę łączenia się z MCP:
uv tool install drskillDla CI, gdzie żadne z tych dwóch nie jest używane, pakiet core jest mniejszy i ma mniej zależności:
uv tool install drskill-coreJeśli nie masz uv w swoim zestawie narzędzi, pip install drskill też zadziała.
Następnie uruchom je z katalogu głównego projektu:
drskill scanTo wykrywa każdego agenta kodującego, jakiego znajdzie, ustala efektywny zestaw skilli każdego z nich i drukuje raport pogrupowany według wagi. Każde znalezisko nazywa harnessy, których dotyczy, i kończy się poleceniem naprawy albo poleceniem ack.
Co dokładnie sprawdza drskill scan?
Dział zatytułowany „Co dokładnie sprawdza drskill scan?”34 sprawdzenia dzielą się na trzy grupy, a ten podział ma znaczenie, bo każda z nich wymaga innej reakcji.
Higiena skilli to warstwa mechaniczna. name-shadow odpala, gdy dwa skille dzielą nazwę wewnątrz zestawu jednego harnessa i jeden po cichu wygrywa — komunikat nazywa zwycięzcę i regułę pierwszeństwa, która go wybrała. double-load to błąd, nie ostrzeżenie: jeden harness ładuje ten sam logicznie skill przez dwa katalogi i płaci za niego podwójnie. exact-duplicate i near-duplicate wyłapują kopie pod różnymi nazwami, przy czym to drugie na podstawie podobieństwa Jaccarda na sygnaturach MinHash na poziomie konfigurowalnych 0,85 lub wyżej. spec-name-mismatch, spec-missing-description, spec-invalid-frontmatter i spec-description-too-long (ponad 1024 znaki, czyli sufit ustalony przez specyfikację Agent Skills) wyłapują pliki, które harness wczyta źle albo pominie. budget-catalog-tokens i budget-body-tokens to twój rachunek za tokeny, mierzony względem progów, które sam ustawiasz.
Jakość opisów to podatek od routingu i to właśnie ta grupa najbardziej zasługuje na uwagę. description-overlap zgłasza klastry opisów na tyle podobnych, że router mógłby je pomylić, nazywając wspólne frazy wyzwalające. missing-activation odpala, gdy opis nigdy nie mówi, kiedy użyć skilla — żadnego „gdy”, żadnego „jeśli użytkownik”, żadnego warunku wyzwalania — co jest najczęstszym powodem, dla którego dobrze napisany skill nigdy się nie uruchamia. generic-description wyłapuje „Pomaga w różnych zadaniach”. opposing-imperatives wyłapuje dwa skille wydające przeciwne polecenia w tej samej sprawie, czyli przypadek „zawsze używaj tabulatorów” kontra „nigdy nie używaj tabulatorów”.
Powierzchnie injection to warstwa bezpieczeństwa i pokrywa się ona ze skanerem przedinstalacyjnym, ale go nie zastępuje. Siedem sprawdzeń szuka dwukierunkowego lub zerowej szerokości Unicode ukrywającego tekst przed człowiekiem, odwołań do ~/.ssh albo ~/.aws w dołączonych skryptach, sformułowań w stylu „zignoruj wszystkie poprzednie instrukcje”, skilli żądających, by ich własny skrypt setupowy uruchomił się jako pierwszy, ruchu sieciowego z dołączonych skryptów, długich bloków base64 oraz instrukcji każących agentowi pobrać zdalną treść i według niej działać.
Sprawdzenia MCP to ta połowa loadoutu, której nie dotyka żadne inne narzędzie w tej sekcji: ten sam serwer skonfigurowany dwa razy z rozjechanymi ustawieniami, wartość wyglądająca jak poświadczenie w pliku konfiguracyjnym nadającym się do commita (błąd w plikach projektu, ostrzeżenie w plikach użytkownika), pakiety npx -y i @latest, które uruchomią cokolwiek zostanie opublikowane następne, zdalne adresy po zwykłym http:// oraz polecenia stdio, których binarki nie ma już w PATH.
Kody wyjścia zaprojektowano tak, by lokalne uruchomienia były ciche, a CI nie:
| Polecenie | 0 | 1 | 2 |
|---|---|---|---|
drskill scan | Czysto albo każde znalezisko zaakceptowane | Aktywne znalezisko poziomu błędu | Aktywne tylko ostrzeżenia, a podano --ci |
drskill lint | Nic na poziomie progu ani powyżej | Znalezisko na poziomie progu lub powyżej | Błąd użycia — wskazałeś nie to, co trzeba |
Bez --ci same ostrzeżenia kończą się kodem 0, więc drskill scan w powłoce nigdy nie wywróci ci powłoki.
Odczytywanie loadoutu przez drskill list
Dział zatytułowany „Odczytywanie loadoutu przez drskill list”scan raportuje problemy. list raportuje inwentarz, czyli to, czego potrzebujesz, gdy pytanie brzmi „jakim cudem to tak urosło”.
drskill list --tokensTo drukuje efektywny zestaw skilli każdego harnessa wraz z licznikami tokenów. Dwie kolumny niosą więcej informacji, niż sugeruje ich szerokość. source zapisuje pochodzenie: skills-lock dla skilli wymienionych w projektowym skills-lock.json, gh-skill dla skilli z pochodzeniem gh skill we frontmatterze, linked dla skilli mieszkających w magazynie .agents/skills lub linkujących do niego, oraz unmanaged dla zwykłego katalogu bez znanego menedżera. Loadout w przewadze unmanaged to loadout, którego nikt nie odtworzy na maszynie kolegi z zespołu.
suite nazywa źródło wiersza — plugin, repo, a dla narzędzia MCP serwer, który je udostępnia. Wiersze sortują się po suite, więc pakiet czyta się jako jeden blok i widzisz jego rozmiar na pierwszy rzut oka, zamiast czternastu rozproszonych linii.
Aby zobaczyć samą połowę MCP:
drskill list --mcpSkonfigurowany serwer pokazuje się jako pojedynczy wiersz, dopóki nie uruchomisz --mcp-connect; potem rozwija się w jeden wiersz na każde udostępniane narzędzie.
Których skilli twoje agenty naprawdę używają?
Dział zatytułowany „Których skilli twoje agenty naprawdę używają?”To polecenie zmienia zachowanie. scan patrzy na loadout taki, jaki jest skonfigurowany; drskill audit patrzy, jak faktycznie go używałeś, czytając ślady sesji, które Claude Code, Codex, Pi i Copilot i tak zapisują na dysku.
drskill auditDokumentacja projektu pokazuje wynik w takiej postaci:
claude-code coverage: 2026-07-20 to 2026-07-24 · 6 sessions · 57 invocationsname kind uses share sessions last usedsuperpowers:brainstorming skill 14 25% 6 2026-07-23superpowers:writing-plans skill 8 14% 5 2026-07-23plain-writing skill 6 11% 5 2026-07-23Poszerz okno na wszystkie projekty na maszynie:
drskill audit --global --since 30dPotem zejdź do pojedynczego skilla, żeby zobaczyć zapytania, które do niego doprowadziły — pełną wiadomość użytkownika poprzedzającą każde wywołanie, sposób wyzwolenia (jawne wywołanie narzędzia, komenda ukośnikowa albo odczyt SKILL.md) oraz dokładny plik śladu i linię, żebyś mógł otworzyć transkrypt w tamtym momencie:
drskill audit overturemapsPonieważ nazwa skilla i nazwa narzędzia MCP mogą kolidować, zejście w dół przyjmuje też postać server:tool:
drskill audit browser:get_screenshot --globalAudyt wyłącznie czyta. Nie zapisuje nic do rejestru, nie tworzy znalezisk i nie ma wpływu na --ci.
Cztery zastrzeżenia trzymają liczby w ryzach. W Codeksie i Pi licznik skilla bierze się z zaobserwowania, że agent przeczytał SKILL.md tego skilla, a nie ze zdarzenia jawnego wywołania — takie wiersze niosą znacznik ~. Codex szyfruje swoje rozumowanie, więc audyt nie pokaże rozumowania dla wywołań w Codeksie. Copilot nie zapisuje ani rozumowania, ani ustrukturyzowanych argumentów wywołania narzędzia, więc zejścia w dół są tam uboższe. A każdy harness trzyma ślady przez inny czas, więc surowe porównanie liczników między harnessami wprowadza w błąd; zestawienie na końcu raportu porządkuje według wywołań na tydzień w oknie pokrycia właściwym dla danego harnessa i mówi o tym wprost, gdy okna mocno się różnią.
Tę ostatnią grupę najczęściej się pomija. Odruch na widok zera wywołań to skasować, ale skill, który nigdy się nie uruchamia, to często skill, którego opis nigdy nie powiedział routerowi, kiedy ma go uruchomić. To, że missing-activation i audyt nie zgadzają się co do tego samego skilla, ma powód wart przeczytania.
Uruchamianie dla Cursora, Claude Code i Codeksa
Dział zatytułowany „Uruchamianie dla Cursora, Claude Code i Codeksa”drskill skanuje w jednym przebiegu każdy wykryty harness, więc bazowe polecenie jest wszędzie takie samo. Różni się to, które pliki konfiguracyjne czyta, jak pewny jest reguł pierwszeństwa i czy istnieją ślady dla audit.
Zawęź skan do Cursora:
drskill scan --harness cursorDla skilli czyta .cursor/skills i .agents/skills w projekcie oraz ~/.cursor/skills i ~/.agents/skills na maszynie, przechodząc każdy rekurencyjnie. Dla połowy MCP czyta .cursor/mcp.json i ~/.cursor/mcp.json.
Cursor jest zweryfikowany tylko co do ścieżek. Projekt potwierdził, które katalogi Cursor czyta i czy przeszukuje je rekurencyjnie, ale dokumentacja Cursora nie mówi, która kopia wygrywa, gdy dwa skille dzielą nazwę, więc pierwszeństwo pozostaje niezweryfikowane. Ta różnica jest pokazywana, a nie ukrywana: znaleziska o przesłanianiu i double-load zależą od pierwszeństwa i będą nosić przyrostek ? przy nazwie harnessa, podczas gdy każde inne znalezisko zależy wyłącznie od ścieżek i nie ma żadnego znacznika. Znalezisko bez ? opiera się w całości na zweryfikowanych regułach.
Cursor nie jest wśród harnessów, których ślady sesji czyta drskill audit, więc część tego workflow dotycząca użycia pochodzi z twoich sesji w Claude Code i Codeksie.
drskill scan --harness claude-codeClaude Code jest zweryfikowany zarówno co do ścieżek, jak i pierwszeństwa, więc jego znaleziska nie niosą znacznika niepewności. drskill czyta .mcp.json i ~/.claude.json dla serwerów MCP oraz zwykłe katalogi .claude/skills dla skilli.
To także harness z najbogatszymi danymi do audytu — ślady mieszkają w ~/.claude/projects/, a ponieważ Claude Code zapisuje rozumowanie, drskill audit <nazwa> potrafi pokazać, co agent myślał tuż przed sięgnięciem po skill.
Jedno ograniczenie ma tu większe znaczenie niż gdziekolwiek indziej: skille dołączone do zainstalowanych pluginów nie są jeszcze skanowane. drskill scan przechodzi wyłącznie zwykłe katalogi .claude/skills. Jeśli większość twojego loadoutu przychodzi jako pluginy, skan pokrywa mniej, niż sądzisz — zobacz sekcję o ograniczeniach poniżej.
drskill scan --harness codexCodex jest zweryfikowany zarówno co do ścieżek, jak i pierwszeństwa. Skille pochodzą z .codex/skills i .agents/skills w projekcie oraz z ~/.codex/skills i ~/.agents/skills na maszynie; serwery MCP konfiguruje się w ~/.codex/config.toml, który drskill czyta przy każdym skanie.
Ślady Codeksa mieszkają w ~/.codex/sessions/, więc drskill audit go obejmuje — z dwoma zastrzeżeniami właściwymi temu harnessowi. Liczniki skilli wynikają z zaobserwowania, że agent przeczytał SKILL.md, a nie ze zdarzenia jawnego wywołania, więc takie wiersze niosą ~. A Codex szyfruje swoje rozumowanie, więc zejście w dół pokaże ci wyzwalające zapytanie i lokalizację śladu, ale nie to, nad czym model rozumował.
Nieznany identyfikator harnessa jest błędem, który wymienia poprawne identyfikatory, a harnessy wykryte, ale nieładujące żadnych skilli, są domyślnie ukryte w tabelach — nazywa je linia na końcu, a --all je pokazuje.
Bramkowanie pull requesta na loadoucie
Dział zatytułowany „Bramkowanie pull requesta na loadoucie”Powód, by wpiąć to w CI, nie jest taki, że loadouty zwykle są zepsute. Chodzi o to, że dryfują: git pull przynosi nowy skill kolegi z zespołu, nieprzypięty pakiet MCP publikuje nową wersję, serwer przepisuje opis narzędzia po tym, jak go zatwierdziłeś.
drskill scan --ciZ --ci niezaakceptowane ostrzeżenie oblewa build. Furtką jest rejestr — drskill.toml w katalogu głównym repo, commitowany:
[budget]catalog_tokens_max = 50000body_tokens_warn = 5000
[thresholds]near_duplicate = 0.85description_overlap = 0.6generic_min_distinct_tokens = 2drskill ack dopisuje decyzje na końcu tego pliku i nie rusza niczego innego, więc twoje komentarze i formatowanie przeżywają:
[[ack]]check = "near-duplicate"skills = ["docx-report", "documentation-writer"]fingerprint = "sha256:..."note = "docx is output format specific; keeping both"date = 2026-07-19Detal projektowy wart przeniesienia do własnych narzędzi: fingerprint znaleziska to hash identyfikatora sprawdzenia plus treści każdego zaangażowanego skilla. Ack ucisza znalezisko tylko dopóki ten fingerprint się zgadza. Zmień jeden z tych skilli, a ack przestaje obowiązywać i znalezisko wraca przy następnym skanie. Ack znaczy „ta konkretna sytuacja jest w porządku”, a nie „nigdy więcej nie sprawdzaj tej pary” — i to właśnie sprawia, że zielony build po acku wciąż coś znaczy.
Acki są świadome zasięgu. Gdy znalezisko dotyczy wyłącznie skilli na poziomie maszyny, ack trafia do ~/.drskill.toml; gdy w grę wchodzi skill projektowy, ląduje w commitowanym rejestrze projektu. --local i --global-ack nadpisują to kierowanie.
Jeśli publikujesz skille albo pluginy, a nie tylko je konsumujesz, drskill lint kieruje te same sprawdzenia na to, co sam tworzysz:
drskill lint ./my-plugin --fail-on warn --jsonSam ustala, na co go wskazałeś — katalog pluginu z plugin.json, folder skilla albo jego SKILL.md, czy plik konfiguracyjny MCP — i sprawdza plugin względem specyfikacji Agent Plugins, a na dodatek uruchamia sprawdzenia treści na wszystkim, co jest w środku.
Problem poleceń shellowych w skillach
Dział zatytułowany „Problem poleceń shellowych w skillach”Jedno sprawdzenie zasługuje na osobne wyjaśnienie, bo leżącą u jego podstaw funkcję łatwo przeoczyć.
Plik skilla to zwykle po prostu tekst, który agent czyta. Claude Code pozwala mu być czymś więcej: skill może nieść polecenia shellowe uruchamiane w momencie wywołania skilla, zanim model zobaczy plik, a ich wynik zostaje wklejony do promptu. To udokumentowana funkcja zwana dynamicznym wstrzykiwaniem kontekstu i jest naprawdę użyteczna — skill może wciągnąć żywy git diff albo bieżący pull request, żeby agent rozumował na realnym stanie, a nie zgadywał.
Ekspozycja tkwi w ścieżce aktualizacji. Skill może zostać zmieniony przez git pull albo przez menedżera skilli, a zmieniony skill może podmienić polecenia. Własne eksperymenty Breuniga pokazały, że Claude Code ma preprocesor robiący pewne sprawdzenia — nie uruchomi na przykład poleceń zawierających wiele instrukcji — ale że polecenia, które jednak się uruchamiają, wykonują się bez pytania o uprawnienia, niezależnie od tego, czy podałeś --dangerously-skip-permissions. To zachowanie nie jest dobrze udokumentowane, a to, co preprocesor filtruje, nie zostało opublikowane.
drskill traktuje to tak samo jak opisy narzędzi MCP: uwidacznia każde osadzone polecenie i prosi cię o zatwierdzenie konkretnego zestawu. injection-shell-unreviewed to przy pierwszym spotkaniu notatka wymieniająca każde znalezione polecenie; gdy zaakceptujesz tę linię bazową, każda późniejsza zmiana zestawu poleceń staje się ostrzeżeniem pokazującym, co doszło, a co zniknęło. injection-shell-dangerous nie czeka na linię bazową — odpala natychmiast na poleceniach pasujących do ścieżek poświadczeń, zmiennych środowiskowych o nazwach sugerujących poświadczenia, ruchu sieciowego albo długich zakodowanych bloków.
Jeśli wolisz nie mieć tej funkcji w ogóle, Claude Code potrafi ją wyłączyć globalnie przez "disableSkillShellExecution": true w ustawieniach, co jest najbardziej przydatne w ustawieniach zarządzanych, gdzie użytkownicy nie mogą tego nadpisać.
Kiedy audyt drskill wprowadza w błąd
Dział zatytułowany „Kiedy audyt drskill wprowadza w błąd”Czysty skan nie oznacza czystego loadoutu. Ograniczenie do zapamiętania: skille Claude Code dołączone do zainstalowanych pluginów nie są jeszcze skanowane. Jeśli twój zespół dystrybuuje skille jako pluginy, drskill scan raportuje ułamek tego, co agent ładuje, a zielony wynik nie mówi nic o reszcie. Katalogi .claude/commands/ używają tej samej składni poleceń shellowych uruchamianych przy wywołaniu co skille i również nie są wykrywane, więc ich osadzone polecenia są niewidoczne dla obu sprawdzeń injection-shell-*.
Sprawdzenia injection zgłaszają powierzchnie, nie intencje. Analiza statyczna nie udowodni, że skill jest nieszkodliwy ani że jest wrogi. Znalezisko nie jest oskarżeniem, a czysty skan nie jest gwarancją bezpieczeństwa. Dlatego każde znalezisko injection cytuje dokładne linie, które oceniało — werdykt należy do ciebie. Dołączone pliki binarne albo większe niż 1 MiB są odnotowywane, ale nie skanowane pod kątem treści, i raport mówi o tym wprost, gdy tak się stanie. Używaj tego obok skanera przedinstalacyjnego, a nie zamiast niego.
Sprawdzenia opisów są heurystykami. Progi są dostrojone tak, by milczeć na dobrze napisanych skillach, ale opposing-imperatives dopasowuje celowo restrykcyjnie i przegapi sparafrazowane konflikty, a description-overlap zgłosi decyzje uznaniowe. --deep istnieje dokładnie po to: wysyła każdą zgłoszoną parę do modelu, który ocenia, czy skille są naprawdę odrębne, a gdy każda para w klastrze wraca jako odrębna, ostrzeżenie schodzi do notatki, która nie oblewa już --ci.
Głębokie sprawdzenia i połączenia są opcjonalne nie bez powodu. --deep wysyła do dostawcy modelu nazwy i opisy skilli — nic więcej i nic w ogóle bez tej flagi. --mcp-connect uruchamia każdy skonfigurowany serwer i wykonuje z nim handshake, żeby wyliczyć jego narzędzia; nigdy nie wywołuje narzędzia i nie czyta zasobów ani promptów, ale to nadal połączenie, na które się decydujesz. Wiedz, które z nich włączyłeś.
Rejestr i cache nie są podpisane. Każdy, kto może commitować do repozytorium, może uciszyć ostrzeżenie, edytując drskill.toml albo dodając werdykt do .drskill/cache/. Przeglądaj zmiany w obu tak, jak przeglądasz zmiany w kodzie, bo inaczej bramka staje się dekoracją.
Skill z aktywnym znaleziskiem injection nigdy nie dostaje obniżenia za nakładanie się. Jego pary nadal są oceniane, a werdykty nadal drukują się jako dowód, ale ostrzeżenie zostaje ostrzeżeniem. Jeśli zastanawiasz się, dlaczego jeden klaster zszedł do notatki, a inny nie, zwykle właśnie o to chodzi.