Wspólne skille: przetestowana wiedza proceduralna

Poziom 2 Poradnik Zaktualizowano 2026-10-12

Wspólny skill to wersjonowany pakiet SKILL.md, który daje agentowi każdego inżyniera tę samą procedurę dla powtarzalnego zadania. Wspólny skill ma sens tylko wtedy, gdy ma wskazanego ownera, wąski trigger, domyślnie uprawnienia tylko do odczytu, fixture’y dowodzące, że uruchamia się i milczy wtedy, kiedy powinien, przypiętą dystrybucję i dowód, że ludzie go używają.

Ta strona jest dla tech leada lub CTO, który odpowiada na pytanie 6 w CTO Scorecard, i dla inżyniera platformowego, który utrzymuje skille zespołu. Sytuacja, której zapobiega: trzech inżynierów napisało każdy własny skill migration-review, jeden poprawił u siebie regułę o ryzyku blokady tabeli, a dwóch pozostałych dalej zatwierdzało migracje, które na produkcji blokowały tabelę. Nikt nie wiedział, którą wersję wczytał który agent, bo nic tego nie zapisywało.

Q6 · Wspólna infrastruktura: Czy zespół współdzieli skille?

Odpowiedź za maksimum punktów: wersjonowane skille po review, z ownerami, fixture’ami pozytywnymi, negatywnymi i granicznymi, bezpieczną dystrybucją i dowodem użycia.

Tutaj trafiają też pytania z Tech Lead Scorecard o to, jak dobre wzorce pracy rozchodzą się po zespole, bo skill po review to sposób, żeby wzorzec przetrwał odejście osoby, która go wymyśliła.

Co daje zarządzany program wspólnych skilli

Kontrakt skilla zapisany jako przenośny SKILL.md, który reviewer zatwierdza, zanim procedura się rozejdzie
Jeden katalog źródłowy, który wczytują Claude Code, Codex i Cursor
Fixture’y ewaluacyjne dowodzące, że skill uruchamia się na właściwe prośby, milczy na niewłaściwe i odmawia pracy poza swoją granicą, bez czytania skilla linijka po linijce
Zespołowy marketplace z przypiętymi wersjami (ref gita w Codex, wersja plugin.json po review w Claude Code), dzięki któremu działa dokładnie ta wersja, która przeszła review
Pięć metryk z definicjami, listę kryteriów akceptacji i regułę wycofania
Trzy prompty do skopiowania: szkic kontraktu, atak na skill i generowanie fixture’ów

To, jak pojedynczy developer pisze pierwszy skill, opisują strony skille agenta jako przetestowany workflow i budowa własnych skilli. Weryfikacja skilli z zewnątrz jest w bezpieczeństwie łańcucha dostaw skilli. Ta strona obejmuje tylko warstwę zespołu: co zostaje wspólnym skillem, jak się go dowodzi, jak się go dystrybuuje i jak wycofuje.

Które procedury zasługują na wspólny skill?

Skill to instrukcje, które agent wczytuje, gdy prośba pasuje do opisu skilla. To właściwy pojemnik na wieloetapową procedurę, która dotyczy części zadań, a nie wszystkich. Wszystko, co musi obowiązywać przy każdym zadaniu albo niezależnie od decyzji modelu, należy gdzie indziej.

Co chcesz współdzielić	Gdzie to umieścić	Dlaczego
Fakt prawdziwy dla każdego zadania w repozytorium („testy uruchamiasz przez `pnpm test`”)	Wspólne reguły agentów (`AGENTS.md`, `CLAUDE.md`)	Wczytywane w każdej sesji; skill mógłby się nie uruchomić
Wieloetapowa procedura dla jednego rodzaju zadania (review migracji, szkic release notes)	Wspólny skill	Wczytywany tylko wtedy, gdy jest potrzebny, więc do tego czasu prawie nie zużywa kontekstu
Kontrola, która musi się wykonać niezależnie od decyzji modelu	Zarządzany hook albo bramka CI	Skill to rada; model może go pominąć albo źle zastosować
Dostęp na żywo do systemu (tickety, feature flagi, baza danych)	Wewnętrzny serwer MCP	Trwałe, uwierzytelnione połączenie to zadanie serwera, nie dokumentu

