Přeskočit na obsah
cd /blog

Mining skillů: od 3 500 kandidátů k 466 schopnostem

[Architektura][Dovednosti]

> Proscreenovali jsme 3 500 kandidátů na skilly a přijali 466. Systematická smyčka těžby a příjmu pro stavbu koherentní knihovny skillů AI agentů ve velkém měřítku.

Čísla v tomto příspěvku odrážejí stav systému v době zveřejnění (leden 2026). Aktuální čísla najdete na naší stránce týmu.

Problém 3 500 skillů

Když jsme začali stavět systém orchestrace agentů, narazili jsme na zajímavou výzvu: v AI ekosystému jsou rozprostřeny tisíce potenciálních skillů. Repozitáře na GitHubu, dokumentace dodavatelů, komunitní projekty, interní vzorce — skilly existují všude. Ale na kterých záleží? Které fungují? A jak si udržíte koherentní knihovnu skillů, kterou agenti skutečně dokážou používat?

Naše odpověď: systematická smyčka těžby a příjmu.

Čísla dnes

Něco přes tři měsíce po tom, co Anthropic 16. října 2025 spustil Agent Skills, takhle jsme na tom byli ve chvíli, kdy byl tento příspěvek publikován 27. ledna 2026:

Metrika Počet
Identifikovaní kandidáti 3 500+
Přijaté skilly 466
Skilly od dodavatelů 373
Interní skilly 93
Aktivní dodavatelé 25+
Průměrný počet tokenů na skill 2 834
Referencované nástroje 89
Unikátní tagy 635

Prošli jsme přes 3 500 kandidátů na skilly. Přijali jsme 466. To je 13% míra přijetí — a ta selektivita je záměrná.

Systém znalostních vrstev

Ne všechny skilly jsou si rovny. Organizujeme je do pěti znalostních vrstev (K0–K4), z nichž každá představuje jiný rozsah použitelnosti.

K0: Foundations (univerzální)

Skilly, které by měl mít každý agent. Představují schopnosti „dobrého myslitele“, které fungují kdekoliv.

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

Skilly K0 jsou přenositelné do jakéhokoliv projektu, jakékoliv domény, jakéhokoliv stacku. Kódují univerzální kognitivní vzorce.

K1: Identities (disciplína)

Skilly „dobrého inženýra“ nebo „dobrého výzkumníka“, které platí napříč projekty v rámci disciplíny.

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

K2: Domains (oborová expertíza)

Skilly „dobrého databázového experta“ nebo „dobrého bezpečnostního inženýra“ přenositelné v rámci oboru.

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: Stacks (technologie)

Skilly „dobrého uživatele Supabase“ nebo „dobrého vývojáře pro Cloudflare“ pro konkrétní technologické stacky.

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

K4: Project (organizace)

Skilly specifické pro naši organizaci a naše workflow.

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

Smyčka těžby

Fáze 1: Objevování

Skilly přicházejí odevšad:

Repozitáře dodavatelů: AWS, Anthropic, Cloudflare, Supabase a přispěvatelé z komunity publikují kolekce skillů. Sledujeme 25+ kořenů dodavatelů.

Komunitní projekty: GitHub je plný šablon pro Claude Code, vzorců agentů a definic workflow.

Interní vzorce: Jak náš tým řeší problémy, vynořují se vzorce. Ty se formalizují do skillů.

Těžba dokumentace: Technická dokumentace často obsahuje implicitní skilly — postupy, checklisty, rozhodovací stromy.

Objevování je nepřetržité. K sledování kandidátů před formálním vyhodnocením používáme backlog skillů.

Fáze 2: Vyhodnocení

Každý kandidát prochází stejným rubrikem:

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

Všech pět produktových kritérií musí projít. Proto je 87 % kandidátů odmítnuto.

Pak každý kandidát prochází samostatným review důvěryhodnosti. Oficiální repozitář dodavatele, známého komunitního maintainera a náhodný repozitář na GitHubu nepovažujeme za rovnocenné zdroje pravdy.

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

