Wydobywanie skilli: od 3500 kandydatów do 466 zdolności

Liczby w tym wpisie odzwierciedlają system w momencie publikacji (styczeń 2026). Aktualne dane znajdziesz na naszej stronie zespołu.

Problem 3500 skilli

Gdy zaczęliśmy budować system orkiestracji agentów, natrafiliśmy na ciekawe wyzwanie: istnieją tysiące potencjalnych skilli rozproszonych po ekosystemie AI. Repozytoria GitHub, dokumentacja dostawców, projekty społecznościowe, wewnętrzne wzorce — skille istnieją wszędzie. Ale które mają znaczenie? Które działają? I jak utrzymać spójną bibliotekę skilli, z której agenci faktycznie mogą korzystać?

Nasza odpowiedź: systematyczna pętla wydobywania i wchłaniania.

Liczby dziś

Zaledwie nieco ponad trzy miesiące po tym, jak Anthropic uruchomił Agent Skills 16 października 2025, oto gdzie byliśmy w momencie publikacji tego wpisu, 27 stycznia 2026:

Metryka	Liczba
Zidentyfikowani kandydaci	3500+
Przyjęte skille	466
Skille dostawców	373
Skille wewnętrzne	93
Aktywni dostawcy	25+
Średnia liczba tokenów na skill	2834
Przywoływane narzędzia	89
Unikalne tagi	635

Przejrzeliśmy ponad 3500 kandydatów na skille. Przyjęliśmy 466. To wskaźnik adopcji na poziomie 13% — i ta selektywność jest zamierzona.

System poziomów wiedzy

Nie wszystkie skille są sobie równe. Organizujemy je w pięć warstw wiedzy (K0-K4), z których każda reprezentuje inny zakres zastosowania:

K0: Fundamenty (uniwersalne)

Skille, które powinien mieć każdy agent. Reprezentują zdolności „dobrego myśliciela”, które działają wszędzie.

foundations/
├── test-first-discipline       # TDD: Red-Green-Refactor
├── evidence-based-completion   # Verify before claiming done
├── systematic-debugging        # Root cause methodology
├── structured-planning         # Break work into tasks
└── context-budget-awareness    # Manage token consumption

Skille K0 są przenośne do dowolnego projektu, dowolnej domeny, dowolnego stosu. Kodują uniwersalne wzorce poznawcze.

K1: Tożsamości (dyscyplina)

Skille „dobrego inżyniera” lub „dobrego badacza”, mające zastosowanie w wielu projektach w ramach danej dyscypliny.

identities/
├── research-workflows          # Multi-source research
├── web-extraction-playbook     # Content extraction
├── code-review                 # PR review patterns
└── cli-interface-standards     # CLI design patterns

K2: Domeny (ekspertyza przedmiotowa)

Skille „dobrego eksperta baz danych” lub „dobrego inżyniera bezpieczeństwa”, przenośne w ramach danej dziedziny.

domains/
├── schema-migration-workflow   # Safe migration patterns
├── rpc-validation-checklist    # RPC health checks
├── auth-validation-checklist   # JWT/OAuth patterns
└── secrets-audit-checklist     # Credential scanning

K3: Stosy (technologia)

Skille „dobrego użytkownika Supabase” lub „dobrego dewelopera Cloudflare” dla konkretnych stosów technologicznych.

stacks/
├── maguyva-quickstart          # Our semantic search patterns
├── cloudflare-deployment       # Workers/Pages deployment
└── mcp-tool-best-practices     # MCP tool selection

K4: Projekt (organizacja)

Skille specyficzne dla naszej organizacji i przepływów pracy.

project/
├── agent-creation-workflow     # How we build agents
├── skill-authoring-workflow    # How we write skills
├── mining-session-workflow     # This very process
└── vendor-skill-evaluation     # Evaluation rubrics

Pętla wydobywcza

Faza 1: odkrywanie

Skille pochodzą zewsząd:

Repozytoria dostawców: AWS, Anthropic, Cloudflare, Supabase i współtwórcy społecznościowi publikują kolekcje skilli. Śledzimy ponad 25 korzeni dostawców.

Projekty społecznościowe: GitHub jest pełen szablonów Claude Code, wzorców agentów i definicji przepływów pracy.

Wzorce wewnętrzne: gdy nasz zespół rozwiązuje problemy, powstają wzorce. Zostają one sformalizowane w skille.