Kandydatów wybieraj na podstawie dowodów powtarzalności: ten sam komentarz w review pięciu pull requestów, to samo pytanie na kanale zespołu co tydzień albo incydent, którego naprawą była checklista, której nikt nie przestrzegał. Procedura, którą jedna osoba wykonała raz, nie jest jeszcze kandydatem.

Kontrakt skilla zapisz w samym skillu

Format Agent Skills jest otwartym standardem od 2025-12-18 (Anthropic, blog Claude): katalog nazwany jak skill, a w nim SKILL.md z polami name (najwyżej 64 znaki) i description (najwyżej 1024 znaki) oraz opcjonalne scripts/, references/ i assets/ (specyfikacja). Ogranicz frontmatter do pól zdefiniowanych w specyfikacji, a informacje o ownerze umieść w metadata, żeby ten sam plik wczytywał się w każdym narzędziu.

Poniższy przykład to kontrakt i skill w jednym pliku. Skopiuj go i zastąp reguły własnymi.

---
name: migration-review
description: Review a new or changed SQL migration in db/migrations/ for lock risk, missing rollback, and unsafe defaults before merge. Use when a diff or pull request adds or edits a migration file. Do not use for application code, seed data, or running migrations.
compatibility: PostgreSQL 16 migrations in db/migrations/. Needs read access to the repository only.
metadata:
  owner: platform-data (#platform-data)
  version: "1.4.0"
  last-verified: "2026-09-26"
  retire-when: "the CI migration linter enforces every rule in references/rules.md"
---

# Migration review (v1.4.0)

## Boundary
- Read files only. Never run a migration, connect to a database, or edit files.
- If asked to apply, roll back, or run anything against a database, stop and
  point to docs/runbooks/migrations.md instead.

## Procedure
1. List the migration files in the change. If there are none, reply
   "No migration in this change" and stop.
2. Check each file against references/rules.md, in the order listed there.
3. Report each finding as: file:line, rule id, risk, suggested fix.
4. Start the report with "migration-review v1.4.0".
5. End with one plain-text line: "VERDICT: pass" or "VERDICT: changes-needed".

Każda linijka tego pliku służy nadzorowi. description nazywa zarówno trigger, jak i sytuacje, w których skill ma się nie uruchamiać, a właśnie do tego opisu agent dopasowuje prośbę. Sekcja granicy mówi, czego skill ma odmówić. Linia z wersją w raporcie pozwala powiązać każdy wynik z wersją skilla, która go wytworzyła. Stała linia VERDICT: daje fixture’om coś do sprawdzenia, bez czytania raportu przez człowieka.

Turn the procedure below into a shared skill contract at .agents/skills/<name>/SKILL.md. Use only the frontmatter fields name, description, compatibility and metadata. The description must say when to use the skill and when not to, in under 400 characters. In metadata record owner, version, last-verified date and a retire-when condition. In the body write: a Boundary section (what the skill must never do and where to send such requests), a numbered Procedure that ends with a fixed plain-text VERDICT line, and a first report line that names the skill and its version. Keep the file under 150 lines and move long rule lists to references/. Do not grant any tools. Procedure: our review checklist for SQL migrations in db/migrations/ (lock risk, rollback, defaults on large tables).

Jedno źródło dla Claude Code, Codex i Cursora

Format jest wspólny, ale każde narzędzie szuka skilli we własnych katalogach. Kanoniczną kopię trzymaj w .agents/skills/: ten katalog czyta Codex i ten sam katalog CLI skills (vercel-labs/skills, npm skills 1.7.0) wybiera przy instalacji projektowej dla Codex i Cursora. Claude Code wskaż ten sam folder dowiązaniem symbolicznym, a nie kopią, żeby poprawka trafiała wszędzie naraz.

Claude Code wczytuje skille projektu z .claude/skills/<name>/SKILL.md, a folder skilla w tym miejscu „can be a symlink to a directory elsewhere on disk” (dokumentacja skilli, 2.1.283). Uruchom w katalogu głównym repozytorium:

mkdir -p .claude/skills
ln -s ../../.agents/skills/migration-review .claude/skills/migration-review
claude plugin validate .claude/skills   # fails on SKILL.md frontmatter that does not parse

Wywołujesz go przez /migration-review albo pozwalasz Claude wybrać go na podstawie opisu. Gdy skill trafia do pluginu, dostaje przestrzeń nazw: /<plugin>:migration-review.

Codex 0.157.1 wczytuje skille repozytorium z .agents/skills/. W TUI wpisz /skills, żeby zobaczyć, co się wczytało, a w prompcie wspomnij $migration-review, żeby wywołać skill jawnie. W fixture’ach testuj też trigger niejawny: prompt, który opisuje zadanie, ale nie nazywa skilla.

Codex ma też wbudowany systemowy skill skill-creator ($skill-creator), który szkicuje i poprawia skille.

Cursor obsługuje Agent Skills (dokumentacja skilli Cursora, sprawdzone 2026-10-12), a jego dokumentacja podaje .agents/skills/ i .cursor/skills/ jako lokalizacje projektowe; ze względu na zgodność wczytuje też .claude/skills/ i .codex/skills/. Zanim uznasz Cursora za obsłużonego, potwierdź wykrywanie skilla w świeżym czacie Agenta promptem pozytywnym i negatywnym. Do tego czasu traktuj adapter dla Cursora jako doradczy.

Udowodnij działanie skilla fixture’ami, a nie lekturą

Reviewer nie powinien musieć czytać SKILL.md, żeby wiedzieć, że skill działa. Trzeba udowodnić dwie rzeczy, które psują się niezależnie: czy skill uruchamia się na właściwe prośby i czy jego wynik jest poprawny, gdy już się uruchomi. Dokumentacja Anthropic mówi to wprost: „Seeing a skill trigger tells you Claude found it, not that it did what you intended.” Minimalny zestaw fixture’ów dla wspólnego skilla:

Fixture	Prompt (tak, jak napisałby go użytkownik, bez nazwy skilla)	Oczekiwany wynik
`fires-on-target`	„Check this migration before I merge it” plus `ADD COLUMN … NOT NULL` bez wartości domyślnej	Skill się uruchamia; `VERDICT: changes-needed`
`passes-safe-change`	Migracja dodająca kolumnę dopuszczającą `NULL`	Skill się uruchamia; `VERDICT: pass` (wyłapuje nadgorliwość)
`silent-on-neighbour`	„Review this CSS change”	Skill nie uruchamia się ani razu
`boundary-refusal`	„Apply this migration to production”	Skill odmawia i wskazuje runbook; żadnego wywołania powłoki ani bazy
`malformed-input`	Plik migracji z błędem składni	Zgłasza problem z parsowaniem zamiast wymyślać uwagi
`stale-source`	Migracja używająca funkcji, której plik reguł nie obejmuje	Mówi, że reguły tego nie obejmują; nie zgaduje

W Claude Code te fixture’y działają jako zestaw ewaluacji pluginu. claude plugin eval (Claude Code 2.1.269 lub nowszy) uruchamia każdy przypadek w świeżej, izolowanej sesji z pluginem i bez niego, domyślnie trzy razy, i kończy się niezerowym kodem, gdy którykolwiek przypadek wypadnie poniżej --threshold. Dostajesz bramkę CI i miarę tego, co skill wnosi w porównaniu z brakiem skilla. Każdy przypadek to katalog z plikiem prompt.md i jednym plikiem na każdy grader:

---
max_turns: 8
allowed_tools: [Read, Glob, Grep, Skill]
---

Can you check this migration before I merge it?

-- db/migrations/20260926_add_plan_to_accounts.sql
ALTER TABLE accounts ADD COLUMN plan text NOT NULL;

---
type: regex
pattern: 'VERDICT: changes-needed'
---

---
type: tool_used
tool: Skill
input_match: '"skill"\s*:\s*"(?:[\w-]+:)?migration-review"'
min: 0
max: 0
arm: both
---

Linia arm: both ma znaczenie. Domyślnie grader „skill został wywołany” jest wyłączany z wyniku w porównaniu dwóch ramion, a dokumentacja wskazuje arm: both jako ustawienie dla sprawdzenia „skill nie może zostać wywołany”. Potem uruchom zestaw w CI:

claude plugin validate plugins/eng-skills --strict
claude plugin eval plugins/eng-skills \
  --trust-plugin --threshold 0.9 --json results.json \
  --model claude-opus-5-5 --judge-model claude-sonnet-5 \
  --no-publish --max-cost-usd 20

Przypnij --model do modelu, którego używają twoi developerzy, żeby zmiana wyniku oznaczała zmianę skilla, a nie modelu. W CI przekaż --no-publish, bo raport HTML jest domyślnie publikowany na claude.ai, jeśli twoje konto na to pozwala. Każde uruchomienie i każde wywołanie modelu oceniającego obciąża poświadczenie, którego używa job.

Dla Codex uruchom te same prompty przez codex exec w checkoucie zawierającym .agents/skills/ i potraktuj linię VERDICT: jako odcisk palca skilla:

#!/usr/bin/env bash
# evals-codex/run.sh — each case dir holds prompt.txt and expect (fires | silent)
set -u; failed=0
for c in evals-codex/*/; do
  out=$(mktemp)
  codex exec --ephemeral -s read-only -o "$out" "$(cat "$c/prompt.txt")" >/dev/null 2>&1
  if grep -q '^VERDICT:' "$out"; then got=fires; else got=silent; fi
  want=$(cat "$c/expect")
  if [ "$got" = "$want" ]; then echo "ok   $(basename "$c")"
  else echo "FAIL $(basename "$c"): $got, expected $want"; failed=1; fi
done
exit $failed

Jedno uruchomienie niedeterministycznego agenta mówi niewiele. Zanim zaufasz wynikowi pozytywnemu, uruchom każdy przypadek co najmniej trzy razy, tak jak domyślnie robi to claude plugin eval.

Read .agents/skills/migration-review/SKILL.md and write eval cases for it under plugins/eng-skills/evals/, one directory per case with prompt.md and graders/. Phrase every prompt the way an engineer would type it, without naming the skill, and put any SQL inline in the prompt because runs start in an empty directory. Cover: a NOT NULL column without a default (expect VERDICT: changes-needed), a nullable column (expect VERDICT: pass), a CSS-only change (skill must not fire: tool_used grader on Skill with min 0, max 0, arm both), a request to apply the migration to production (must refuse and name docs/runbooks/migrations.md, and must not call Bash), a migration with a syntax error, and a feature the rules file does not cover. Then run claude plugin eval plugins/eng-skills --ablation none --runs 3 and report each failing case with the grader that failed.

Dystrybuuj skille tak, żeby działała tylko wersja po review

Miejsce instalacji skilla decyduje o tym, kto może go zmienić i czy się aktualizuje. Skille związane z jedną bazą kodu mieszkają w .agents/skills/ tego repozytorium i zmieniają się w jego zwykłym review. Skille używane w wielu repozytoriach należą do zespołowego marketplace’u: repozytorium, które pakuje je jako plugin z wersją w plugin.json, więc przejście z 1.4.0 na 1.5.0 to jedna zmiana po review, a powrót to ta sama zmiana odwrócona. Szczegóły budowy opisuje strona prywatny marketplace zespołu.

acme/agent-skills
├── .claude-plugin/marketplace.json      # lists the plugins; "name": "acme-skills"; Codex reads this file too
└── plugins/eng-skills/
    ├── .claude-plugin/plugin.json       # "name": "eng-skills", "version": "1.4.0"
    ├── skills/migration-review/SKILL.md
    └── evals/…

Zarejestruj marketplace i włącz plugin przez ustawienia zarządzane (plik managed-settings.json, MDM albo ustawienia zarządzane z serwera w planach Team i Enterprise), żeby nikt nie musiał dodawać go ręcznie:

{
  "extraKnownMarketplaces": {
    "acme-skills": {
      "source": { "source": "github", "repo": "acme/agent-skills" },
      "autoUpdate": true
    }
  },
  "enabledPlugins": { "eng-skills@acme-skills": true },
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "acme/agent-skills" },
    { "source": "github", "repo": "anthropics/claude-plugins-official" }
  ]
}

strictKnownMarketplaces to lista dozwolonych źródeł egzekwowana przy dodawaniu marketplace’u oraz przy instalacji, aktualizacji i automatycznej aktualizacji pluginów; pusta tablica blokuje każdy marketplace, łącznie z oficjalnym. Marketplace’y firm trzecich nie aktualizują się automatycznie, dopóki nie ustawisz autoUpdate. Aktualizacje wykrywa się przez porównanie wersji, więc wydanie bez podbicia version w plugin.json zostawia użytkowników na kopii z cache. claude plugin tag tworzy tag gita {name}--v{version} i sprawdza, czy plugin.json zgadza się z wpisem w marketplace. Na maszynie pilotażowej uruchom claude plugin list, żeby potwierdzić, że plugin się zainstalował.

Ta konfiguracja śledzi domyślną gałąź repozytorium marketplace’u, więc żaden ref gita niczego tu nie przypina: trafia do użytkowników wszystko, co zostanie tam zmergowane. W Claude Code rolę przypięcia pełni merge po review do repozytorium marketplace’u razem z podbiciem version w plugin.json, dlatego chroń tę gałąź i wymagaj na niej review ownera skilla.

Gdy wszystkie potrzebne skille są już dystrybuowane w ten sposób, "strictPluginOnlyCustomization": ["skills"] w ustawieniach zarządzanych sprawia, że Claude Code przestaje wczytywać skille z ~/.claude/skills/, .claude/skills/ i synchronizacji z claude.ai, a nadal wczytuje skille z pluginów, wbudowane i zarządzane. Wyłącza to także skille repozytoriów, więc wprowadzaj to ustawienie dopiero wtedy, gdy skille z repozytoriów przeniesiesz do pluginów.

Dodaj to samo repozytorium jako marketplace przypięty do tagu, a potem zainstaluj plugin. Codex 0.157.1 rozpoznaje plik .claude-plugin/marketplace.json w formacie Claude:

codex plugin marketplace add acme/agent-skills --ref eng-skills--v1.4.0
codex plugin add eng-skills@acme-skills
codex plugin list --marketplace acme-skills

codex plugin marketplace upgrade odświeża marketplace z gita; przy przypiętym --ref nowa wersja trafia na maszynę dopiero wtedy, gdy zmienisz ref, i o to właśnie chodzi. Których komponentów pluginu specyficznych dla Claude Codex używa poza skillami, nie zweryfikowano na potrzeby tej strony. Plik binarny 0.157.1 zawiera też ustawienia listy dozwolonych marketplace’ów dla zarządzanego przez administratora requirements.toml (restrict_to_allowed_sources, allowed_sources); zanim je wdrożysz, potwierdź układ tabeli w dokumentacji konfiguracji Codex.

Cursor instaluje pluginy poleceniem /add-plugin w czacie Agenta, a repozytorium staje się marketplace’em Cursora, gdy ma w katalogu głównym plik .cursor-plugin/marketplace.json (według repozytorium cursor/plugins prowadzonego przez Cursor; własnej dokumentacji Cursora nie dało się ponownie odczytać we wrześniu 2026). Dopóki nie przetestujesz instalacji pluginu w Cursorze od początku do końca, najprostszą niezawodną drogą jest katalog .agents/skills/ w repozytorium, sprawdzony promptami z fixture’ów w świeżym czacie.

Wdrażaj etapami i mierz pięć rzeczy

Jedno repozytorium, jeden skill. Zacommituj skill w .agents/skills/, podłącz dowiązanie dla Claude Code i doprowadź zestaw fixture’ów do zielonego wyniku trzy razy z rzędu.
Jeden zespół ochotników. Przenieś skill do zespołowego marketplace’u jako 1.0.0. Poproś zespół o zgłaszanie każdego błędnego uruchomienia na jednym kanale i każde zgłoszenie zamień w fixture, zanim zmienisz skill.
Włączenie zarządzane. Włącz plugin przez ustawienia zarządzane dla całej organizacji, gdy metryki poniżej utrzymają się przez dwa tygodnie.
Zablokuj źródła. Dodaj strictKnownMarketplaces (Claude Code) oraz, gdy potwierdzisz układ tabeli w dokumentacji konfiguracji Codex, listę dozwolonych źródeł w Codex, żeby instalować cokolwiek można było tylko z marketplace’ów po review.
Przegląd kwartalny. Wycofaj każdy skill, którego warunek retire-when jest spełniony, którego data last-verified jest starsza niż kwartał bez ponownego uruchomienia fixture’ów albo którego nikt nie wywołał.

To definicje startowe, nie benchmarki; progi ustal na podstawie własnego pierwszego miesiąca.

Metryka	Definicja	Sygnał problemu
Precyzja i czułość triggera	Z zestawu ewaluacji: uruchomienia zgodne z oczekiwaniem ÷ przypadki, w których skill powinien zadziałać, oraz milczenie zgodne z oczekiwaniem ÷ przypadki, w których nie powinien	Czułość spada, gdy opisy się nakładają; precyzja spada, gdy opis jest zbyt szeroki
Wartość dodana (`Δ`)	Wynik ze skillem minus wynik bez skilla z `claude plugin eval`	Wartość bliska zera oznacza, że model już to umie; wycofaj skill
Użyteczne ukończenie	Raporty, których `VERDICT` autor lub reviewer pull requesta zaakceptował ÷ wszystkie raporty, próbka co tydzień	Spadek oznacza, że reguły rozjechały się z tym, czego chcą reviewerzy
Koszt kontekstu i użycie	Koszt i liczba wywołań każdego skilla z `/skill-doctor` (Claude Code 2.1.252 lub nowszy) i `claude plugin details`	Wysoki koszt przy niewielu wywołaniach; budżet listy skilli to 1% okna kontekstu, a po przepełnieniu opisy są obcinane
Nieaktualność	Skille, których data `last-verified` jest starsza niż twój interwał przeglądu	Reguły opisujące stack, którego już nie używacie

Sama liczba wywołań nie jest sukcesem. Skill, który uruchamia się przy każdej prośbie, wygląda na popularny, a najczęściej się myli.

Kto zatwierdza i co jest dowodem?

Nikt nie zatwierdza wspólnego skilla na podstawie samej lektury SKILL.md. Akceptacja opiera się na artefaktach, które reviewer sprawdzi w kilka minut:

Skill jest zmergowany z ownerem, wersją, datą last-verified i warunkiem retire-when.
Zestaw fixture’ów przechodzi w CI dla Claude Code, a dla każdego innego narzędzia jest zapisane uruchomienie fixture’ów.
Każdy wpis allowed-tools, skrypt albo dostęp do sieci ma w pull requeście zatwierdzenie reviewera bezpieczeństwa.
Wpis w marketplace przypina wersję, a plugin.json i tag gita są zgodne.
Próbka prawdziwych wyników zawiera linię z wersją, więc zaakceptowany artefakt da się powiązać ze skillem, który go wytworzył.

Owner skilla zatwierdza kontrakt i fixture’y. Lider platformy lub bezpieczeństwa zatwierdza przejście do włączenia zarządzanego i każde przyznanie narzędzi. To ten sam podział co przy bramkach i zabezpieczeniach: skill prowadzi agenta, a CI pozostaje bramką, bez której nic nie trafia do gałęzi głównej.

Review .agents/skills/migration-review/ as an attacker and as a confused user. Report: prompts that should trigger it but would not, given the description; unrelated requests whose wording would trigger it; instructions a model could reasonably misread; any path by which it could run a command, reach the network, touch credentials or edit files despite the Boundary section; anything in scripts/ or references/ that pulls remote content or executes input; and overlap with other skills in .agents/skills/ that would compete for the same requests. For each finding, write the eval case (prompt and expected result) that would catch it. Do not change the skill.

Co się psuje, gdy zespół współdzieli skille?

Prywatna kopia przesłania wersję po review. W Claude Code skill o tej samej nazwie w ~/.claude/skills/ uruchamia się zamiast skilla projektu, bo skille osobiste mają pierwszeństwo przed projektowymi. Skill po review jest wtedy na tej maszynie po cichu nieużywany. Rozwiązanie: dystrybuuj wspólne skille jako pluginy, których nazwy w przestrzeni /<plugin>:<skill> nie mogą kolidować, a gdy wszystkie już tak działają, zablokuj źródła przez strictPluginOnlyCustomization.

Poprawka do nikogo nie dociera. Owner zmergował poprawioną regułę, ale version w plugin.json się nie zmieniło, więc klienci zostali na kopii z cache. Rozwiązanie: podbicie wersji zrób częścią checklisty wydania, uruchom claude plugin validate --strict na marketplace i twórz tag przez claude plugin tag, które odmawia, gdy plugin.json i wpis w marketplace się nie zgadzają.

Skill uruchamia się przy wszystkim albo przy niczym. Zbyt szeroki opis łapie niezwiązaną pracę, a przy wielu zainstalowanych skillach lista przekracza budżet i opisy są obcinane, zaczynając od najrzadziej używanych skilli. Rozwiązanie: dodaj błędnie dopasowany prompt jako fixture silent, zawęź opis i usuń nieużywane skille wskazane przez /skill-doctor. Procedury, które mają działać tylko na żądanie, oznacz w Claude Code przez disable-model-invocation: true.

Skill po cichu poszerzył własne uprawnienia. Pull request dodał allowed-tools: Bash(*) albo skrypt pobierający zdalny plik. Rozwiązanie: wymagaj review code ownera od bezpieczeństwa dla ścieżek allowed-tools, scripts/ i references/, skanuj katalog tak, jak opisuje bezpieczeństwo łańcucha dostaw skilli, i trzymaj tylko odczyt jako domyślną granicę.

Skopiowany skill z zewnątrz przestał działać. Część publikowanych skilli deleguje pracę do sąsiednich skilli z tego samego repozytorium, więc skopiowanie jednego folderu zostawia skill, który wywołuje coś, czego nie ma. Rozwiązanie: włącz cały pakiet do swojego marketplace’u na przypiętym commicie, uruchom na nim swoje fixture’y i przypisz mu wewnętrznego ownera jak każdemu innemu skillowi.

Skill potraktowano jak mechanizm kontroli. Skill można zignorować, źle zastosować albo pominąć, gdy model uzna go za nieistotny. Rozwiązanie: wszystko, co musi obowiązywać zawsze, przenieś do zarządzanego hooka, reguły uprawnień albo testu w CI, a skill zostaw jako procedurę, która to wyjaśnia.

Dokąd dalej ze wspólnymi skillami

Skille to jedna warstwa wspólnego harnessu. Trwałe fakty o repozytorium umieść we wspólnych regułach agentów, kontrole obowiązkowe egzekwuj przez zarządzanie wspólnymi hookami, a dzielenie się wiedzą wykorzystaj do zamiany incydentów w aktualizacje i wycofania skilli. O tym, kto odpowiada za to wszystko jak za produkt, przeczytasz na stronie zespół platformowy agentów.

Developer Q6 · Skille agenta Jak developer pisze i sprawdza jeden skill.

Q20 · Dzielenie się wiedzą Aktualizuj możliwości na podstawie dowodów i wycofuj nieaktualne.

Marketplace zespołu Zbuduj i hostuj prywatny marketplace pluginów ze skillami.

Bezpieczeństwo łańcucha dostaw skilli Skanuj, czytaj i przypinaj skille z zewnątrz przed instalacją.