agent-sort

Agent Sort

Utilisez cette compétence lorsqu'un dépôt nécessite 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 code source réel.

Quand l'utiliser

• Un projet n'a besoin que d'un sous-ensemble de l'ECC et les installations complètes sont trop bruyantes
• La pile du dépôt est claire, mais personne ne veut trier les compétences une par une manuellement
• Une équipe souhaite une décision d'installation reproductible, fondée sur des preuves par grep plutôt que sur des opinions
• 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, ensemble de règles ou de hooks et nécessite un nettoyage

Règle non négociable

• Utilisez le dépôt actuel comme source de vérité, pas les 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 de l'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 en souhaite un

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, le routeur de compétence, ou une utilisation manuelle sélective

Sources de preuves

Utilisez les preuves locales du dépôt avant toute classification :

• extensions de fichiers
• gestionnaires de paquets et fichiers de verrouillage
• configurations de framework
• configurations CI et hooks
• scripts de construction/test
• importations et manifestes 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, divisez la révision en ces passes :

1. Agents
   • classifiez agents/*
2. Compétences
   • classifiez skills/*
3. Commandes
   • classifiez commands/*
4. Règles
   • classifiez rules/*
5. Hooks et scripts
   • classifiez les surfaces de hooks, les vérifications de santé MCP, les scripts d'aide et la compatibilité OS
6. Extras
   • classifiez 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 | QUOTIDIEN | 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

Passez 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

Déplacez 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

Traduisez la classification en actions :

• Compétences QUOTIDIEN -> installer ou conserver dans .claude/skills/
• Commandes QUOTIDIEN -> ne conserver comme shims explicites que si encore utiles
• Règles QUOTIDIEN -> installer uniquement les ensembles de langages correspondants
• Hooks/scripts QUOTIDIEN -> ne conserver que ceux 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 regroupés
• l'emplacement des références de la bibliothèque

Ne dupliquez pas chaque corps de compétence dans le routeur.

6. Vérifier le résultat

Une fois le plan appliqué, vérifiez :

• chaque fichier QUOTIDIEN existe à l'endroit prévu
• 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 résultante correspond réellement à la pile du dépôt

Retournez un rapport compact avec :

• nombre QUOTIDIEN
• nombre BIBLIOTHÈQUE
• surfaces obsolètes supprimées
• questions ouvertes

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 plus large du contexte, passez le relais à :

• strategic-compact

Format de sortie

Retournez 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/de référence avec preuves

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

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