PLAID en Pratique - J'ai Fait Passer une Vraie Idee de Produit Dans ce Skill Idea-to-Launch

Il y a quelques semaines, j’ai ecrit sur la bibliotheque agent-skills d’Addy Osmani et sur la maniere dont le format skill a progressive disclosure d’Anthropic redefinit discretement ma facon de faire du travail agentique serieux. Les skills d’Osmani sont une discipline d’ingenierie generique - la boucle spec -> plan -> build -> test -> review -> ship dont toute base de code a besoin. Ils supposent que tu sais deja ce que tu construis.

PLAID (Product Led AI Development), de buildgreatproducts, s’attaque a l’autre moitie du probleme. C’est le skill qui tourne avant que tu ne tapes /spec. Il fait passer un founder de “j’ai une idee vague” a vision produit + PRD + build roadmap + plan go-to-market, dans une seule conversation orchestree. La ou les skills d’Osmani sont une bibliotheque SDLC horizontale, PLAID est un pipeline vertical vise a un utilisateur precis : le founder solo ou en petite equipe qui veut shipper.

J’ai passe une soiree a faire tourner PLAID de bout en bout sur une idee de produit pilote jetable. Voici ce qu’il a vraiment produit, ce qui est authentiquement bon, et ou les fissures apparaissent.

Ce Qu’est PLAID, en Bref

PLAID est un seul skill Claude Code avec trois capabilities :

Capability	Ce qu’il fait	Output
Plan	Conversation d’intake de vision + generation de documents	`vision.json`, `product-vision.md`, `prd.md`, `product-roadmap.md`
Launch	Plan go-to-market a partir de la vision	`gtm.md`
Build	Execute le roadmap phase par phase, commit apres chacune	Code qui tourne, historique git phase par phase

Le skill complet fait environ 2 800 lignes de markdown reparties entre SKILL.md et dix fichiers de reference (prompts de generation, schema, guide d’intake, comparaison de tech stacks). Il y a un seul validateur Node.js sans aucune dependance. C’est tout. Pas de framework d’agent, pas de machine a etats, pas d’UI - juste un ensemble d’instructions bien ecrites que le modele suit.

L’installation tient en une ligne :

npx skills add BuildGreatProducts/plaid

Ou manuellement, ajoute le chemin vers SKILL.md dans ton .claude/settings.json :

{
  "skills": ["/absolute/path/to/plaid/SKILL.md"]
}

Puis dans une session Claude Code, tape PLAID ou plan a product et le skill se charge.

Le Test

Il me fallait une idee de test suffisamment realiste pour pouvoir juger la qualite du output. J’en ai pris une dans mon propre backlog :

Currency Coach - une app mobile pour les pilotes IFR-rated qui ingere leur logbook ForeFlight ou Garmin Pilot existant, modelise la decroissance de chaque competence de vol individuelle (ILS, LPV, circling, nuit, vent de travers, IMC a la main), et delivre un verdict pre-vol pour un trajet specifique planifie. Pas “es-tu en regle ?” mais “es-tu assez affute pour ce samedi, et sinon, quelle seule session de 45 minutes reglerait ca ?”

Je suis l’utilisateur cible, donc je peux faire la difference entre un PRD qui comprend le vol IFR et un qui produit du cosplay d’aviation. Bon banc de test.

J’ai lance l’intake de vision de PLAID, rempli les huit sections (founder, purpose, product, audience, business, feeling, tech stack, tooling), sauvegarde les reponses dans vision.json, lance le validateur (qui est passe du premier coup, petit detail qui compte), puis genere les trois documents.

Le Output

Trois fichiers dans docs/ :

