loot-skill

loot

Chaque session laisse du butin. La plupart meurt dans le journal de discussion. Votre travail : le trouver, l'écrire, le juger sur des preuves plutôt que sur l'enthousiasme, et ne publier que la pièce rare qui le mérite, après que l'utilisateur a dit oui.

La majeure partie de la valeur de loot est LOOT.md : un enregistrement continu de tout ce que l'utilisateur a découvert. La publication est l'exception.

Le butin est toute partie précieuse de la session, pas seulement les découvertes secondaires :

Type	À quoi ça ressemble	Forme habituelle
Construction	l'application, l'outil ou le script dont il était question dans la session	dépôt
Composant	une pièce qui fonctionne en dehors de ce projet (un hook, un analyseur, une configuration, un prompt)	dépôt ou gist
Technique	une astuce, un correctif ou une méthode (a rendu X 4× plus rapide, a fait fonctionner Y localement)	article + gist ou dépôt
Savoir-faire	les corrections et retours que l'utilisateur vous a donnés et qui ont amélioré la sortie	skill
Histoire	le chemin du problème au résultat, y compris les impasses	article
Données	benchmarks, comparaisons, mesures	article ou README du dépôt

Une session contient souvent plusieurs éléments. Un seul élément mérite souvent plusieurs formes (dépôt + article + démo).

Modes

Commande	Fait
/loot	analyser cette session, afficher le tableau, demander quoi publier
/loot "<sujet>"	ne regarder qu'une seule chose (moins coûteux) : "l'astuce ffmpeg"
/loot 2, /loot all	publier l'élément 2, ou tous les éléments notés Rare ou mieux, sans demander lesquels
/loot --list	lister les sessions passées récentes pour choisir
/loot <session.jsonl>	analyser une session passée au lieu de celle-ci
/loot review	réévaluer ce qui se trouve déjà dans LOOT.md (voir étape 6)

1. Analyser

Lisez toute la conversation et les fichiers qu'elle a touchés. Pour une session passée, ou lorsque les premières parties de celle-ci ont été résumées, lisez la transcription à la place :

node <dossier de ce skill>/scripts/transcript.mjs list          # sessions Claude Code + Codex récentes
node <dossier de ce skill>/scripts/transcript.mjs read <fichier>   # texte condensé, secrets masqués

