Lenny Skills : 76 compétences PM en fichiers markdown, et ce que cela implique

Un problème de contexte, pas de génération

Un agent de code générique connaît la syntaxe, pas la méthode. Quand vous lui demandez de rédiger un PRD ou de prioriser un backlog, il produit un texte plausible qui mélange des cadres empruntés à droite et à gauche. Lenny Skills répond à ce problème précis : fournir des cadres nommés, attribués et vérifiés, que l'agent applique au lieu de les inventer. Le README annonce 76 compétences couvrant la stratégie, la planification, la découverte, la construction, le lancement, la croissance, l'équipe et la cadence opérationnelle, avec un total de 4 019 insights sourcés issus de 597 épisodes et articles. Le public visé est étroit : des équipes produit qui utilisent déjà un agent qui lit les fichiers SKILL.md, et qui veulent que cet agent raisonne avec les frameworks de praticiens identifiés plutôt qu'avec une moyenne de blog posts. Ce n'est pas un outil pour quelqu'un qui cherche un assistant PM clé en main.

Ce que contient réellement un dossier de compétence

Chaque compétence est un dossier sous skills/, par exemple skills/writing-prds/ ou skills/roadmap-prioritization/. Le README indique que chaque compétence embarque les frameworks, checklists et templates nommés que les invités utilisent réellement, dans un fichier references/artifacts.md. La version 2.0 ajoute le contenu de la newsletter : 349 articles, dont la série « How X builds product », alors que la 1.0 était podcast uniquement. Le mécanisme est donc documentaire, pas logiciel. L'agent lit le SKILL.md, y trouve une description de la tâche et un renvoi vers les artefacts, puis applique le cadre. La colonne « Sources » des tableaux du README donne un ordre de grandeur de la densité : 47 sources pour Defining Product Strategy, 9 pour Product Experimentation Excellence, 6 pour Product Stack Strategy. Cette dispersion est un signal utile : certaines compétences s'appuient sur un corpus large, d'autres sur une poignée d'épisodes. Le README précise aussi que chaque citation est vérifiée mot pour mot contre la transcription ou l'article source, ce qui distingue le dépôt d'un résumé généré.

Installation : deux commandes et une convention de chemin

L'installation tient en deux commandes, telles que le README les donne : git clone https://github.com/RefoundAI/lenny-skills.git puis cp -R lenny-skills/skills/writing-prds .claude/skills/. Le point important est le chemin de destination. Le dépôt ne fournit ni CLI, ni script d'installation, ni gestionnaire de paquets. Vous copiez un dossier dans .claude/skills/ et c'est tout. Le README mentionne aussi des liens de téléchargement individuels sur refoundai.com/lenny-skills pour récupérer une compétence isolée. Conséquence pratique : il n'y a pas de mise à jour automatique. Quand le dépôt passe de la 1.0 à la 2.0, votre copie locale ne bouge pas. Il faut re-cloner et recopier, ou suivre les changements à la main. Pour une équipe, cela signifie que la version des compétences utilisée par chaque développeur peut diverger silencieusement, à moins de versionner le contenu de .claude/skills/ dans le dépôt du projet. Le README ne décrit aucune procédure pour cela.

La licence MIT et ce qu'elle ne couvre pas

Le dépôt est publié sous MIT, ce qui autorise la copie, la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver l'avis de licence. Cette licence s'applique au code et aux fichiers du dépôt. Elle ne dit rien du statut des citations et des transcriptions sous-jacentes, qui proviennent du podcast et de la newsletter de Lenny Rachitsky. Le README ne traite pas ce point. Si vous redistribuez les compétences en l'état, ou si vous en extrayez les citations pour les republier ailleurs, la question du droit sur les propos cités se pose séparément de la licence MIT du dépôt. Je ne peux pas trancher à partir des éléments fournis : le dépôt ne contient ni mention de permission explicite des ayants droit, ni clause de citation. C'est un point à vérifier avant tout usage qui dépasse l'usage interne.

La limite structurelle : du texte, pas de l'exécution

Le dépôt ne contient pas de code applicatif. Il n'y a pas d'API, pas de serveur MCP, pas de tests, pas de sortie vérifiable. La valeur dépend entièrement de la qualité de lecture de l'agent qui consomme les fichiers. Si votre agent ne lit pas SKILL.md, le dépôt ne sert à rien. Si votre agent le lit mais ne suit pas les renvois vers references/artifacts.md, vous récupérez la description d'un cadre sans les templates qui l'accompagnent. Autre limite : le contenu est figé au moment de la génération. Les frameworks sont ceux que les invités du podcast décrivaient dans leurs épisodes, pas nécessairement ceux qu'ils appliquent aujourd'hui. Le README ne donne aucune date de dernière vérification par compétence, seulement la date de publication de la version 2.0. Enfin, la couverture est inégale par construction : avec 6 sources, Product Stack Strategy repose sur un corpus bien plus mince que les 47 sources de Defining Product Strategy. Le dépôt ne signale pas cette différence comme un avertissement, mais la colonne Sources la rend visible.

Face à une bibliothèque de prompts ou à un agent PM spécialisé

L'alternative la plus directe est une collection de prompts versionnés dans le dépôt de votre équipe. La différence n'est pas la qualité du texte, c'est la traçabilité. Un prompt maison ne cite personne et ne se vérifie pas. Ici, chaque compétence est rattachée à un nombre de sources identifié et à des citations contrôlées mot pour mot. En contrepartie, vous héritez d'une structure imposée : dossiers, SKILL.md, references/artifacts.md, et d'un contenu que vous ne pouvez pas ajuster sans casser le lien avec la source. Une autre approche consiste à utiliser un assistant PM hébergé, qui intègre les frameworks dans un produit avec interface. Vous gagnez la mise à jour continue et l'absence de manipulation de fichiers, vous perdez le contrôle local et la possibilité d'inspecter ce que l'agent lit réellement. Lenny Skills se situe entre les deux : plus traçable qu'un prompt, plus inspectable qu'un SaaS, mais sans automatisation d'aucun côté.

Coût de maintenance et rythme de version

Deux versions publiées : v1.0.0 le 29 janvier 2026, v2.0.0 le 16 juillet 2026. Le rythme observé est donc d'environ une version majeure tous les six mois, avec un changement de périmètre important entre les deux (ajout du contenu newsletter, réorganisation en modèle opératoire produit). Le coût de maintenance côté utilisateur est faible mais réel : recopier les dossiers, vérifier que les compétences que vous utilisez ont survécu à la réorganisation, et contrôler que le contenu de references/artifacts.md n'a pas changé de format. Le dépôt ne fournit pas de changelog détaillé par compétence, seulement des notes de version au niveau du dépôt. Si vous épinglez une version, vous ne saurez pas, sans diff manuel, ce qui a bougé dans une compétence donnée entre deux copies.

Conclusion éditoriale

Adoptez lenny-skills si votre équipe travaille déjà dans Claude Code ou un agent qui lit SKILL.md et que vous voulez des cadres PM nommés, avec citations vérifiées, plutôt que des prompts improvisés. Évitez-le si vous attendez un outil exécutable, une API ou des mises à jour automatiques. Avant de copier un dossier dans .claude/skills/, ouvrez le SKILL.md et le references/artifacts.md de la compétence concernée : c'est le seul moyen de vérifier que les frameworks correspondent à votre contexte, et le dépôt ne fournit aucun mécanisme de validation automatique.

Sources officielles

1. Issues
2. License: MIT
3. README
4. RefoundAI/lenny-skills on GitHub
5. Releases