product-vision.md - 49 Ko, environ 8 000 mots. Vision, mission, core values, piliers strategiques, personas primaires + secondaires, JTBD, pain points, paysage concurrentiel, scope du MVP avec out-of-scope explicite, voix de marque avec exemples DO/DON’T, design tokens avec valeurs hex, specs typographiques, echelle de spacing.
prd.md - 72 Ko, environ 9 200 mots. Table du stack, diagramme d’architecture Mermaid, schema Convex complet avec 12 tables, specification d’API, 24 exigences fonctionnelles avec criteres d’acceptance, UI ecran par ecran avec etats empty/loading/error/populated, config Tailwind avec design tokens, implementation d’auth, integration d’abonnement, edge cases, questions ouvertes.
product-roadmap.md - 38 Ko, environ 5 200 mots. 72 taches reparties sur 5 phases, chaque tache avec chemins de fichiers, un prompt de phase que tu peux coller directement dans Claude Code, et un bloc “reference sections to load” pour que l’agent n’ait pas a charger tout le PRD en contexte a chaque phase.

Ce n’est pas un stub. C’est la forme d’une vraie spec produit, produite en moins de 20 minutes de temps modele a partir d’un vision.json.

Ce Qui Marche Vraiment

1. L’Intake de Vision EST le Produit

Le guide d’intake (references/INTAKE-GUIDE.md) est la meilleure chose du repo. Huit sections, environ quarante questions, chacune avec :

Le texte de la question plus une justification en une phrase de pourquoi elle compte
Un prompt pour generer trois suggestions substantiellement differentes sur la base de ce que le founder a dit jusqu’ici
Une regle explicite que les deux premieres questions (nom, expertise) n’ont pas de suggestions (saisie directe uniquement)
Une regle que les suggestions doivent s’ameliorer dans le temps, pas juste reformuler le contenu precedent

La section tech stack est particulierement bonne. Elle utilise un format de table comparative qui pose Next.js vs Remix vs SvelteKit avec des pros/cons honnetes, puis fait une recommandation specifique liee aux reponses precedentes du founder. Les recommandations par default (Next.js pour le web, Expo pour mobile, backend Convex, Clerk ou Convex Auth, Polar ou RevenueCat) sont opinionated mais bien justifiees. Tu peux override n’importe laquelle, mais les defaults sont suffisamment bons pour que la plupart des solo founders devraient juste les prendre.

C’est la que le scope founder-specifique de PLAID paie. Un skill de spec generique ne peut pas demander “quel est ton revenue target a 90 jours” ou “qui es-tu uniquement positionne pour aider” parce que ces questions ne conviennent pas a tous les utilisateurs. PLAID se focalise durement sur l’archetype du founder et gagne le droit de les poser.

2. La Cascade de Trois Docs

PLAID est strict sur le fait que les docs soient generes dans l’ordre - vision d’abord, puis PRD qui lit la vision, puis roadmap qui lit les deux. C’est evident avec le recul mais rare en pratique. La plupart des outils de generation de docs traitent chaque artefact comme independant. La cascade de PLAID fait que les tokens poses tot (design tokens, noms de skills, magic moment) se propagent de maniere coherente jusqu’aux notes de roadmap au niveau tache.

