Extraction de compétences : de 3 500 candidates à 466 capacités

Les chiffres de cet article reflètent le système au moment de la publication (janvier 2026). Consultez notre page équipe pour les chiffres actuels.

Le problème des 3 500 compétences

Quand nous avons commencé à construire un système d’orchestration d’agents, nous avons fait face à un défi intéressant : des milliers de compétences potentielles sont éparpillées dans tout l’écosystème IA. Dépôts GitHub, documentation d’éditeurs, projets communautaires, schémas internes — les compétences existent partout. Mais lesquelles comptent ? Lesquelles fonctionnent ? Et comment maintenir une bibliothèque de compétences cohérente que les agents peuvent réellement utiliser ?

Notre réponse : une boucle systématique d’extraction et d’ingestion.

Les chiffres aujourd’hui

À peine plus de trois mois après le lancement des Agent Skills par Anthropic le 16 octobre 2025, voici où nous en étions à la publication de cet article, le 27 janvier 2026 :

Métrique	Nombre
Candidates identifiées	plus de 3 500
Compétences adoptées	466
Compétences d’éditeurs	373
Compétences internes	93
Éditeurs actifs	plus de 25
Tokens moyens par compétence	2 834
Outils référencés	89
Tags uniques	635

Nous avons passé en revue plus de 3 500 compétences candidates. Nous en avons adopté 466. Cela représente un taux d’adoption de 13 % — et cette sélectivité est voulue.

Le système de paliers de connaissance

Toutes les compétences ne se valent pas. Nous les organisons en cinq couches de connaissance (K0-K4), chacune représentant une portée d’applicabilité différente :

K0 : Fondations (universelles)

Des compétences que chaque agent devrait posséder. Elles représentent des capacités de « bon penseur » qui fonctionnent partout.

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

Les compétences K0 sont portables vers n’importe quel projet, domaine ou pile technologique. Elles encodent des schémas cognitifs universels.

K1 : Identités (discipline)

Des compétences de « bon ingénieur » ou de « bon chercheur » qui s’appliquent à travers les projets au sein d’une discipline.

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

K2 : Domaines (expertise sur un sujet)

Des compétences de « bon expert base de données » ou de « bon ingénieur sécurité », portables au sein d’un domaine.

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

Des compétences de « bon utilisateur Supabase » ou de « bon développeur Cloudflare » pour des piles technologiques spécifiques.

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

K4 : Projet (organisation)

Des compétences propres à notre organisation et à nos flux de travail.

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

La boucle de minage

Phase 1 : découverte

Les compétences viennent de partout :

Dépôts d’éditeurs : AWS, Anthropic, Cloudflare, Supabase et des contributeurs communautaires publient des collections de compétences. Nous suivons plus de 25 racines d’éditeurs.

Projets communautaires : GitHub regorge de templates Claude Code, de schémas d’agents et de définitions de flux de travail.

Schémas internes : à mesure que notre équipe résout des problèmes, des schémas émergent. Ils sont formalisés en compétences.

Minage de documentation : la documentation technique contient souvent des compétences implicites — procédures, listes de vérification, arbres de décision.

La découverte est continue. Nous utilisons un backlog de compétences pour suivre les candidates avant évaluation formelle.

Phase 2 : évaluation

Chaque candidate passe par la même grille :

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

Les cinq critères produit doivent tous être satisfaits. C’est pourquoi 87 % des candidates sont rejetées.

Ensuite, chaque candidate passe par une revue de confiance distincte. Nous ne traitons pas un dépôt officiel d’éditeur, un mainteneur communautaire bien connu et un dépôt GitHub aléatoire comme des sources de vérité équivalentes.

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

Les éditeurs de confiance bénéficient d’une revue de provenance plus légère, mais pas d’un laissez-passer. Les sources non fiables ou inconnues subissent un audit manuel plus approfondi, et nous n’exécutons pas les scripts intégrés avant qu’ils n’aient été lus, délimités, et classés comme sûrs.

Analyse d’écart : avant d’adopter, nous cherchons dans notre registre :

uv run orkestra skills search "<capability>"

Si nous l’avons déjà, nous n’en avons pas besoin. Si nous avons quelque chose de proche, nous pourrions fusionner plutôt qu’adopter.

Notation de profondeur et de conformité aux standards : nous notons aussi à quel point une candidate exploite pleinement le modèle agent-compétence. Un simple SKILL.md isolé peut rester utile, mais des compétences plus profondes ont plus de valeur quand elles séparent instructions, références, scripts et actifs de la façon que agentskills.io encourage.

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

Les étoiles GitHub peuvent légèrement rehausser un score de crédibilité, mais elles ne sauvent jamais une compétence superficielle ou dangereuse. Un dépôt très étoilé avec un seul SKILL.md vague et des scripts opaques note moins bien qu’un plus petit dépôt avec une description précise, des references/ soignées, et des utilitaires atomiques qui exploitent réellement toute la capacité du modèle de compétence.

Analyse structurelle : nous vérifions la qualité de la compétence :

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

Si une candidate inclut des scripts, cette revue devient plus stricte. Une bonne compétence n’est pas seulement utile ; elle doit être lisible, délimitée et sûre à confier à un agent. Ce seul filtre de sécurité disqualifie une part significative de candidates par ailleurs intéressantes.

Phase 3 : ingestion

Quand une compétence passe l’évaluation, elle entre dans le registre. Mais les compétences ne sont jamais adoptées sans modification. Elles sont adaptées à notre système.

Modifications lors de l’adoption :