Wydobywanie z dokumentacji: dokumentacja techniczna często zawiera niejawne skille — procedury, listy kontrolne, drzewa decyzyjne.

Odkrywanie jest ciągłe. Używamy backlogu skilli, żeby śledzić kandydatów przed formalną oceną.

Faza 2: ocena

Każdy kandydat przechodzi przez tę samą rubrykę:

adoption_criteria:
  - fills_real_gap: true      # We lack this capability
  - well_structured: true     # Progressive disclosure
  - actively_maintained: true # Commits in last 6 months
  - portable: true            # Not hyper-specific
  - tested: true              # Evidence of usage

Wszystkie pięć kryteriów produktowych musi przejść. Dlatego 87% kandydatów zostaje odrzuconych.

Następnie każdy kandydat przechodzi przez osobny przegląd zaufania. Nie traktujemy oficjalnego repozytorium dostawcy, znanego opiekuna społecznościowego i przypadkowego repozytorium GitHub jako równoważnych źródeł prawdy.

trust_review:
  vendor_credibility:
    - ownership_verified       # Official vendor, known maintainer, or internal source
    - maintenance_signal       # Recent commits, issue response, release history
    - adoption_signal          # Evidence of real use, stars alone are not enough
    - provenance_clear         # We can trace where the skill came from
  prompt_injection_scan:
    - hidden_instruction_check # Buried "ignore previous instructions" patterns
    - exfiltration_check       # Prompts that try to leak files, secrets, or context
    - authority_check          # Claims of priority over system or developer rules
  script_audit:
    - inspect_scripts          # Read shell/python/js helpers before adoption
    - network_and_exec_review  # curl|bash, remote downloads, subprocess execution
    - file_and_secret_review   # Env vars, credential access, broad file writes
    - destructive_action_check # rm, reset, overwrite, or unsafe automation

Zaufani dostawcy otrzymują lżejszy przegląd pochodzenia, ale nie wolną przepustkę. Niezaufane lub nieznane źródła otrzymują głębszy ręczny audyt, a dołączonych skryptów nie uruchamiamy, dopóki nie zostaną przeczytane, zakresowane i sklasyfikowane jako bezpieczne.

Analiza luk: przed przyjęciem przeszukujemy nasz rejestr:

uv run orkestra skills search "<capability>"

Jeśli już to mamy, nie potrzebujemy tego. Jeśli mamy coś zbliżonego, możemy scalić zamiast przyjmować.

Ocena głębi i standardów: oceniamy też, jak w pełni kandydat wykorzystuje model agent-skill. Samotny SKILL.md wciąż może być użyteczny, ale głębsze skille są cenniejsze, gdy oddzielają instrukcje od referencji, skryptów i zasobów w sposób, do którego zachęca agentskills.io.

skill_depth:
  - level_1: SKILL.md only                     # Single instruction file
  - level_2: SKILL.md + strong description     # Clear triggers and scope
  - level_3: adds references/                  # Load docs only when needed
  - level_4: adds atomic scripts/              # Small, reviewable helpers
  - level_5: adds assets/examples/templates    # Full progressive disclosure
depth_signals:
  - standards_adherence        # Structure aligns with agentskills.io conventions
  - reference_quality          # Curated references, not giant context dumps
  - script_atomicity           # Focused helpers, not opaque monoliths
  - tool_boundary_clarity      # Clear limits on what the skill can execute
  - community_signal           # Stars/forks/users help, but only as a weak boost

Gwiazdki na GitHubie mogą nieco podnieść wynik wiarygodności, ale nigdy nie ratują płytkiego lub niebezpiecznego skilla. Repozytorium z dużą liczbą gwiazdek z jednym niejasnym SKILL.md i nieprzejrzystymi skryptami punktuje niżej niż mniejsze repozytorium z precyzyjnym opisem, wyselekcjonowanym references/ i atomowymi pomocnikami, które faktycznie wykorzystują pełną zdolność skilla.

Analiza strukturalna: sprawdzamy jakość skilla:

wc -l vendor/<repo>/<skill>/SKILL.md  # Size check
ls vendor/<repo>/<skill>/scripts/     # Supporting files
ls vendor/<repo>/<skill>/references/  # Bundled docs

Jeśli kandydat zawiera skrypty, ten przegląd staje się bardziej rygorystyczny. Dobry skill nie jest tylko użyteczny; musi być czytelny, ograniczony i bezpieczny do przekazania agentowi. Sam ten filtr bezpieczeństwa dyskwalifikuje znaczącą część skądinąd interesujących kandydatów.