Dans mon run, les color tokens choisis dans la vision (#0A0C10 pour l’encre, un amber warning, une sauge mutee pour “sharp”) apparaissaient verbatim dans la config Tailwind du PRD puis encore dans les taches de Phase 0 du roadmap (“copie la config Tailwind complete depuis PRD § 9”). J’ai fait zero travail de reconciliation. C’est le genre de coherence cumulative que tu n’obtiens normalement qu’avec un humain qui a ecrit les trois documents en une seule seance.

3. Le Format de Tache

Chaque tache du roadmap utilise exactement cette forme :

- [ ] **TASK-023** - Implement the decay-model unit tests.
  Files: `convex/decayModel.ts`, `convex/decayModel.test.ts`
  Notes: Test half-life curves for each skill type. Seed with 50 flights
  from fixtures/sample-logbook.json. Expected accuracy >= 90% vs labels.

En plus, chaque phase a un bloc “Reference sections to read before starting” pointant vers des sections specifiques de la vision et du PRD. Ca compte parce que ca veut dire que l’agent de build n’a pas a charger 72 Ko de PRD en contexte pour chaque tache. Il charge juste les sections pertinentes. C’est du progressive disclosure applique a l’interieur d’un seul projet - exactement le bon move.

4. Le Validateur

node scripts/validate-vision.js --migrate fait 340 lignes de Node.js sans aucune dependance externe. Il verifie le schema JSON, applique les migrations si tu as un vision.json plus ancien d’une version PLAID precedente, et rapporte des warnings sans bloquer. C’est une touche mineure et ca change completement le ressenti. La plupart des “AI skills” ne livrent pas de validateur. En livrer un signale que les auteurs pensent a ca comme de l’ingenierie, pas du prompting.

5. Resumabilite

Les fichiers de capability de PLAID verifient tous l’etat du projet a l’entree : est-ce que vision.json existe ? Les docs sont-ils presents ? Le roadmap est-il partiellement fait ? Puis il reprend la ou ca s’est arrete. Tu peux fermer une session en plein intake et revenir dans une semaine, et le skill te dira exactement ou tu as mis en pause. Ca se marie naturellement avec la philosophie du skills framework selon laquelle “les skills sont des workflows, pas des prompts one-shot”.

Ou les Fissures Apparaissent

Je veux etre honnete ici parce que la raison pour laquelle je teste ces choses, c’est pour savoir quand leur faire confiance.

1. Vision et PRD Se Recoupent Plus Qu’ils Ne Devraient

La section Product Strategy de product-vision.md inclut scope MVP et out-of-scope. Les sections Overview et “Out of Scope” de prd.md couvrent le meme terrain. Les guides de generation disent au modele “ne repete pas d’information entre sections” puis donnent des exigences de section qui forcent la repetition. J’ai fini avec trois formulations legerement differentes de la meme liste de scope a trois endroits differents. Une structure plus propre mettrait le scope une seule fois (dans la vision) et ferait que le PRD y fasse reference.

2. Le Template de PRD Biaise Vers REST

Le guide de generation du PRD inclut des exemples d’endpoints REST (method, path, request body, response body). Pour une app Convex - que PLAID lui-meme recommande comme backend par default - il n’y a pas d’endpoints REST, juste des queries et mutations typees. Le modele a correctement ignore le template REST et produit des signatures Convex RPC, mais il a du se battre contre le template pour le faire. Un template stack-aware (un pour REST, un pour Convex, un pour tRPC) eliminerait cette friction. Ca merite une PR.

3. La Granularite des Taches de Roadmap est Aspirationnelle

PLAID prescrit des taches dimensionnees pour 15-45 minutes de travail d’agent. Certaines taches sorties de mon test run sont clairement multi-sessions - “TASK-021 : Implement the decay-model classifier with >= 90% accuracy on a 50-flight labeled set.” C’est un probleme de recherche, pas une tache de 30 minutes. La regle empeche le modele de le dire. Tu te retrouves avec des taches nominalement atomiques mais pratiquement multi-jours, ce qui cree un faux sentiment de scope. Je prefererais que le skill dise “certaines taches sont classees Research, voici comment les gerer” plutot que de forcer tout dans la meme granularite.

4. Les Defaults Opinionated Coupent Dans les Deux Sens

PLAID est fortement opinionated : Convex, Clerk ou Convex Auth, Polar pour les paiements web, RevenueCat pour mobile. Si tu es d’accord, tu gagnes des heures - les sections auth et paiements du PRD sortent implementation-ready avec des patterns de code Convex + RevenueCat specifiques. Si tu n’es pas d’accord, le skill se bat contre toi. Le fichier de comparaison de tech stacks liste honnetement les alternatives (Supabase, Firebase, Stripe, etc.) mais les guides de generation supposent implicitement les defaults. Les founders sur un stack Stripe + Postgres + Supabase obtiendront un output utile mais moins poli.

C’est le bon trade-off pour l’audience cible de PLAID (solo founders qui veulent shipper) et le mauvais pour la mienne sur certains projets. Sache de quel cote tu es avant de t’engager.

5. Pas de Tests dans le PRD ou le Roadmap

C’est celui qui m’empechera d’utiliser PLAID tel quel sur quoi que ce soit de serieux. Le PRD a une section “Non-Functional Requirements” qui mentionne des seuils de qualite, mais les 72 taches du roadmap n’incluent pas une seule tache pour ecrire des unit tests ou des integration tests. Le testing est absent du scaffolding de phase-prompt. C’est exactement ce que le skill test-driven-development d’Osmani existe pour corriger.

La solution honnete est de superposer : utiliser PLAID pour generer la vision + PRD + roadmap, puis faire tourner les skills d’Osmani (ou equivalent) par-dessus pour l’implementation test-first, la code review, et le shipping. C’est comme ca que je vais l’utiliser desormais.

Comment PLAID se Place a Cote de Agent-Skills d’Osmani et Spec Kit

Les trois sont complementaires, pas concurrents :

Dimension	PLAID	Agent-Skills (Osmani)	Spec Kit (GitHub)
Scope	Vertical founder : idea -> launch	Bibliotheque SDLC generique horizontale	Cycle de vie Spec-Driven Development
Quand s’en servir	Nouveau produit, pas encore de docs	Toute base de code, toute phase	Demarrage d’un projet greenfield
Unite principale	Cascade 3-docs (vision/PRD/roadmap)	20+ skills specifiques a une phase	Scaffolding de slash-command
Stack opinionated ?	Oui - defaults Convex/Clerk/Polar/RevenueCat	Non	Non
Testing integre ?	Absent	Skill central	Implicite dans le flux a portes
Anti-rationalization	Implicite	Explicite par section dans chaque skill	Implicite dans les portes de phase

Mon workflow emergent pour un produit greenfield :

PLAID Plan pour generer vision.json, product-vision.md, prd.md, product-roadmap.md. Environ une heure incluant la conversation d’intake. J’edite les docs a la main pour tout ce que PLAID a rate ou oublie.
Trim et annote les taches du roadmap - signale les multi-sessions, ajoute une poignee de taches de test explicites, ajuste la granularite.
Les /spec, /plan, /build, /test, /review, /ship d’Osmani pour l’execution. Ces skills vivent par-dessus les artefacts de PLAID, pas en dessous.
PLAID Launch pour le plan GTM quand je suis pret a annoncer.
Utiliser PLAID Build uniquement sur les phases de scaffold vraiment triviales (setup Phase 0, plomberie). Pour tout ce qui n’est pas trivial, je prefere les skills d’Osmani a cause de la discipline de testing.

Ce Qu’il Faut Retenir

PLAID est le premier skill que j’ai vu qui traite la definition de produit comme un workflow de premier ordre, pas comme un effet de bord du prompting. Le guide d’intake a lui seul est une version plus propre et plus opinionated de ce que la plupart des founders essaient (et echouent) d’extraire de ChatGPT sur une douzaine de sessions brouillonnes. La cascade de trois docs est une vraie innovation en coherence imposee. Le validateur est un signal discret que les auteurs se soucient de l’ingenierie de la chose.

C’est aussi plus etroit que la bibliotheque d’Osmani et ca manque de la couche de testing qui transforme une spec en produit digne de confiance. Ne l’utilise pas comme stack agentique complet. Utilise-le comme front end d’un stack.

Si tu es un founder qui fixe un repertoire docs/ vide, lance PLAID ce soir. Si tu es un ingenieur avec une base de code deja en vol, reste avec Osmani. Si tu demarres un produit greenfield et que tu veux le faire proprement, utilise les deux.

References

buildgreatproducts/plaid - Le repo du skill PLAID
Mon article precedent sur le framework skills - Agent-Skills, progressive disclosure, et pourquoi tout ca compte
addyosmani/agent-skills - La bibliotheque de skills SDLC horizontale
github/spec-kit - Le toolkit Spec-Driven Development de GitHub
skills CLI - L’installateur npx skills add
La doc skills d’Anthropic - Le format sous-jacent