CaseYwY/skills

manage-project-skills — sélection & audit des compétences de projet

0. Hiérarchie des règles (à lire en premier)

1. Autorisation (la plus élevée, sans exception) : aucune installation/mise à jour/suppression, aucune écriture de fichier projet sans approbation explicite de l'utilisateur ; exception : écritures approuvées dans le registre. L'approbation = compétence spécifique + source + portée ; « gérez mes compétences » n'autorise rien individuellement.
2. Processus : suivre le mode sélectionné (T0/T1/T2/audit) ; les étapes « interdites » ne sont jamais sautées pour des raisons d'efficacité.
3. Directives : local d'abord, retenue — les écarts sont autorisés avec une raison explicite.

Essentiel: il vaut mieux qu'il manque une compétence plutôt que d'en installer une de travers — retrait ≈ 1 min ; mauvaise installation = contexte permanent + compétition de déclencheurs. Retenue, justification obligatoire, local en premier.

1. Modes

Si les exigences sont floues ⇒ les besoins globaux sont inconnus ⇒ pas d'installation en masse au lancement.

• T0 · Inventaire de lancement (LECTURE SEULE) : étapes 1-2 + rapport textuel (« couvert / pas d'installation »). Zéro installation/écriture. L'initialisation du registre = une écriture approuvée séparée. La matrice de couverture = uniquement les besoins déduisibles de la pile. Chemin rapide : si le registre existe && pas de discussion sur les compétences ⇒ lire uniquement le registre. Ré-inventorier si : les répertoires de compétences / AGENTS.md / le fichier de verrouillage / l'agent a changé ∨ le registre ≠ le disque ∨ l'utilisateur le demande.
• T1 · Piloté par les besoins (en cours de tâche) : classer d'abord. Réponse ponctuelle (détail d'API, commande unique) ⇒ rechercher, pas d'installation. Réutilisable (workflows/standards/chaînes d'outils que ce dépôt rencontre à nouveau) ⇒ installer une compétence ⇒ enregistrer. L'entrée repose sur les règles de AGENTS.md (voir MAINTENANCE.md), pas sur l'auto-évaluation du modèle.
• T2 · Plan stabilisé : installation par lots, chaque candidat justifié par le plan confirmé. Étapes 1 à 7 complètes.
• Audit : l'utilisateur demande une révision/un nettoyage/une épuration ⇒ voir la fin.

Tous les modes partagent le registre de projet .agents/skills-rationale.md (si approuvé) ; le lire en premier.

2. Flux

1. Profiler le projet

Lire si présent (ne pas deviner) : les manifestes (package.json / pyproject.toml / go.mod / Cargo.toml / *.csproj) ; la structure + les signaux de monorepo (workspaces, turbo.json) ; l'infra (.github/workflows, Dockerfile, vercel.json, wrangler.toml) ; l'en-tête du README, docs/agents/.

2. Inventaire de la couverture (local d'abord ; déduplication avant d'ajouter)

Ordre : installé dans le projet → global → registre. Deux classes :

• Compétences personnelles : globales, transversales aux projets. Ne pas dupliquer dans le projet ; enregistrer l'agent cible. La présence globale ≠ dépendance déclarée du projet.
• Critiques pour le projet : le workflow/livraison en dépend. Enregistrer source + version/commit + chemin de restauration — même si installé globalement ; les nouvelles machines n'héritent pas des globales.

