Quand il vous faut un PRD pour lundi, /writing-prds rédige une spec centrée problème avec métriques de succès pour que les ingénieurs construisent sans trois rounds de review. — Claude Skill
Une compétence Claude pour Claude Code par Refound — exécuter /writing-prds dans Claude·Mis à jour le 5 juin 2026
Rédigez en quelques minutes un PRD centré problème avec contexte, métriques de succès et scope.
- Structure problem-led : background, Why Now, client, métriques de succès, scope, selon le « start with the why » de Maggie Crowley
- Option PR/FAQ pour specs working-backwards façon Amazon, selon Bill Carr
- Mode léger : PRD minimal d’Eric Simons centré sur les outcomes clés, pas les détails exhaustifs
- Variantes ère IA : prompt sets pour features IA (Aparna Chennapragada) et rubriques d’eval exécutables (Hamel Husain, Shreya Shankar)
- Prompt Why Now intégré pour défendre la priorité face aux opportunités concurrentes
Pour qui
Ce qu'il fait
Vous avez une semaine pour transformer une directive vague en spec buildable. /writing-prds structure background, problème, Why Now, client, métrique de succès et out-of-scope selon le format problem-first de Maggie Crowley.
Vous spécifiez une feature LLM et la prose ne suffit pas. /writing-prds génère un prompt set et une rubrique d’eval comme PRD, selon « demos before memos » d’Aparna Chennapragada et l’approche evals-as-PRD de Hamel Husain.
Leadership veut un PR/FAQ façon Amazon pour valider un pari. /writing-prds rédige une press release fictive plus FAQ en langage client, selon Bill Carr, factuel et comparable aux autres pitches.
Votre dernier PRD faisait 12 pages et les ingénieurs ont survolé les deux premières. /writing-prds le réécrit façon Eric Simons : contexte minimal, outcomes clés seulement et paragraphe Why Now justifiant le timing face aux autres paris.
Fonctionnement
Collez vos notes brutes, votre problem statement ou la transcription du kickoff
Répondez à trois questions de cadrage : problème, Why Now, mesure du succès
Choisissez le format : PRD classique, PR/FAQ Amazon, prompt set IA ou rubrique d’eval
Recevez un draft avec background, client, métriques de succès, scope et out-of-scope
Relisez les décisions ouvertes signalées inline et envoyez le PRD vers Linear, Notion ou Docs
Exemple
Problème : les utilisateurs Slack veulent @mentionner des équipes, pas seulement des individus Why Now : le churn T1 cite « impossible de ping une équipe » Cible de ship : fin du trimestre Engineering : 1 FE, 1 BE Question ouverte : fanout notifications, équipes imbriquées ?
Les utilisateurs Slack ping des individus des dizaines de fois par jour mais ne peuvent pas joindre toute une équipe en un message. Les interviews churn T1 ont remonté ce point dans 7 appels de sortie sur 12 (180K $ ARR). Les concurrents ont livré les team mentions le trimestre dernier. Attendre signifie plus de churn et une différenciation affaiblie.
Principal : engineering managers dans des orgs 20-200 personnes qui routent les questions à une équipe, pas une personne. Job : « demander à toute mon équipe sans deviner qui est on-call ». Aujourd’hui : ils gardent une liste privée, @mentionnent 3 personnes ou postent dans un canal que personne ne surveille.
Leading : 15 % des orgs actives utilisent @team dans les 4 semaines après GA Lagging : churn citant « team mentions » tombe à zéro sur T2 Guardrail : taux opt-out notifications sous 2 %
In : créer équipe, @mention, respect DND notification, équipes plates seulement Out : équipes imbriquées, mentions équipes externes, UI présence par équipe Décisions ouvertes : cap fanout (signalé pour review engineering)
Métriques améliorées
Compatible avec
Envie d'utiliser Rédaction de PRD ?
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 :
Writing PRDs
Aidez l’utilisateur à rédiger des Product Requirements Documents clairs et actionnables.
Comment aider
- Commencer par le pourquoi - Clarifiez le problème et pourquoi il compte maintenant avant les features.
- Définir le succès dès le départ - Écrivez les métriques leading, lagging et guardrails.
- Choisir le bon format - PRD classique, PR/FAQ, prototype, prompt set ou eval exécutable.
- Rendre le document actionnable - Scope, hors scope, décisions ouvertes, owners et prochaines étapes.
Principes clés
Un bon PRD mène par le problème et le contexte. Il ne remplace pas la conversation avec engineering, mais la rend plus courte et plus précise. Pour les features IA, les prompts et evals peuvent être la spec la plus utile.
Sortie attendue
Livrez background, Why Now, client, problème, objectifs, métriques, scope, hors scope, risques, décisions ouvertes et version prête à coller dans Notion, Jira ou Docs.