Faza 3: wchłanianie

Gdy skill przechodzi ocenę, wchodzi do rejestru. Ale skille nigdy nie są przyjmowane bez zmian. Są modyfikowane, żeby pasować do naszego systemu.

Modyfikacje przy adopcji:

1. Normalizacja metadanych: każdy skill otrzymuje nasz schemat frontmatter
2. Przypisanie poziomu K: skille są umieszczane we właściwej warstwie wiedzy
3. Wzbogacenie tagów: dodawane są tagi na potrzeby odkrywalności
4. Deklaracja narzędzi: dozwolone narzędzia są jednoznacznie deklarowane
5. Wyrównanie sekcji: treść jest restrukturyzowana, żeby pasować do naszego szablonu

Typowy YAML skilla po wchłonięciu:

metadata:
  identifier: vendor-skill-evaluation
  name: vendor-skill-evaluation
  description: Systematic evaluation of vendor skills for adoption.
  type: workflow
  layer: K4
  semantic_folder: project
  source: core
  last_updated: '2026-01-17'

frontmatter:
  tags:
    - agents
    - meta
    - skill-adoption
    - vendor
  allowed_tools:
    - Bash
    - Read
    - Write
    - Edit
    - Grep
    - Glob
    - Task

Faza 4: przypisanie zakresu

Skille są przypisywane do zakresów — kategorii, które determinują, którzy agenci wczytują które skille:

scopes:
  database:
    primary_skills:
      - domains/schema-migration-workflow
      - domains/rpc-validation-checklist
      - vendor/supabase/supabase-database
      - vendor/supabase/supabase-auth

  research:
    primary_skills:
      - identities/research-workflows
      - identities/web-extraction-playbook
      - identities/dataset-discovery-quickstart

Agenci deklarują swoje zakresy, a skille są przypisywane automatycznie:

# Agent definition
scopes: [database, research]
# Gets: all database skills + all research skills + universal skills

Faza 5: materializacja

Skille nie żyją jako YAML na produkcji. Są renderowane do plików SKILL.md, które Claude Code może wczytać:

uv run orkestra sync

To polecenie:

1. Czyta wszystkie definicje YAML skilli
2. Renderuje je przez szablony Jinja
3. Zapisuje pliki SKILL.md do .claude/skills/
4. Organizuje według poziomu K (foundations/, identities/, domains/, stacks/, project/)

Ostateczna struktura wyjściowa:

.claude/skills/
├── foundations/     # K0: Universal
├── identities/      # K1: Discipline
├── domains/         # K2: Subject
├── stacks/          # K3: Technology
├── project/         # K4: Organization
└── vendor/          # External skills

Wzorzec uśpionego zakresu

Jednym z naszych najpotężniejszych wzorców są skille „przyjęte, ale niewczytane”. Nazywamy je uśpionymi zakresami.

Rozważ skille obliczeń naukowych z repozytorium k-dense-scientific. Przyjęliśmy ponad 120 skilli obejmujących bioinformatykę, chemię, obliczenia kwantowe i informatykę kliniczną. Ale większość naszych agentów nie potrzebuje dokowania molekularnego ani analizy ekspresji genów.

Zamiast wczytywać wszystkie 120 skilli do każdego agenta (rozdymając okna kontekstu), robimy tak:

1. Przyjmujemy skille z konkretnym zakresem (np. bioinformatics)
2. Trzymamy je uśpione — zarejestrowane, ale niewczytane
3. Włączamy je tylko wtedy, gdy agent deklaruje ten zakres

# In scopes.yaml - dormant scope
bioinformatics:
  description: "Bioinformatics and genomics"
  primary_skills: []  # Empty - skills exist but aren't loaded

# When an agent needs bioinformatics:
# Agent YAML
scopes: [research, bioinformatics]  # Now loads bioinformatics skills

Ten wzorzec pozwala nam mieć 466 skilli w rejestrze, podczas gdy typowi agenci wczytują tylko 40-60 istotnych.

Typy skilli

Skille występują w trzech wzorcach poznawczych:

Przepływ pracy (Workflow)

Uporządkowane kroki proceduralne: „1. Zrób X, 2. Potem Y, 3. Na koniec Z”

type: workflow
# Examples: schema-migration-workflow, mining-session-workflow

Dyscyplina (Discipline)

Behawioralne bariery ochronne: „Zawsze X”, „Nigdy Y”, „Preferuj Z”