1. Normalisation des métadonnées : chaque compétence reçoit notre schéma de frontmatter
2. Attribution du palier K : les compétences sont placées dans la couche de connaissance appropriée
3. Enrichissement des tags : des tags sont ajoutés pour la découverte
4. Déclaration des outils : les outils autorisés sont explicitement déclarés
5. Alignement des sections : le contenu est restructuré pour correspondre à notre modèle

Un YAML de compétence typique après ingestion :

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

Phase 4 : attribution de portée

Les compétences sont attribuées à des portées — des catégories qui déterminent quels agents chargent quelles compétences :

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

Les agents déclarent leurs portées, et les compétences sont attribuées automatiquement :

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

Phase 5 : matérialisation

Les compétences ne vivent pas en YAML en production. Elles sont rendues en fichiers SKILL.md que Claude Code peut charger :

uv run orkestra sync

Cette commande :

1. Lit toutes les définitions YAML de compétences
2. Les rend via des templates Jinja
3. Écrit les fichiers SKILL.md dans .claude/skills/
4. Organise par palier K (foundations/, identities/, domains/, stacks/, project/)

La structure de sortie finale :

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

Le schéma des portées dormantes

L’un de nos schémas les plus puissants est celui des compétences « adoptées mais non chargées ». Nous appelons cela des portées dormantes.

Prenez les compétences de calcul scientifique du dépôt k-dense-scientific. Nous avons adopté plus de 120 compétences couvrant la bio-informatique, la chimie, l’informatique quantique et l’informatique clinique. Mais la plupart de nos agents n’ont pas besoin d’amarrage moléculaire ni d’analyse d’expression génique.

Au lieu de charger les 120 compétences dans chaque agent (ce qui gonflerait les fenêtres de contexte), nous :

1. Adoptons les compétences avec une portée spécifique (par exemple, bioinformatics)
2. Les gardons dormantes — enregistrées mais non chargées
3. Les activons seulement quand un agent déclare cette portée

# 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

Ce schéma nous permet d’avoir 466 compétences dans le registre, tandis qu’un agent typique n’en charge que 40 à 60 pertinentes.

Types de compétences

Les compétences suivent trois schémas cognitifs :

Flux de travail

Des étapes procédurales ordonnées : « 1. Faire X, 2. Puis Y, 3. Enfin Z »

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

Discipline

Des garde-fous comportementaux : « Toujours X », « Jamais Y », « Préférer Z »

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

Liste de vérification

Des critères de vérification : « Confirmer X », « Vérifier Y », « Contrôler Z »

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

Portes de qualité

Chaque compétence doit passer une validation avant de partir en production :

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

Les descriptions doivent compter de 50 à 400 caractères, avec des phrases de déclenchement (« À utiliser quand… », « Quand vous avez besoin de… ») pour que Claude Code sache quand les suggérer.

Nous validons en continu :

uv run orkestra validate --show-warnings

L’écosystème d’éditeurs

Nos 373 compétences d’éditeurs viennent de :

Fournisseur	Compétences	Domaine
AWS Agent	19	Services cloud
Anthropic	12	Génération de documents
Cloudflare	8	Edge computing
Supabase	5	Base de données
k-dense	plus de 100	Calcul scientifique
silvainfm	4	Data science
Java Developer Kit	plus de 45	Spring/Java
Vercel	1	Automatisation navigateur

Chaque racine d’éditeur est déclarée dans 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

Quand orkestra sync s’exécute, les compétences d’éditeurs sont liées par symlink dans .claude/skills/vendor/ avec leur espace de noms fournisseur.

Ce que nous avons appris

La sélectivité paie. Il est tentant d’adopter tout ce qui paraît utile. Mais chaque compétence coûte des tokens. Avec 2 834 tokens en moyenne par compétence, le gonflement fait mal vite. Notre taux d’adoption de 13 % garde les agents légers.

La structure permet la découverte. Le système de paliers K n’est pas qu’une question d’organisation — c’est une question de portabilité. Les compétences K0 sont réutilisables partout. Les compétences K4 sont intentionnellement propres au projet. Cette clarté aide les humains comme les agents à trouver ce dont ils ont besoin.

Les portées dormantes passent à l’échelle. Vous pouvez adopter des centaines de compétences sans toutes les charger. Les portées vous permettent de construire un registre exhaustif tout en gardant maniables les fenêtres de contexte de chaque agent.

La modification lors de l’adoption est essentielle. Les compétences brutes d’éditeurs correspondent rarement à votre système. Le processus d’ingestion — ajouter des métadonnées, attribuer des paliers, enrichir les tags — fait fonctionner les compétences externes en interne.

Le minage est continu. Le chiffre de 3 500 continue de croître. De nouveaux dépôts d’éditeurs apparaissent. Des schémas communautaires émergent. Des flux de travail internes se solidifient. La boucle ne s’arrête jamais.

Et ensuite

Nous travaillons sur plusieurs améliorations :

1. Détection automatisée d’écarts : alerter quand des échecs courants d’agents pourraient être résolus par une compétence non adoptée
2. Flux de travail de dépréciation des compétences : un processus formel pour retirer les compétences supplantées ou inutilisées
3. Dépendances entre compétences : déclaration explicite des prérequis d’une compétence
4. Analytique d’usage : suivre quelles compétences les agents invoquent réellement, par opposition à celles qu’ils se contentent de charger

La boucle de minage de compétences est de l’infrastructure. Ce n’est pas glamour. Mais c’est ce qui fait que 41 agents travaillent de façon cohérente avec 466 capacités, tout en restant dans les limites de contexte.

Voilà l’histoire de comment 3 500 devient 466. Pas en ignorant 3 000 — en les évaluant systématiquement et en n’adoptant que ce qui fonctionne.

---

Vous voulez voir le système de compétences en action ? Consultez uv run orkestra skills list pour explorer notre registre actuel.