La transcription de cette session est le fichier le plus récent dans ~/.claude/projects/<projet>/. Si vous n'avez pas pu lire au-delà d'un résumé, dites-le dans le tableau : les premières découvertes peuvent manquer. Listez les candidats. Pour chacun, notez ce qu'il fait et la preuve qu'il fonctionne (test, benchmark, avant/après, la réaction de l'utilisateur).

Abandonnez un élément lorsqu'il ne fonctionne que dans la configuration de cet utilisateur et ne peut pas être généralisé, lorsqu'il s'agit principalement du code de quelqu'un d'autre, ou lorsqu'il s'agit du travail privé ou client de l'utilisateur. Ne mentionnez pas les secrets, identifiants ou données personnelles de la session dans le tableau.

2. Évaluer

L'évaluation est un filtre, et son travail est de dire non. Vous êtes un mauvais juge du travail que vous venez d'aider à produire : vous ne pouvez pas dire ce qui est nouveau dans le monde, et vous avez tendance à flatter l'utilisateur. Donc la rareté vient des preuves, et le jugement se fait en dehors de la conversation.

Collectez les preuves pour chaque candidat :

• requête : ce qu'un inconnu ayant ce problème taperait dans un moteur de recherche
• recherche : exécutez-la (web, GitHub, npm/PyPI) et listez les résultats les plus proches avec des liens. Recherchez ce qu'il fait, pas son nom. Pas d'outil de recherche : "non vérifié".
• preuve : un test, un benchmark ou un avant/après qui a réellement eu lieu dans la session, avec l'endroit (la commande, le fichier, le message), ou "aucune". Ne reconstruisez jamais une preuve de mémoire : les notes d'IA inventent des noms, des nombres et des détails.
• avantage : ce qu'il fait que le résultat le plus proche ne fait pas, mesuré si possible

Évaluez ailleurs. Si vous pouvez lancer un sous-agent, donnez-lui uniquement les candidats et leurs preuves, jamais la conversation, avec cette consigne : "Évaluez chaque élément par rapport au barème ci-dessous. Argumentez d'abord pour Commun et ne montez un élément que lorsque ses preuves atteignent le barème. En cas de doute, évaluez plus bas. N'utilisez que les preuves données ; n'en ajoutez ou n'en supposez jamais. Pour tout élément une exigence en dessous du palier suivant, nommez la preuve la moins chère qui le ferait monter." Si vous ne pouvez pas, écrivez l'argument le plus fort pour que chaque élément soit Commun avant de l'évaluer.

Rareté	Nécessite tout	Formes
Commun	n'importe quoi en dessous de Rare	une ligne dans LOOT.md
Rare	une vraie requête ; une recherche citée qui n'a rien trouvé d'équivalent, ou un avantage mesuré par rapport au résultat le plus proche ; une preuve que ça fonctionne	gist, article court, ou un petit dépôt ou skill
Épique	Rare, plus un avantage mesuré par rapport à une alternative nommée, et ça fonctionne depuis un clone propre	dépôt ou skill, article, démo, brouillons de lancement

Règles strictes :

• "non vérifié" ou "aucune preuve" signifie Commun, aussi bon que cela puisse paraître.
• Quelque chose d'équivalent existe et l'avantage n'est pas mesuré : Commun. Un avantage argumenté à partir des README d'autres projets n'est pas mesuré.
• Les égalités sont arrondies à l'inférieur.
• Les quasi-échecs obtiennent une prochaine étape. Un élément une exigence en dessous du palier suivant est étiqueté [COMMUN, presque Rare] ou [RARE, presque Épique] et reçoit une ligne suivant : : la preuve la moins chère qui le ferait monter, et approximativement combien de temps cela prend. Cela transforme un "non" en une tâche que l'utilisateur peut choisir.
• Attendez-vous à ce que presque tout soit Commun. Si plus d'un élément dans une session est évalué au-dessus de Commun, dites pourquoi cette session est l'exception.
• Commun n'est pas un échec. C'est l'entrée de journal qui empêche le travail d'être perdu.

Affichez le tableau du butin, avec les preuves pour tout ce qui est au-dessus de Commun, et arrêtez-vous :

BUTIN : 3 éléments
1. [RARE, presque Épique] remotion-ae-transitions : Transitions de type After Effects dans Remotion, entièrement local
   requête : "remotion after effects transitions"
   recherche : @remotion/transitions (glissés, fondus, volets), un pack de modèles payant ; aucun ne fait ça
   preuve : 6 transitions rendues et approuvées dans la session
   avantage : non mesuré, donc pas Épique → gist + article court
   suivant : rendre les mêmes 3 plans avec @remotion/transitions et comparer ; puis un run sur clone propre (~45 min)
2. [COMMUN] astuce ffmpeg deux passes : documentée dans le wiki ffmpeg → LOOT.md
3. [COMMUN] chargeur de polices personnalisé : utile uniquement dans ce projet → LOOT.md
Publier quoi ? (numéros, "all", ou "none")

Affichez au maximum 7 éléments, les plus forts en premier. Tout le reste obtient une ligne sous "noté".

Après avoir affiché le tableau, ajoutez-le à LOOT.md à la racine du projet (créez-le s'il manque), daté. Un élément mérite une entrée complète uniquement si une session future ferait une erreur, ou referait un vrai travail, sans elle. Sinon, c'est une entrée "noté" d'une ligne. Le journal n'est utile que s'il reste lisible.

3. Forger

Pour chaque élément choisi, construisez la chose finie dans un nouveau dossier en dehors de l'historique du dépôt actuel (par défaut ../<slug>, ou là où l'utilisateur dit). Lisez references/forge.md pour la liste de contrôle de chaque forme. En bref :

• Généralisez-le. Supprimez les noms de projet, les chemins codés en dur, les détails clients et le code mort. Il doit fonctionner à partir d'un clone propre avec les étapes du README. Exécutez-le.
• Nommez-le. Court, mémorisable, dit le travail. Vérifiez que le nom est libre : gh search repos <nom>, npm view <nom> (code de sortie 1 signifie libre).
• Slogan. Une ligne qui dit à un inconnu ce que ça fait et pour qui.
• Logo. Simple, une ou deux couleurs, lisible à 16px, fonctionne sur fond clair et foncé.
• Aperçu social. Une carte 1280×640 (logo, nom, slogan) pour que les liens partagés affichent une image au lieu d'une carte GitHub vierge.
• README. Résultat d'abord, puis démarrage rapide, puis comment ça fonctionne.
• Preuve. Un test, un benchmark, ou un avant/après. N'inventez jamais de chiffres.

Skills : si la forme choisie est un skill, suivez le skill skill-factory qui est livré à côté de celui-ci (../skill-factory/SKILL.md), en lui donnant les preuves de l'élément (requête, résultats de recherche, preuve, avantage) comme spécification de départ. Ignorez les étapes 3 à 5 pour cet élément : skill-factory teste, révise et contrôle lui-même la publication.

4. Vérifier (ne jamais sauter)

1. Scannez chaque dossier que vous allez publier pour détecter les secrets :

   • toujours : node <dossier de ce skill>/scripts/scan.mjs <dossier>
   • aussi, si gitleaks est installé : gitleaks dir <dossier>, et gitleaks git <dossier> lorsque le dossier a un historique git.

   Corrigez chaque constatation, ou marquez un faux positif avec loot:allow sur cette ligne et dites pourquoi. Examinez chaque ligne warn à la main. Ne poussez jamais un historique git existant que gitleaks n'a pas scanné ; sans gitleaks, publiez à partir d'un nouveau git init à la place.

2. Lisez chaque fichier qui sera publié. Cherchez les données personnelles, les noms de clients, les noms d'hôtes internes, les liens de dépôts privés et le code sous une autre licence.

3. Montrez à l'utilisateur un manifeste : chaque destination (nom du dépôt, public ou privé, brouillon d'article ou en direct), les fichiers, le slogan. Demandez un oui clair. Un oui couvre exactement ce manifeste, rien de plus.