type: discipline
# Examples: test-first-discipline, evidence-based-completion

Lista kontrolna (Checklist)

Kryteria weryfikacji: „Potwierdź X”, „Zweryfikuj Y”, „Sprawdź Z”

type: checklist
# Examples: auth-validation-checklist, secrets-audit-checklist

Bramki jakości

Każdy skill musi przejść walidację, zanim trafi do wydania:

validation:
  file_exists: true           # Skill file at declared path
  frontmatter_valid: true     # Frontmatter parses correctly
  sections_complete: true     # Expected sections present
  tools_registered: true      # Declared tools exist in registry

Opisy muszą mieć 50-400 znaków z frazami wyzwalającymi („Użyj, gdy…”, „Gdy potrzebujesz…”), żeby Claude Code wiedział, kiedy je zasugerować.

Walidujemy w sposób ciągły:

uv run orkestra validate --show-warnings

Ekosystem dostawców

Nasze 373 skille dostawców pochodzą z:

Dostawca	Skille	Domena
AWS Agent	19	Usługi chmurowe
Anthropic	12	Generowanie dokumentów
Cloudflare	8	Edge computing
Supabase	5	Baza danych
k-dense	100+	Obliczenia naukowe
silvainfm	4	Data science
Java Developer Kit	45+	Spring/Java
Vercel	1	Automatyzacja przeglądarki

Każdy korzeń dostawcy jest zadeklarowany w metadata.yaml:

vendor_roots:
  - path: vendor/aws-agent-skills
    provider: aws
  - path: vendor/k-dense-scientific/scientific-skills
    provider: k-dense
  - path: vendor/supabase-skills
    provider: supabase

Gdy uruchamia się orkestra sync, skille dostawców są linkowane symbolicznie do .claude/skills/vendor/ z przestrzenią nazw ich dostawcy.

Czego się nauczyliśmy

Selektywność się opłaca. Kusi, żeby przyjmować wszystko, co wygląda na użyteczne. Ale każdy skill kosztuje tokeny. Przy średnio 2834 tokenach na skill, rozdęcie boli szybko. Nasz 13% wskaźnik adopcji utrzymuje agentów szczupłymi.

Struktura umożliwia odkrywalność. System poziomów K to nie tylko organizacja — chodzi o przenośność. Skille K0 można wykorzystać wszędzie. Skille K4 są celowo specyficzne dla projektu. Ta jasność pomaga zarówno ludziom, jak i agentom znaleźć to, czego potrzebują.

Uśpione zakresy skalują. Możesz przyjąć setki skilli bez wczytywania ich wszystkich. Zakresy pozwalają zbudować wyczerpujący rejestr, jednocześnie utrzymując okna kontekstu poszczególnych agentów w ryzach.

Modyfikacja przy adopcji jest niezbędna. Surowe skille dostawców rzadko pasują do Twojego systemu. Proces wchłaniania — dodawanie metadanych, przypisywanie poziomów, wzbogacanie tagów — sprawia, że zewnętrzne skille działają wewnętrznie.

Wydobywanie jest ciągłe. Liczba 3500 wciąż rośnie. Pojawiają się nowe repozytoria dostawców. Powstają wzorce społecznościowe. Utrwalają się wewnętrzne przepływy pracy. Pętla nigdy się nie zatrzymuje.

Co dalej

Pracujemy nad kilkoma usprawnieniami:

1. Automatyczne wykrywanie luk: alarm, gdy częste niepowodzenia agentów mogłyby zostać rozwiązane przez nieprzyjęty skill
2. Przepływy wycofywania skilli: formalny proces wycofywania skilli, które zostały zastąpione lub są nieużywane
3. Zależności między skillami: jednoznaczna deklaracja wymagań wstępnych skilla
4. Analityka użycia: śledzenie, które skille agenci faktycznie wywołują, a nie tylko wczytują

Pętla wydobywania skilli to infrastruktura. Nie jest efektowna. Ale to właśnie ona sprawia, że 41 agentów działa spójnie z 466 zdolnościami, pozostając w granicach kontekstu.

Taka jest historia tego, jak 3500 zamienia się w 466. Nie przez ignorowanie 3000 — przez systematyczną ocenę i przyjęcie tylko tego, co działa.

---

Chcesz zobaczyć system skilli w akcji? Sprawdź uv run orkestra skills list, żeby przejrzeć nasz obecny rejestr.