GitHub introduit les agent skills pour réutiliser des tâches automatisées

Concept et architecture des agent skills

Un agent skill est un répertoire versionné centré sur un fichier SKILL.md. Ce fichier décrit le job (nom, description), les entrées attendues et les sorties produites. Le format front‑matter YAML permet de déclarer explicitement la tâche, comme dans l’exemple du Proof Agent :

---
name: proof-agent
description: Adversarial verification of AI-generated work. Spawns an independent verifier to check for false claims, broken code, and security issues.
---

Le skill ne possède pas les accès aux ressources ; il dépend de l’environnement qui fournit les outils, les identifiants et les permissions nécessaires. Ainsi, un skill peut spécifier une requête de base de données sans pouvoir s’y connecter directement.

Coordination de compétences dans un workflow

Les skills sont conçus pour des tâches bornées et répétables. Dans l’exemple Data Forge, plusieurs skills collaborent pour créer un pipeline de support‑desk : forge-init découvre les tables et conventions, forge-builder orchestre la création du code, forge-dbx fournit l’accès aux données, et forge-lint applique les standards de l’équipe. Chaque skill lit un manifest partagé, ce qui évite la redondance des découvertes.

Le manifest décrit le projet, le magasin de métriques et la plateforme d’exécution :

project:
  name: "support-desk"
  store_name: "support_metric_store"
platform:
  engine: "duckdb"
  pipeline_framework: "spark_python"
  duckdb_dir: "warehouse"

En séparant les détails du projet du code de vérification, on peut réutiliser les mêmes skills avec un autre manifest sans réécriture. Le workflow comporte sept phases, chacune précédée d’un point de contrôle humain. Avant de passer à la phase suivante, le système vérifie que la phase précédente est terminée, et les changements de schéma nécessitent une approbation explicite.

Gestion du contexte, des permissions et du packaging

Le modèle impose que les compétences ne contiennent pas de configuration projet‑spécifique. Le manifest agit comme une couche d’abstraction : il indique l’engin (DuckDB ou Databricks) mais ne fournit pas le binaire ni les droits d’accès, qui restent du ressort de l’environnement d’exécution. Cette séparation garantit que les mêmes skills fonctionnent sur différents agents, qu’il s’agisse de Claude Code, de Cursor ou d’un autre client.

Pour supporter plusieurs clients, le dépôt conserve les sources sous skills/*/SKILL.md puis utilise un script d’empaquetage qui génère les fichiers spécifiques au client, par exemple .claude-plugin/plugin.json. Cette étape assure la synchronisation des instructions tout en adaptant le format aux exigences de chaque plateforme.