Transformez une idée produit en PRD clair pour design, engineering et leadership. — Claude Skill
Une compétence Claude pour Claude Code par Paweł Huryn — exécuter /write-prd dans Claude·Mis à jour le 13 juin 2026·vmain@d384f0c
Crée un PRD en huit sections couvrant contexte, problème, audience, objectif, métriques de succès, proposition de valeur, solution, périmètre de release, hypothèses et questions ouvertes.
- Transforme un contexte de fonctionnalité brut en PRD structuré que les personnes peuvent relire.
- Sépare contexte, problème, objectif, segment client, proposition de valeur, solution, hypothèses et périmètre de release.
- Garde une écriture simple pour que les parties prenantes non techniques comprennent quoi construire et pourquoi.
- Rend explicites v1, périmètre ultérieur, métriques de succès, risques et questions ouvertes avant estimation.
- Signale hypothèses et manques de mesure avant que l équipe traite le PRD comme prêt.
Un PM écrit un brief de fonctionnalité avec une solution, mais problème, audience, métrique de succès et limites de release restent flous.
Lancez /write-prd pour transformer l idée en PRD relisable avec objectifs mesurables, hypothèses et première release réaliste.
Pour qui
Transformer des idées produit en PRD structurés que design, engineering et leadership peuvent relire.
Voir les compétences de ce rôleUtiliser périmètre, hypothèses et critères de succès du PRD pour planifier la livraison plus fiablement.
Voir les compétences de ce rôleCe qu'il fait
Créer un PRD complet depuis une idée produit brute et des notes parties prenantes dispersées.
Restructurer un PRD existant pour rendre problème, périmètre, métriques et hypothèses évidents.
Donner à design et engineering assez de contexte pour challenger le périmètre et estimer l implémentation.
Fonctionnement
Collecte idée de fonctionnalité, utilisateurs cibles, raison business, recherche, contraintes et risques connus.
Rédige les huit sections du PRD : résumé, contacts, contexte, objectif, segment, proposition de valeur, solution et release.
Ajoute résultats clés mesurables et hypothèses explicites.
Sépare le périmètre de première release des améliorations ultérieures pour permettre à design et engineering d estimer, challenger et repousser.
Termine avec questions ouvertes et décisions de revue pour que les parties prenantes sachent ce qui manque encore.
Options d'entrée
Ce que vous voulez construire, pourquoi maintenant et quelles preuves existent déjà.
Exemple
Idée : améliorer le flow d invitation d équipe. Problème : les nouveaux admins n invitent pas leurs coéquipiers pendant le setup, et les équipes avec un seul utilisateur activent rarement. Audience : admins de workspaces B2B dans les 7 premiers jours. Preuves : 38 % activation, 24 % rétention semaine 4, 41 % complétion invitation, 18 tickets support mentionnent une confusion autour des invitations, 12 clients ont demandé des rappels Slack d invitation. Objectif business : améliorer l activation ce trimestre sans augmenter la charge support. Contrainte : la première release doit tenir en 6 semaines avec 2 engineers et un designer.
Construire un flow d invitation self-service qui aide les nouveaux admins à faire entrer leurs coéquipiers dans un workspace pendant le setup. Le PRD se concentre sur les 7 premiers jours après création du workspace, où la complétion d invitation est le signal le plus fortement lié à l activation.
Les admins de workspaces B2B créent souvent un workspace seuls et manquent l étape d invitation. Les équipes avec un seul utilisateur activent rarement car aucune boucle de collaboration n existe. Audience principale : nouveaux admins de workspace. Audience secondaire : coéquipiers invités qui ont besoin d une façon simple d accepter et rejoindre.
Objectif : aider les nouveaux admins à inviter les bons coéquipiers avant que le setup cale. Succès : activation de 38 % à 55 %, complétion invitation de 41 % à 65 %, tickets support liés au setup en baisse de 30 %, rétention semaine 4 de 24 % à 32 %.
Inclure une checklist de setup in-app, une option de rappel d invitation, un empty state plus clair quand aucun coéquipier n a rejoint, un écran de confirmation admin, et le tracking des événements invite sent, invite accepted et setup completed.
Exclure import CSV en masse, refonte complète des rôles/permissions, assistant setup SSO et provisioning account-level de la v1. Ces éléments peuvent compter pour les clients enterprise, mais ne sont pas requis pour tester si la complétion d invitation améliore l activation.
Hypothèses : les admins savent qui inviter; les rappels sont acceptables durant la première semaine; l activation s améliore quand un deuxième coéquipier rejoint avant le jour 7. Risques : fatigue de notification, ownership flou entre admin et coéquipier, tracking manquant de l acceptation d invitation.
Qui possède le copy des rappels Slack ? Les rappels doivent-ils être e-mail, Slack ou les deux ? Quelle formulation privacy-safe pour les invitations en attente ? Quelle source d événement fait autorité pour le reporting activation ?
Métriques améliorées
Compatible avec
Envie d'utiliser Document d exigences produit ?
Choisissez comment commencer.
Installez et exécutez cette compétence localement sur votre ordinateur.
Ouvrez un terminal sur votre ordinateur et collez cette commande :
Cela télécharge la compétence avec tous ses fichiers sur votre ordinateur :
Ajoutez -g à la fin pour le rendre disponible dans tous vos projets.
Démarrez Claude Code, puis tapez la commande :
Créer un Product Requirements Document
Objectif
Vous êtes un product manager expérimenté chargé de créer un Product Requirements Document (PRD) complet pour $ARGUMENTS. Ce document servira de spécification de référence pour votre produit ou fonctionnalité, alignera les parties prenantes et guidera le développement.
Contexte
Un PRD bien structuré communique clairement le quoi, le pourquoi et le comment d une initiative produit. Cette skill utilise un template en 8 sections éprouvé pour communiquer efficacement la vision produit aux ingénieurs, designers, leaders et parties prenantes.
Instructions
-
Collecter les informations : Si l utilisateur fournit des fichiers, lisez-les attentivement. S il mentionne recherche, URLs ou données clients, utilisez la recherche web pour obtenir du contexte supplémentaire et des insights marché.
-
Réfléchir étape par étape : Avant d écrire, analysez :
- Quel problème résolvons-nous ?
- Pour qui le résolvons-nous ?
- Comment mesurerons-nous le succès ?
- Quelles sont nos contraintes et hypothèses ?
-
Appliquer le template PRD : Créez un document avec ces 8 sections :
1. Résumé (2-3 phrases)
- De quoi parle ce document ?
2. Contacts
- Nom, rôle et commentaire pour les parties prenantes clés
3. Contexte
- Contexte : de quoi parle cette initiative ?
- Pourquoi maintenant ? Quelque chose a-t-il changé ?
- Est-ce quelque chose qui vient seulement de devenir possible ?
4. Objectif
- Quel est l objectif ? Pourquoi est-il important ?
- Comment bénéficiera-t-il à l entreprise et aux clients ?
- Comment s aligne-t-il avec la vision et la stratégie ?
- Résultats clés : comment mesurer le succès ? (Utilisez le format SMART OKR)
5. Segment(s) de marché
- Pour qui construisons-nous cela ?
- Quelles contraintes existent ?
- Note : les marchés sont définis par les problèmes/jobs des personnes, pas par la démographie
6. Proposition(s) de valeur
- Quels jobs/besoins clients adressons-nous ?
- Que gagneront les clients ?
- Quelles douleurs éviteront-ils ?
- Quels problèmes résolvons-nous mieux que les concurrents ?
- Considérez le framework Value Curve
7. Solution
- 7.1 UX/Prototypes (wireframes, user flows)
- 7.2 Fonctionnalités clés (descriptions détaillées)
- 7.3 Technologie (optionnel, seulement si pertinent)
- 7.4 Hypothèses (ce que nous croyons mais n avons pas prouvé)
8. Release
- Combien de temps cela pourrait-il prendre ?
- Qu est-ce qui va dans la première version vs les versions futures ?
- Évitez les dates exactes; utilisez des horizons relatifs
-
Utiliser un langage accessible : Écrivez pour une personne sortie de l école primaire. Évitez le jargon. Utilisez des phrases claires et courtes.
-
Structurer la sortie : Présentez le PRD comme un document markdown bien formaté avec titres et sections clairs.
-
Sauvegarder la sortie : Si le PRD est substantiel (ce qui sera le cas), sauvegardez-le comme document markdown au format :
PRD-[product-name].md
Notes
- Soyez spécifique et data-driven quand possible
- Reliez chaque section à la stratégie globale
- Signalez clairement les hypothèses pour que l équipe puisse les valider
- Gardez le document concis mais complet
Lectures complémentaires
Documents de référence
name: create-prd description: "Créer un Product Requirements Document avec un template complet en 8 sections couvrant problème, objectifs, segments, propositions de valeur, solution et planification de release. À utiliser pour rédiger un PRD, documenter des exigences produit, préparer une spec de fonctionnalité ou revoir un PRD existant."
Créer un Product Requirements Document
Objectif
Vous êtes un product manager expérimenté chargé de créer un Product Requirements Document (PRD) complet pour $ARGUMENTS. Ce document servira de spécification de référence pour votre produit ou fonctionnalité, alignera les parties prenantes et guidera le développement.
Contexte
Un PRD bien structuré communique clairement le quoi, le pourquoi et le comment d une initiative produit. Cette skill utilise un template en 8 sections éprouvé pour communiquer efficacement la vision produit aux ingénieurs, designers, leaders et parties prenantes.
Instructions
-
Collecter les informations : Si l utilisateur fournit des fichiers, lisez-les attentivement. S il mentionne recherche, URLs ou données clients, utilisez la recherche web pour obtenir du contexte supplémentaire et des insights marché.
-
Réfléchir étape par étape : Avant d écrire, analysez :
- Quel problème résolvons-nous ?
- Pour qui le résolvons-nous ?
- Comment mesurerons-nous le succès ?
- Quelles sont nos contraintes et hypothèses ?
-
Appliquer le template PRD : Créez un document avec ces 8 sections :
1. Résumé (2-3 phrases)
- De quoi parle ce document ?
2. Contacts
- Nom, rôle et commentaire pour les parties prenantes clés
3. Contexte
- Contexte : de quoi parle cette initiative ?
- Pourquoi maintenant ? Quelque chose a-t-il changé ?
- Est-ce quelque chose qui vient seulement de devenir possible ?
4. Objectif
- Quel est l objectif ? Pourquoi est-il important ?
- Comment bénéficiera-t-il à l entreprise et aux clients ?
- Comment s aligne-t-il avec la vision et la stratégie ?
- Résultats clés : comment mesurer le succès ? (Utilisez le format SMART OKR)
5. Segment(s) de marché
- Pour qui construisons-nous cela ?
- Quelles contraintes existent ?
- Note : les marchés sont définis par les problèmes/jobs des personnes, pas par la démographie
6. Proposition(s) de valeur
- Quels jobs/besoins clients adressons-nous ?
- Que gagneront les clients ?
- Quelles douleurs éviteront-ils ?
- Quels problèmes résolvons-nous mieux que les concurrents ?
- Considérez le framework Value Curve
7. Solution
- 7.1 UX/Prototypes (wireframes, user flows)
- 7.2 Fonctionnalités clés (descriptions détaillées)
- 7.3 Technologie (optionnel, seulement si pertinent)
- 7.4 Hypothèses (ce que nous croyons mais n avons pas prouvé)
8. Release
- Combien de temps cela pourrait-il prendre ?
- Qu est-ce qui va dans la première version vs les versions futures ?
- Évitez les dates exactes; utilisez des horizons relatifs
-
Utiliser un langage accessible : Écrivez pour une personne sortie de l école primaire. Évitez le jargon. Utilisez des phrases claires et courtes.
-
Structurer la sortie : Présentez le PRD comme un document markdown bien formaté avec titres et sections clairs.
-
Sauvegarder la sortie : Si le PRD est substantiel (ce qui sera le cas), sauvegardez-le comme document markdown au format :
PRD-[product-name].md
Notes
- Soyez spécifique et data-driven quand possible
- Reliez chaque section à la stratégie globale
- Signalez clairement les hypothèses pour que l équipe puisse les valider
- Gardez le document concis mais complet