Analyse : répertoires du projet (.agents/skills, .opencode/skills, .claude/skills = exemples courants, confirmer selon la doc de l'agent ; inaccessible ⇒ « non vérifié », jamais « aucune compétence ») ; global via npx skills ls -g ; manifeste source & skills-lock.json (synchroniser si présent). Sortie : matrice de couverture (besoin → satisfait par / lacune).

3. Combler les lacunes à partir de sources fiables

Niveaux de confiance : officiel du fournisseur (anthropics/skills, openai/skills, supabase/agent-skills) > auteur d'origine (mattpocock/skills, cursor/plugins) > communauté > non vérifiable (scrutin renforcé). Sinon npx skills find <mot-clé> — le nombre d'installations = référence, pas une confiance. Rien ne correspond ⇒ le dire + proposer skill-creator ; pas de solutions de contournement approximatives.

4. Budget : pas de limite stricte, basé sur les besoins

• Chaque candidat a besoin d'une raison concrète (« le projet a X ⇒ Y ») ; pas de raison ⇒ abandon.

• ~10 candidats = bug d'analyse ⇒ réauditer les étapes 1-2.

• Marginal ⇒ liste « reportée » (le retrait est peu coûteux).
• Déduplication ≠ suppression automatique : chevauchement de descriptions ⇒ groupe de candidats ⇒ comparer les déclencheurs/E-S/effets secondaires/dépendances/versions ⇒ fusionner/supprimer uniquement avec preuve de remplacement + approbation de l'utilisateur ; sinon garder les deux, marquer « à comparer ».

5. Barrière de sécurité : avant l'installation, approuvé par l'utilisateur

Examiner l'ensemble du paquet, pas seulement SKILL.md :

1. Lire SKILL.md entièrement + tous les fichiers/scripts/config/dépendances référencés ; par script vérifier : exécution / réseau / écritures / identifiants.
2. Enregistrer la preuve d'analyse : scanner + verdict + version correspondante + date. Pas d'analyse = inconnu, pas sûr. Désaccord entre scanners ⇒ lister, ne pas faire la moyenne.
3. Source privée sans analyse ⇒ une révision manuelle complète du fichier remplace la barrière, marquée « non analysé ».
4. Risque moyen+ ou comportement inexpliqué ⇒ l'utilisateur décide ; rien n'est installé tant que ce n'est pas clair.

6. Installation

# Détecte automatiquement l'agent (signaler la détection à l'utilisateur) ; machines multi-agents : passer --agent
npx skills add <propriétaire/dépôt>@<compétence> --copy -y

• Canal 2 — version épinglée / solution de secours si npm inaccessible : gh skill install <propriétaire/dépôt> <compétence[@version]> --agent opencode (aperçu ; copie les fichiers, pas de mise à jour de skills-lock ⇒ le registre enregistre source+version ; toujours passer --agent — la valeur par défaut non interactive est github-copilot). Un canal par compétence — ne pas mélanger.
• --copy = instantané isolé, PAS un épinglage de version : pas de synchronisation amont, pas d'identité de version, la réinstallation le modifie. Reproductibilité ⇒ le registre enregistre : source + chemin + version/commit (+hash).
• Compétences de workflow critiques pour le projet : --copy, jamais de lien symbolique (le lien symbolique suit la branche amont).
• skills-lock.json produit ⇒ commiter (restauration : npx skills experimental_install) ; s'assurer que .agents/ n'est pas dans .gitignore.
• Efficacité variable : OpenCode recharge à chaud (vérifié) ; d'autres agents peuvent nécessiter un redémarrage ⇒ inviter l'utilisateur à redémarrer + revérifier.
• GitHub inaccessible ⇒ signaler + proposer un cache local ; ne jamais ignorer silencieusement.

7. Vérifier et enregistrer (quatre couches ; couche manquante = « non vérifié »)

• Fichier : existe, chemin correct, références complètes
• Manifeste : npx skills ls correspond au fichier de verrouillage et au disque (visible ≠ chargeable)
• Chargement : l'agent cible charge réellement la compétence
• Comportement : une tâche positive représentative fonctionne
• Écrire les décisions (quoi/pourquoi/reporté/vérifié jusqu'à) → .agents/skills-rationale.md
• Supprimer : préférer npx skills remove <nom> -y (paramètres selon npx skills --help) ; ne jamais simplement supprimer le répertoire (désynchronisation du fichier de verrouillage) ; enregistrer source+version avant suppression ; sauvegarder si non récupérable ; revérifier les quatre couches après.

3. Mode Audit

Inclut cette compétence elle-même. Rapport → approbation de l'utilisateur → exécution. Vérifications :

1. Doublons : regrouper les descriptions par cluster ⇒ groupes de candidats ⇒ comparer les déclencheurs/E-S/effets secondaires/dépendances/versions ; preuve de remplacement + approbation ⇒ fusionner/supprimer ; sinon garder les deux (« à comparer »). Ne jamais supprimer sur la seule base de la similarité.
2. Conflits : contradictions dans le même scénario ⇒ citer les passages + portée ⇒ l'utilisateur arbitre.
3. Gonflement : pas de télémétrie d'utilisation — « jamais déclenché » = source utilisateur. Mesurable : gonflement de la description vs fonction, chevauchement avec des compétences plus fréquentes. Rétrogradation ⇒ chemin de restauration de l'état.
4. Références mortes : entrée requise (manquante = bloquant) / dépendance optionnelle (absente = ignorée) / sortie attendue (créée à l'exécution ; absence ≠ erreur). Référence morte ⇔ entrée requise manquante + pas de récupération.

Rapport : preuve → recommandation → impact → autorisation. Avant suppression : confirmer la récupérabilité (npx skills find) ; non récupérable ⇒ sauvegarder + demander. Résultats → registre.

4. Maintenance et application

Modèles de règles pour AGENTS.md, boucle de diagnostic d'échec de déclenchement, jeu de test de 15 scénarios, flux de publication → MAINTENANCE.md — à exécuter avant/après l'édition de cette compétence.