5. Publier

Lisez references/ship.md pour les commandes et les solutions de repli. Utilisez d'abord vos propres outils ; en dernier recours, remettez à l'utilisateur une commande ou un fichier prêt à être exécuté.

• Dépôt : gh repo create, description, sujets, pousser.
• Article : dev.to ou Hashnode en tant que brouillon lorsqu'un jeton est déjà configuré ; sinon un fichier Markdown. Medium : Markdown plus instructions d'importation.
• Publications de lancement (Show HN, X, Reddit), Épique uniquement : brouillons dans un dossier launch/ ignoré par git. Ne les publiez jamais.
• Terminez avec des liens vers tout ce qui a été publié et tout ce qui reste pour l'utilisateur.

6. Réviser (/loot review)

Les évaluations d'une seule session sont une supposition. Les preuves s'accumulent avec le temps :

1. Lisez LOOT.md. Regroupez les entrées qui sont la même chose vue à nouveau (même idée racine, même si formulée différemment).
2. Réévaluez un élément lorsque quelque chose a changé : il est apparu dans 3 sessions ou plus, il a gagné des preuves (utilisateurs, un benchmark, quelqu'un l'a demandé), ou une nouvelle recherche ne trouve plus rien d'équivalent. Utilisez les mêmes règles de preuve et le même évaluateur externe.
3. Montrez ce qui a bougé et pourquoi. Écrivez une section "review" datée dans LOOT.md ; ne réécrivez jamais les anciennes entrées. Ensuite, proposez de publier tout ce qui est maintenant Rare ou mieux.

Utiliser ce que l'agent a

Besoin	Meilleur	Solution de repli qui fonctionne toujours
Logo / image de couverture	votre propre génération d'images ou un MCP d'images, si vous en avez un	SVG dessiné à la main
Analyse de secrets	gitleaks (couvre aussi l'historique git)	scripts/scan.mjs inclus
Vidéo de démo	Remotion (Node)	captures d'écran + GIF
Captures d'écran	un outil de navigateur	demandez-en une à l'utilisateur
"Ça existe ?"	recherche web	marquez "non vérifié" (le limite à Commun)
Sessions passées ou résumées	scripts/transcript.mjs (Claude Code, Codex)	demandez à l'utilisateur de coller ou d'exporter la conversation
Évaluation indépendante	un sous-agent qui ne voit jamais la conversation	le cas le plus fort pour Commun, écrit en premier
Publier un dépôt	CLI gh	imprimez les commandes
Publier un article	l'API de la plateforme avec un jeton existant	fichier Markdown

Règles

• Rien ne devient public sans le oui de l'utilisateur sur le manifeste exact.
• Ne demandez, ne tapez et ne stockez jamais d'identifiants. Si un outil n'est pas connecté, utilisez une solution de repli.
• Ne publiez jamais de secrets, de données personnelles, ou de travail client ou employeur.
• Respectez les licences : ne changez pas la licence d'un code que vous n'avez pas écrit.
• Pas de preuve inventée : pas de benchmarks, d'utilisateurs, de citations ou de comptes d'étoiles faux.
• Écrivez dans la voix de l'utilisateur du chat, pas comme un communiqué de presse.