agent-sort

Agent Sort

Utilisez cette compétence lorsqu'un dépôt a besoin d'une surface ECC spécifique au projet au lieu de l'installation complète par défaut.

L'objectif n'est pas de deviner ce qui « semble utile ». L'objectif est de classer les composants ECC avec des preuves issues du codebase réel.

Quand l'utiliser

• Un projet n'a besoin que d'un sous-ensemble d'ECC et les installations complètes sont trop bruyantes
• La pile du dépôt est claire, mais personne ne veut sélectionner les compétences une par une à la main
• Une équipe souhaite une décision d'installation reproductible, appuyée par des preuves et non par une opinion
• Vous devez séparer les surfaces de travail quotidiennes toujours chargées des surfaces de bibliothèque/référence consultables
• Un dépôt a dérivé vers le mauvais langage, jeu de règles ou de hooks et a besoin d'être nettoyé

Règles non négociables

• Utilisez le dépôt actuel comme source de vérité, pas des préférences génériques
• Chaque décision QUOTIDIEN doit citer des preuves concrètes du dépôt
• BIBLIOTHÈQUE ne signifie pas « supprimer » ; cela signifie « garder accessible sans le charger par défaut »
• N'installez pas de hooks, règles ou scripts que le dépôt actuel ne peut pas utiliser
• Privilégiez les surfaces natives d'ECC ; n'introduisez pas un second système d'installation

Livrables

Produisez ces artefacts dans l'ordre :

1. Inventaire QUOTIDIEN
2. Inventaire BIBLIOTHÈQUE
3. Plan d'installation
4. Rapport de vérification
5. Routeur skill-library optionnel si le projet le souhaite

Modèle de classification

Utilisez uniquement deux catégories :

• QUOTIDIEN
  • doit se charger à chaque session pour ce dépôt
  • fortement adapté au langage, framework, workflow ou surface opérateur du dépôt
• BIBLIOTHÈQUE
  • utile à conserver, mais pas assez pour le charger par défaut
  • doit rester accessible via la recherche, une compétence routeur ou une utilisation manuelle sélective

Sources de preuve

Utilisez les preuves locales du dépôt avant de faire tout classement :

• extensions de fichiers
• gestionnaires de paquets et fichiers de verrouillage
• configurations de framework
• configurations CI et de hooks
• scripts de build et de test
• imports et manifests de dépendances
• documentation du dépôt décrivant explicitement la pile

Les commandes utiles incluent :

rg --files
rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
cat package.json
cat pyproject.toml
cat Cargo.toml
cat pubspec.yaml
cat go.mod

Passes de révision parallèles

Si des sous-agents parallèles sont disponibles, répartissez la révision selon ces passes :

1. Agents
   • classer agents/*
2. Compétences
   • classer skills/*
3. Commandes
   • classer commands/*
4. Règles
   • classer rules/*
5. Hooks et scripts
   • classer les surfaces de hooks, vérifications de santé MCP, scripts d'aide et compatibilité OS
6. Extras
   • classer les contextes, exemples, configurations MCP, modèles et documents d'orientation

Si les sous-agents ne sont pas disponibles, exécutez les mêmes passes séquentiellement.

Flux de travail principal

1. Lire le dépôt

Établissez la pile réelle avant de classer quoi que ce soit :

• langages utilisés
• frameworks utilisés
• gestionnaire de paquets principal
• pile de test
• pile de lint/format
• surface de déploiement/exécution
• intégrations opérateur déjà présentes

2. Construire le tableau de preuves

Pour chaque surface candidate, enregistrez :

• chemin du composant
• type de composant
• catégorie proposée
• preuve du dépôt
• brève justification

Utilisez ce format :

skills/frontend-patterns | skill | QUOTIDIEN | 84 fichiers .tsx, next.config.ts présent | pile frontend principale
skills/django-patterns   | skill | BIBLIOTHÈQUE | aucun fichier .py, pas de pyproject.toml       | non actif dans ce dépôt
rules/typescript/*       | rules | QUOTIEN | package.json + tsconfig.json            | dépôt TS actif
rules/python/*           | rules | BIBLIOTHÈQUE | zéro fichier source Python              | garder accessible uniquement

3. Décider QUOTIDIEN vs BIBLIOTHÈQUE

Promouvoir en QUOTIDIEN lorsque :

• le dépôt utilise clairement la pile correspondante
• le composant est suffisamment général pour aider chaque session
• le dépôt dépend déjà du runtime ou du workflow correspondant

Rétrograder en BIBLIOTHÈQUE lorsque :

• le composant est hors pile
• le dépôt pourrait en avoir besoin plus tard, mais pas tous les jours
• il ajoute une surcharge de contexte sans pertinence immédiate

4. Construire le plan d'installation

Traduire la classification en actions :

• compétences QUOTIDIENNES -> installer ou conserver dans .claude/skills/
• commandes QUOTIDIENNES -> conserver comme shims explicites uniquement si encore utiles
• règles QUOTIDIENNES -> installer uniquement les ensembles de langues correspondants
• hooks/scripts QUOTIDIENS -> ne conserver que les compatibles
• surfaces BIBLIOTHÈQUE -> garder accessibles via la recherche ou skill-library

Si le dépôt utilise déjà des installations sélectives, mettez à jour ce plan au lieu de créer un autre système.

5. Créer le routeur de bibliothèque optionnel

Si le projet souhaite une surface de bibliothèque consultable, créez :

• .claude/skills/skill-library/SKILL.md

Ce routeur doit contenir :

• une brève explication de QUOTIDIEN vs BIBLIOTHÈQUE
• des mots-clés de déclenchement groupés
• où se trouvent les références de la bibliothèque

Ne dupliquez pas le corps de chaque compétence à l'intérieur du routeur.

6. Vérifier le résultat

Après l'application du plan, vérifiez :

• chaque fichier QUOTIDIEN existe à l'endroit attendu
• les règles de langage obsolètes n'ont pas été laissées actives
• les hooks incompatibles n'ont pas été installés
• l'installation obtenue correspond effectivement à la pile du dépôt

Renvoyez un rapport compact avec :

• nombre de QUOTIDIENS
• nombre de BIBLIOTHÈQUE
• surfaces obsolètes supprimées
• questions en suspens

Passages de relais

Si l'étape suivante est une installation interactive ou une réparation, passez le relais à :

• configure-ecc

Si l'étape suivante est un nettoyage des chevauchements ou une révision du catalogue, passez le relais à :

• skill-stocktake

Si l'étape suivante est une réduction de contexte plus large, passez le relais à :

• strategic-compact

Format de sortie

Renvoyez le résultat dans cet ordre :

PILE
- résumé langage/framework/exécution

QUOTIDIEN
- éléments toujours chargés avec preuves

BIBLIOTHÈQUE
- éléments consultables/référence avec preuves

PLAN D'INSTALLATION
- ce qui doit être installé, supprimé ou routé

VÉRIFICATION
- vérifications effectuées et lacunes restantes