hamgarian/loot-skill

skill-factory (usine à compétences)

Construit une compétence comme le ferait un mainteneur méticuleux, puis retient la publication jusqu'à ce que l'utilisateur l'approuve. Fonctionne dans n'importe quel agent ; chaque étape nomme le meilleur outil et une solution de repli qui fonctionne toujours.

Entrée : une idée de compétence, ou un butin remis par loot avec ses preuves (requête, résultats de recherche, preuve, cas limite). Dossier cible : là où l'utilisateur le dit, sinon ../<slug> en dehors de l'historique du dépôt courant.

1. Spécifications

Rédigez SPEC.md : objectif, entrées et sorties, et une checklist d'acceptation où chaque ligne peut être testée. Tenez-vous à une page. Si loot a remis l'élément, réutilisez ses preuves au lieu de chercher à nouveau. Ne demandez à l'utilisateur que lorsque deux interprétations de l'idée produiraient des compétences différentes.

2. Construction, tests d'abord

• Si l'agent dispose d'un assistant de création de compétences (dans Claude Code : anthropic-skills:skill-creator), utilisez-le pour la compétence et ses évaluations.
• Sinon, rédigez SKILL.md vous-même : préambule avec name (en kebab-case) et une description qui dit ce qu'elle fait et quand la déclencher, puis les étapes.
• Les scripts reçoivent des tests avant le code (node:test ou pytest). Implémentez jusqu'à ce qu'ils réussissent. Écrivez les fichiers avec votre outil d'édition de fichiers, pas avec des heredocs shell.
• Exécutez chaque test et évaluation. Gardez la commande exacte et sa sortie pour l'étape 4.

3. Révision indépendante

Le constructeur ne note pas son propre travail.

• Meilleur : lancez un sous-agent qui n'a pas vu cette conversation. Donnez-lui uniquement le dossier cible et references/release-checklist.md avec cette consigne : « Examinez la compétence dans par rapport à la checklist. Répondez PASS ou ÉCHEC par élément avec preuve fichier:ligne. En cas de doute, ÉCHEC. Signalez toute affirmation que les tests ou évaluations ne prouvent pas. »
• Repli : pas de sous-agents : pour chaque élément de la checklist, écrivez le meilleur argument qu'il ÉCHOUE avant de décider.

Corrigez chaque ÉCHEC, relancez les tests, révisez à nouveau. Arrêtez-vous lorsque tous les éléments passent, ou lorsqu'un élément est bloqué par l'utilisateur (dites lequel et pourquoi).

4. Porte de libération

Analysez les secrets : node <dossier compétence loot>/scripts/scan.mjs <dossier>, plus gitleaks dir <dossier> si installé. Montrez ensuite un manifeste à l'utilisateur et arrêtez-vous pour un oui clair :

• nom du dépôt, public ou privé
• version et ligne du journal des modifications
• les fichiers à publier
• résultats des tests et évaluations (commande + nombre de réussites), le verdict de la révision
• tout ce qui a été sauté

Un oui couvre exactement ce manifeste. Publiez ensuite à partir d'un git init frais : committez release vX.Y.Z, taguez, gh repo create et poussez, puis installez la compétence là où l'agent de l'utilisateur charge les compétences. Pas de gh ou pas connecté : imprimez les commandes. Ne demandez, ne tapez et ne stockez jamais d'identifiants.

5. Rapport

Un court message en langage clair : liens, résultats des tests, résultat de la révision, et ce qui reste à l'utilisateur.