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

Canonical source: https://maguyva.ai/pl/blog/skill-mining-3500-and-counting

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-01-27 · Author: Maguyva Team

> Przesialiśmy 3500 kandydatów na skille i przyjęliśmy 466. Systematyczna pętla wyszukiwania i włączania skilli do rejestru pozwala budować spójną bibliotekę skilli agentów AI na dużą skalę.

> *Liczby w tym wpisie odzwierciedlają system w momencie publikacji (styczeń 2026). Aktualne dane znajdziesz na naszej [stronie zespołu](/pl/team).*

## 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 wyszukiwania i włączania skilli do rejestru.

## 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 (dziedzina zawodowa)

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

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

### K2: Domeny (wiedza specjalistyczna)

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 jest oceniany według tych samych kryteriów:

```yaml
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 być spełnionych. 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.

```yaml
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, sprawdzone pod kątem zakresu działania i uznane za bezpieczne.

**Analiza luk**: przed przyjęciem przeszukujemy nasz rejestr:

```bash
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`.

```yaml
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 otrzymuje niższą ocenę niż mniejsze repozytorium z precyzyjnym opisem, starannie dobranymi materiałami w `references/` i atomowymi pomocnikami, które faktycznie wykorzystują pełną zdolność skilla.

**Analiza strukturalna**: sprawdzamy jakość skilla:

```bash
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: włączanie do rejestru

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 włączeniu do rejestru:

```yaml
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:

```yaml
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:

```yaml
# 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ć:

```bash
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

```yaml
# 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”

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

### Dyscyplina (Discipline)

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

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

### Lista kontrolna (Checklist)

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

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

## Kontrole jakości

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

```yaml
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:

```bash
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:

```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 włączania do rejestru — 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.*