Důvěryhodní dodavatelé dostanou lehčí review provenience, ale ne volnou kartu. Nedůvěryhodné nebo neznámé zdroje dostanou hlubší ruční audit a přiložené skripty nespouštíme, dokud nejsou přečtené, ohraničené rozsahem a klasifikované jako bezpečné.

Analýza mezer: Před přijetím prohledáme náš registr:

uv run orkestra skills search "<capability>"

Pokud to už máme, nepotřebujeme to. Pokud máme něco blízkého, možná to spíš sloučíme, než abychom to přijímali.

Skórování hloubky a standardů: Skórujeme také, jak plně kandidát využívá model agent-skill. Osamocený SKILL.md může být pořád užitečný, ale hlubší skilly jsou cennější, když oddělují instrukce od referencí, skriptů a assetů tak, jak to podporuje 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

Hvězdičky na GitHubu dokážou skóre důvěryhodnosti trochu zvednout, ale nikdy nezachrání mělký nebo nebezpečný skill. Repozitář s mnoha hvězdami a jedním vágním SKILL.md a neprůhlednými skripty skóruje níž než menší repozitář s přesným popisem, kurátorovanými references/ a atomickými pomůckami, které skutečně využívají plnou schopnost skillu.

Strukturální analýza: Kontrolujeme kvalitu skillu:

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

Pokud kandidát obsahuje skripty, ten review je přísnější. Dobrý skill není jen užitečný; musí být čitelný, ohraničený a bezpečný na to, aby se předal agentovi. Sám tenhle bezpečnostní filtr diskvalifikuje smysluplný podíl jinak zajímavých kandidátů.

Fáze 3: Příjem

Když skill projde vyhodnocením, vstoupí do registru. Skilly ale nikdy nepřijímáme nezměněné. Upravují se, aby seděly do našeho systému.

Úpravy při přijetí:

  1. Normalizace metadat: každý skill dostane naše frontmatter schéma
  2. Přiřazení K-vrstvy: skilly se zařadí do odpovídající znalostní vrstvy
  3. Obohacení tagy: tagy se přidávají pro objevitelnost
  4. Deklarace nástrojů: povolené nástroje jsou explicitně deklarované
  5. Zarovnání sekcí: obsah se restrukturuje podle naší šablony

Typický YAML skillu po příjmu:

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

Fáze 4: Přiřazení scope

Skilly se přiřazují ke scope — kategoriím, které určují, kteří agenti které skilly načtou:

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

Agenti deklarují své scope a skilly se přiřazují automaticky:

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

Fáze 5: Materializace

Skilly nežijí v produkci jako YAML. Vykreslují se do souborů SKILL.md, které Claude Code umí načíst:

uv run orkestra sync

Tento příkaz:

  1. Přečte všechny YAML definice skillů
  2. Vykreslí je přes šablony Jinja
  3. Zapíše soubory SKILL.md do .claude/skills/
  4. Organizuje je podle K-vrstvy (foundations/, identities/, domains/, stacks/, project/)

Finální struktura výstupu:

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

Vzorec spícího scope

Jeden z našich nejsilnějších vzorců jsou skilly „přijaté, ale nenačtené“. Říkáme jim spící scope.

Vezměte si skilly pro vědecké výpočty z repozitáře k-dense-scientific. Přijali jsme 120+ skillů pokrývajících bioinformatiku, chemii, kvantové počítání a klinickou informatiku. Většina našich agentů ale nepotřebuje molekulární docking ani analýzu genové exprese.

Místo abychom všech 120 skillů naložili do každého agenta (a nafoukli kontextová okna), postupujeme takto:

  1. Přijmeme skilly s konkrétním scope (např. bioinformatics)
  2. Necháme je spící – registrované, ale nenačtené
  3. Zapneme je jen tehdy, když agent tento scope deklaruje
# 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

Díky tomuto vzorci můžeme mít v registru 466 skillů, zatímco typický agent jich načte jen 40–60 relevantních.

Typy skillů

Skilly přicházejí ve třech kognitivních vzorcích:

Workflow

Seřazené procedurální kroky: „1. Udělej X, 2. Pak Y, 3. Nakonec Z“

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

Disciplína

Behaviorální zábradlí: „Vždy X“, „Nikdy Y“, „Upřednostni Z“

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

Checklist

Ověřovací kritéria: „Potvrď X“, „Ověř Y“, „Zkontroluj Z“

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

Brány kvality

Než skill vyjde do provozu, musí projít validací:

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

Popisy musí mít 50–400 znaků se spouštěcími frázemi („Použij, když…“, „Když potřebuješ…“), aby Claude Code věděl, kdy je navrhnout.

Validujeme průběžně:

uv run orkestra validate --show-warnings

Ekosystém dodavatelů

Našich 373 skillů od dodavatelů pochází z:

Poskytovatel Skilly Doména
AWS Agent 19 Cloudové služby
Anthropic 12 Generování dokumentů
Cloudflare 8 Edge computing
Supabase 5 Databáze
k-dense 100+ Vědecké výpočty
silvainfm 4 Datová věda
Java Developer Kit 45+ Spring/Java
Vercel 1 Automatizace prohlížeče

Každý kořen dodavatele je deklarovaný v 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

Když proběhne orkestra sync, skilly dodavatelů se symlinknou do .claude/skills/vendor/ pod jejich namespace poskytovatele.

Co jsme se naučili

Selektivita se vyplácí. Je lákavé přijmout všechno, co vypadá užitečně. Ale každý skill stojí tokeny. S průměrem 2 834 tokenů na skill bobtnání rychle bolí. Naše 13% míra přijetí drží agenty útlé.

Struktura umožňuje objevitelnost. Systém K-vrstev není jen organizace — jde o přenositelnost. Skilly K0 lze znovu použít kdekoliv. Skilly K4 jsou záměrně specifické pro projekt. Tahle jasnost pomáhá lidem i agentům najít, co potřebují.

Spící scope škálují. Můžete přijmout stovky skillů, aniž byste je všechny museli načíst. Scope vám umožní vybudovat rozsáhlý registr a přitom udržet kontextová okna jednotlivých agentů zvladatelná.

Úprava při přijetí je zásadní. Syrové skilly dodavatelů se do vašeho systému málokdy hodí beze změny. Proces příjmu — přidání metadat, přiřazení vrstev, obohacení tagů — dělá z externích skillů funkční interní součást.

Těžba je nepřetržitá. Číslo 3 500 pořád roste. Objevují se nové repozitáře dodavatelů. Vynořují se komunitní vzorce. Interní workflow se ustalují. Smyčka se nikdy nezastaví.

Co je dál

Pracujeme na několika vylepšeních:

  1. Automatizovaná detekce mezer: upozornění, když by běžná selhání agenta mohla vyřešit nepřijatý skill
  2. Workflow pro deprecaci skillů: formální proces pro vyřazování skillů, které jsou nahrazené nebo nepoužívané
  3. Cross-skill závislosti: explicitní deklarace předpokladů mezi skilly
  4. Analytika používání: sledování, které skilly agenti skutečně vyvolávají, a ne jen načítají

Smyčka mining skillů je infrastruktura. Není okázalá. Ale je to to, díky čemu 41 agentů koherentně funguje se 466 schopnostmi a přitom zůstává v kontextových limitech.

To je příběh, jak se z 3 500 stává 466. Ne tak, že bychom 3 000 ignorovali — tím, že jsme je systematicky vyhodnotili a přijali jen to, co funguje.


Chcete vidět systém skillů v akci? Podívejte se na uv run orkestra skills list a prozkoumejte náš aktuální registr.

Související čtení

Další ze stavebního deníku Maguyva