kelegele/oh-my-pm

Génération de PRD

Générer des Documents de Spécifications Produit structurés à partir d'idées de fonctionnalités.

Ce que fait cette compétence

Transforme des demandes de fonctionnalités informelles en PRD complets comprenant des user stories, des critères d'acceptation, des exigences fonctionnelles, des indicateurs de succès et des recommandations de conformité. Le résultat est prêt à être implémenté par les équipes d'ingénierie et examiné par les parties prenantes.

Quand l'utiliser

Activez cette compétence lorsque :

• L'utilisateur souhaite documenter une nouvelle fonctionnalité ou une idée de produit
• Des expressions comme « rédiger un PRD », « créer des spécifications », « documenter cette fonctionnalité »
• Préparation d'une revue produit, d'un alignement des parties prenantes ou d'un transfert vers l'ingénierie
• L'utilisateur mentionne des user stories, des critères d'acceptation ou des indicateurs de succès
• Besoin de formaliser une idée brute en documentation structurée

Détection du scénario (CRITIQUE - Première étape)

Avant de générer tout contenu PRD, vous DEVEZ identifier le scénario.

Utilisez AskUserQuestion pour déterminer quel scénario s'applique :

Q : Veuillez sélectionner le scénario de génération PRD

Option	Description
Mise à jour itérative	Optimisation itérative basée sur les fonctionnalités existantes
Nouvelle fonctionnalité	Ajout d'un nouveau module à un produit existant
Nouveau produit de A à Z	Planification d'un tout nouveau produit à partir de zéro

Collecte de contexte par scénario

Une fois le scénario identifié, collectez le contexte requis :

Scénario	Informations requises	Méthode de collecte
Mise à jour itérative	1. Description de la fonctionnalité actuelle2. État de l'interface (capture d'écran/HTML/lien)3. Objectif de l'itération	Saisie utilisateur + AskUserQuestion pour l'option d'état UI
Nouvelle fonctionnalité	1. Architecture globale du produit2. Spécifications de conception (bibliothèque de composants/modèle d'interaction)3. Emplacement d'entrée	Lecture du répertoire docs/product/ ou saisie utilisateur
Nouveau produit de A à Z	1. Contexte du produit et utilisateurs cibles2. Contraintes de ressources3. Produits de référence	Saisie utilisateur + analyse concurrentielle

Collecte de l'état UI pour les mises à jour itératives : Lorsque l'utilisateur sélectionne « Mise à jour itérative », demandez comment il souhaite fournir l'état actuel de l'interface :

• Capture d'écran - L'utilisateur fournit une capture d'écran, utilisez mcp__zai-mcp-server__ui_to_artifact ou mcp__4_5v_mcp__analyze_image
• Fichier HTML - L'utilisateur fournit un chemin HTML local, utilisez l'outil Read pour analyser la structure DOM
• Lien en ligne - L'utilisateur fournit une URL, utilisez mcp__web_reader__webReader (aucune connexion requise)

Étape 0.5 : Analyse des lacunes d'information et plan PRD (CRITIQUE - PORTE STRICTE)

PORTE STRICTE : Ne passez PAS à la vérification des références sectorielles ou à la génération du PRD tant que cette étape n'est pas terminée et que l'utilisateur n'a pas approuvé le plan.

Protocole d'omission explicite (quand l'utilisateur refuse explicitement l'interaction) : Si l'utilisateur interdit explicitement les questions (par exemple « Arrête de demander, écris directement »), vous POUVEZ sauter les portes interactives — mais vous DEVEZ alors commencer la sortie par un bloc de déclaration d'hypothèses listant chaque hypothèse formulée (scénario, chapitres sélectionnés/exclus, produit cible, valeurs par défaut clés) afin que l'utilisateur puisse les corriger. La déclaration d'hypothèses sert également de liste de complétude pour la discipline des preuves : les informations non confirmées sont marquées 【à confirmer】, les assertions sans preuve sont marquées 【non vérifiées】(voir Discipline des preuves ci-dessous). N'inventez jamais de valeurs par défaut en silence.

Après la détection du scénario et la collecte du contexte :

1. Analyse des lacunes : Comparez les informations fournies par l'utilisateur avec les « exigences de contexte » pour ce scénario. Listez chaque champ obligatoire manquant. Vérifiez également docs/product/ pour les données de perception existantes (market-analysis.json, competitive-analysis, user-research.json, positioning.md).

2. Une question à la fois : Pour chaque élément manquant, posez une question à l'utilisateur avec AskUserQuestion en proposant des choix multiples. Ne regroupez PAS plusieurs questions en un seul message.

   Élément manquant	Exemple de question
   Capture d'écran UI	« Comment souhaitez-vous fournir l'état de l'interface actuelle ? » → A. Capture d'écran disponible B. Fichier HTML disponible C. Lien en ligne disponible D. Pas encore, passer pour l'instant
   Liste des concurrents	« Quels concurrents souhaitez-vous analyser ? » → sélection multiple + « Autre »
   Utilisateurs cibles	« Qui sont les utilisateurs cibles ? » → A. Persona déjà défini B. Je décris et vous organisez C. Besoin de faire d'abord une étude utilisateur
   Produits de référence	« Avez-vous des produits de référence ? » → A. Oui, je décris B. Vous cherchez les références du secteur C. Aucun besoin de référence

3. Gérer les éléments manquants : Si l'utilisateur dit « Je fournirai les captures d'écran plus tard » ou « Passer pour l'instant », enregistrez les éléments en attente et notez-les dans le plan PRD comme [à compléter].

4. Générer le plan PRD : Préparez (mais n'affichez pas encore) la structure du plan PRD. Le tableau ci-dessous montre le modèle avec les sélections par défaut :

   ### Chapitres PRD prévus
   | Chapitre | Résumé du contenu | Sélectionné | Statut des dépendances |
   |:---------|:------------------|:------------|:-----------------------|
   | Chapitre 0 Analyse comparative sectorielle | Analysera X produits de référence | ✅ | Terminé / [à compléter] |
   | Chapitre 1 Aperçu du projet | Développé à partir de la description utilisateur | ✅ | Terminé |
   | Chapitre 2 Analyse métier | Utilisateurs cibles X, points faibles Y | ✅ | Terminé / [à compléter] |
   | Chapitre 3 Exigences fonctionnelles | [Liste des fonctionnalités clés] | ✅ | Terminé |
   | Chapitre 4 Exigences non fonctionnelles | Exigences standard du secteur | ✅ | Généré automatiquement |
   | Chapitre 5 Parcours utilisateur | Déduit des fonctionnalités | ✅ | Nécessite des compléments UI |
   | Chapitre 6 Risques projet | Basé sur la complexité des fonctionnalités | ✅ | Généré automatiquement |
   | Chapitre 7 Recommandations de conformité | Basé sur le type de données | ❌ | Généré automatiquement |
   | Chapitre 8 Conception de prototypes | [Lien prototype] | ❌ | - |
   | Chapitre 9 Indicateurs de succès | Basé sur les objectifs | ❌ | Généré automatiquement |
   
   ### Liste d'exclusion (contenus non générés)
   - Solution technique / architecture — Le PRD est un document de spécifications produit, il n'inclut pas les détails d'implémentation technique
   - Définitions d'API / spécifications de points d'accès — Rédigées séparément par l'équipe de développement dans la solution technique
   - Conception de schéma de base de données — Hors du périmètre des spécifications produit
   

   Remarque : Le tableau ci-dessus utilise les sélections par défaut. Les valeurs réelles de la colonne « Sélectionné » seront remplies à l'étape 4.5 en fonction des réponses de l'utilisateur concernant la sélection des chapitres. Ne présentez PAS encore ce tableau à l'utilisateur.

4.5. Sélection des chapitres (PORTE STRICTE — Avant de présenter le plan PRD) :

Présentez la sélection des chapitres à l'utilisateur via AskUserQuestion avec multiSelect. En raison de la limite de 4 options, divisez en 3 questions séquentielles. Construisez les listes selected_chapters et excluded_chapters à partir des réponses, et mettez à jour la colonne « Sélectionné » du tableau du plan PRD en conséquence.

Question 1 — Chapitres principaux (Chapitres 0-3) :

Option	Par défaut	Description
Chapitre 0 Analyse comparative sectorielle	✅ Sélectionné	Recherche des produits de référence et des meilleures pratiques
Chapitre 1 Aperçu du projet	✅ Sélectionné	Contexte, objectifs et périmètre du projet
Chapitre 2 Analyse métier	✅ Sélectionné	Utilisateurs cibles, points faibles, analyse de marché
Chapitre 3 Exigences fonctionnelles	✅ Sélectionné	Liste des fonctionnalités, user stories, exigences détaillées

Question 2 — Chapitres étendus (Chapitres 4-7) :

Option	Par défaut	Description
Chapitre 4 Exigences non fonctionnelles	✅ Sélectionné	Performances, sécurité, disponibilité, compatibilité
Chapitre 5 Parcours utilisateur	✅ Sélectionné	Parcours utilisateur, diagrammes de flux de pages
Chapitre 6 Risques projet	✅ Sélectionné	Risques projet et stratégies d'atténuation
Chapitre 7 Recommandations de conformité	⬜ Non sélectionné	Recommandations de conformité et catégories de risques

Question 3 — Chapitres optionnels (Chapitres 8-9) :

Option	Par défaut	Description
Chapitre 8 Conception de prototypes	⬜ Non sélectionné	Liens de prototypes et notes de conception
Chapitre 9 Indicateurs de succès	⬜ Non sélectionné	Métriques North Star, de processus et de résultats

Exclusions permanentes (ne font pas partie de la liste de sélection, JAMAIS générées) :

• Solution technique / architecture — Le PRD n'inclut pas les détails d'implémentation technique
• Définitions d'API / spécifications de points d'accès — Rédigées séparément par l'équipe de développement
• Conception de schéma de base de données — Hors du périmètre des spécifications produit

Après avoir collecté les sélections : Mettez à jour la colonne « Sélectionné » du tableau du plan PRD pour refléter les choix de l'utilisateur (✅ pour sélectionné, ❌ pour exclu).

5. Approbation utilisateur : Utilisez AskUserQuestion pour présenter le plan PRD (avec les sélections de chapitres) et obtenir une approbation explicite :

   Option	Description
   Confirmer, générer le PRD selon ce plan	Passer à l'Étape 1 Référence sectorielle et à l'Étape 2 Génération du PRD
   Ajuster la sélection des chapitres	Re-sélectionner les chapitres à générer
   Besoin d'ajuster le plan	Modifier le plan PRD puis reconfirmer
   J'ai plus d'informations à ajouter	Revenir à l'Étape 0.5 pour ajouter des informations, puis régénérer le plan
   Ajouter d'abord des données de perception	Appeler market-research / competitive-analysis

Anti-patron : « J'ai assez d'informations, générons simplement » — interdit. Même avec peu de lacunes, présentez le plan et obtenez l'approbation.

Guide de gestion des images en environnement TUI

Dans un environnement terminal (TUI), l'utilisateur peut fournir des images des manières suivantes :

Méthode 1 : Chemin de fichier local (le plus simple)

Fournissez directement le chemin local de l'image, utilisez l'outil Read pour la lire :

# Exemple de dialogue utilisateur
« Analyse cette capture d'écran UI : /Users/fh/Desktop/screenshot.png »
« Interface actuelle : ~/Screenshots/ui-2025-03-12.png »
« Image de référence : ./docs/product/images/reference.png »

Formats de chemin pris en charge :

• Chemin absolu : /Users/fh/Desktop/screenshot.png
• Abréviation du répertoire personnel : ~/Screenshots/ui.png
• Chemin relatif : ./images/ui.png

Formats d'image pris en charge : PNG, JPG, JPEG, WebP, GIF

Méthode 2 : URL d'image en ligne

L'utilisateur télécharge l'image sur un hébergement/stockage cloud et fournit l'URL :

# Exemple de dialogue utilisateur
« Capture d'écran UI : https://i.imgur.com/xyz.png »
« Image de référence : https://s3.aws.com/bucket/screenshot.png »

Utilisez l'outil mcp__4_5v_mcp__analyze_image ou mcp__zai-mcp-server__ui_to_artifact pour lire l'image distante.

Hébergements recommandés :

• imgur.com (gratuit, aucune inscription requise)
• GitHub (comme pièce jointe à un issue)
• Stockage cloud (AWS S3, Alibaba Cloud OSS)

Méthode 3 : Commande de capture d'écran en terminal

Guidez l'utilisateur pour utiliser les outils de capture d'écran du terminal afin de générer rapidement une capture :

macOS :

# Capture d'une zone sélectionnée (interactive)
screencapture -i ~/screenshot.png

# Capture de toute la fenêtre
screencapture -w ~/screenshot.png

# Capture de tout l'écran
screencapture ~/screenshot.png

Linux :

# ImageMagick (à installer d'abord : sudo apt install imagemagick)
import ~/screenshot.png

# gnome-screenshot (Ubuntu/GNOME)
gnome-screenshot -a -f ~/screenshot.png

# spectacle (KDE)
spectacle -r -o ~/screenshot.png

Méthode 4 : Récupération directe du presse-papiers (macOS)

# Installer l'outil pngpaste
brew install pngpaste

# Enregistrer l'image du presse-papiers dans un fichier
pngpaste ~/screenshot.png

Processus de traitement

Lorsque l'utilisateur fournit une image :

1. Chemin local → Utilisez l'outil Read pour lire directement
2. URL distante → Utilisez mcp__4_5v_mcp__analyze_image ou mcp__zai-mcp-server__ui_to_artifact
3. Analyse du contenu de l'image → Extrayez la structure UI, la disposition, les éléments interactifs
4. Génération du PRD → Générez le document de spécifications basé sur les résultats de l'analyse de l'image

Vérification des références sectorielles

Après la détection du scénario, la collecte du contexte et la clarification des informations :

1. Références fournies par l'utilisateur (priorité) : Produits de référence spécifiés par l'utilisateur
2. Recherche complémentaire de l'agent : Recherche automatique des meilleures pratiques du secteur basée sur les mots-clés du scénario
3. Extraction des meilleures pratiques : 3 à 5 modèles d'interaction / conceptions de fonctionnalités de référence
4. Citation dans le PRD : Référence aux solutions de référence avec justification de l'adoption/de la différenciation

Correspondance des mots-clés de recherche :

Scénario	Mots-clés de recherche
Mise à jour itérative	« {nom de fonctionnalité} meilleures pratiques », « conception {nom de fonctionnalité} secteur »
Nouvelle fonctionnalité	« Solution {type de produit} {nom de module} », « {fonctionnalité} produits similaires »
Nouveau produit de A à Z	« Cadre produit {secteur} », « Carte produit {domaine} »

Comment ça marche

Le processus de génération garantit des PRD complets et exploitables :

1. Détection du scénario - Utilisez AskUserQuestion pour identifier itération/nouvelle fonctionnalité/nouveau produit
2. Collecte du contexte - Rassemblez les informations requises en fonction du type de scénario
3. Analyse des lacunes d'information - Identifiez les informations manquantes, posez une question à la fois
4. Sélection des chapitres - L'utilisateur sélectionne les chapitres du PRD à générer (sélection multiple)
5. Présentation du plan PRD - Présentez le plan avec les sélections de chapitres pour approbation utilisateur (PORTE STRICTE)
6. Recherche de références sectorielles - Recherchez et extrayez les meilleures pratiques (spécifiées par l'utilisateur + recherche de l'agent)
7. Analyser les exigences - Structurez la demande de fonctionnalité de l'utilisateur en composants clés
8. Rassembler le contexte - Lisez l'analyse de marché, les informations concurrentielles, les études utilisateur
9. Assembler les sections - Construisez UNIQUEMENT les sections PRD SÉLECTIONNÉES avec un niveau de détail approprié
10. Vérifier la complétude - Vérifiez par rapport aux normes de qualité (chapitres sélectionnés uniquement)
11. Auto-évaluation pré-livraison - Exécutez la vérification finale PRD (auto-vérification des chapitres + défi du point de vue des parties prenantes) ; corrigez les blocages ou marquez 【à confirmer】
12. Générer la sortie - Écrivez dans docs/product/prd/{feature-name}-{date}-v{version}.md (incluez une section « Enregistrement de la vérification finale » en fin de document)

Contraintes de contenu (RÈGLES STRICTES) :

Avant de générer le contenu PRD, notez :

1. Générez UNIQUEMENT les chapitres sélectionnés par l'utilisateur. Sautez complètement les chapitres non sélectionnés.
2. Ne JAMAIS générer les types de contenu suivants, quelle que soit la saisie de l'utilisateur :
   • Architecture technique / détails d'implémentation
   • Définitions de points d'accès API ou spécifications
   • Schémas de base de données ou conceptions de tables
3. Si la description de la fonctionnalité de l'utilisateur mentionne des détails techniques, résumez-les comme des exigences fonctionnelles SANS exposer les spécificités d'implémentation.

Paramètres d'entrée

Paramètre	Type	Requis	Description
requirements	chaîne	Oui	Description de la fonctionnalité ou user story à documenter
target_audience	chaîne	Non	Segment d'utilisateurs ou persona cible
context_refs	liste	Non	Fichiers de contexte connexes à référencer

Discipline des preuves

1. Marquage des informations manquantes 【à confirmer】 : Toute information qui ne peut être obtenue à partir de l'entrée ou du contexte est marquée 【à confirmer】. N'inventez jamais de valeurs par défaut.
2. Traçabilité des preuves 【non vérifié】 : Les affirmations des utilisateurs / affirmations de marché doivent être suivies de questions sur la source des preuves ; celles sans preuve sont marquées 【non vérifié】 avec mention de la méthode de vérification requise.
3. Porte de vérification de complétude : Avant de générer la livraison officielle, produisez d'abord une liste de complétude des informations (Confirmé ✅ / À confirmer ⚠️ / Non vérifié ❓). Ne générez le contenu principal qu'après confirmation par l'utilisateur.

Relation avec le Protocole d'omission explicite (Étape 0.5) : La discipline des preuves est une discipline de sortie (marquage des informations et auto-vérification avant livraison), tandis que l'omission explicite est une discipline d'interaction (traitement dégradé lorsque l'utilisateur refuse explicitement l'interaction). Les deux sont complémentaires et non conflictuelles. Dans le scénario d'omission explicite, la liste de complétude n'est pas supprimée — elle est fusionnée avec la « déclaration d'hypothèses », mais sans attendre la confirmation de l'utilisateur ; les informations non confirmées dans la déclaration d'hypothèses sont également marquées 【à confirmer】/【non vérifié】 conformément aux règles de cette section.

Structure de sortie

Le PRD suit cette structure (alignée sur le modèle de PRD standard). IMPORTANT : Ce modèle montre tous les chapitres possibles. Générez UNIQUEMENT les chapitres sélectionnés par l'utilisateur. Sautez complètement les chapitres non sélectionnés. Ne générez en aucun cas l'architecture technique, les spécifications API ou les conceptions de base de données.

# [Nom de la fonctionnalité] PRD

## Informations de base du document
- **Version du document** : v1.0
- **Date de création** : AAAA-MM-JJ
- **Dernière mise à jour** : AAAA-MM-JJ
- **Statut du document** : Brouillon/Relecture/Approuvé
- **Créateur** : [Nom d'utilisateur]
- **Relecteur** : [À déterminer]

## Historique des révisions
| Version | Date | Contenu de la révision | Réviseur |
|:--------|:-----|:----------------------|:---------|
| v1.0 | AAAA-MM-JJ | Version initiale | [Créateur] |

## 0. Analyse comparative sectorielle
### 0.1 Produits de référence
| Produit | Fonctionnalité clé | Adoption / Différenciation |
|:--------|:-------------------|:--------------------------|
| [Concurrent A] | XXX | Adoption de son modèle XXX, car... |
| [Concurrent B] | XXX | Point de différenciation : ... |

### 0.2 Résumé des meilleures pratiques
- **Modèle d'interaction** : [Modèle d'interaction standard du secteur adopté]
- **Différenciation clé** : [Particularité de cette solution]

## 1. Aperçu du projet
### 1.1 Contexte du projet
[Contexte du marché, contexte concurrentiel, contexte des besoins utilisateur]

### 1.2 Objectifs du projet
#### 1.2.1 Objectif principal
- [Objectif principal quantifiable]

#### 1.2.2 Objectifs secondaires
- [Objectifs de soutien]

### 1.3 Périmètre du projet
#### 1.3.1 Périmètre inclus
- [Contenu inclus dans cette itération/fonctionnalité]

#### 1.3.2 Périmètre exclu
- [Éléments explicitement hors du périmètre cette fois-ci]

## 2. Analyse métier
### 2.1 Utilisateurs cibles
| Rôle utilisateur | Description | Besoin principal |
|:-----------------|:------------|:-----------------|
| Utilisateur A | [Issu de l'étude utilisateur] | XXX |
| Utilisateur B | [Issu de l'étude utilisateur] | XXX |

### 2.2 Points faibles des utilisateurs
| ID Point faible | Description du point faible | Degré d'impact |
|:----------------|:---------------------------|:---------------|
| P-001 | XXX | Élevé/Moyen/Faible |
| P-002 | XXX | Élevé/Moyen/Faible |

### 2.3 Analyse de marché
[Tendances du secteur, paysage concurrentiel, opportunités de marché]

## 3. Exigences fonctionnelles
### 3.1 Liste des fonctionnalités principales
| ID Fonctionnalité | Nom de la fonctionnalité | Priorité | Description |
|:------------------|:-------------------------|:---------|:------------|
| F-001 | XXX | P0/P1/P2 | XXX |
| F-002 | XXX | P0/P1/P2 | XXX |

### 3.2 User Stories
#### US-1 : [Nom de la fonctionnalité]
**En tant que** [Rôle utilisateur]
**Je souhaite** [Description de la fonctionnalité]
**Afin de** [Valeur métier]

**Critères d'acceptation** :
- Given [Condition préalable]
- When [Action exécutée]
- Then [Résultat attendu]

**Priorité** : P0/P1/P2
**Estimation** : X Story Points

#### US-2 : [Nom de la fonctionnalité]
...

### 3.3 Détails des fonctionnalités
#### F-001 : [Nom de la fonctionnalité]
**Description** : [Description détaillée de la fonctionnalité]

**Flux d'interaction** :
1. Étape une
2. Étape deux
3. Étape trois

**Cas limites** :
- Flux normal : ...
- Cas exceptionnel : ...

## 4. Exigences non fonctionnelles
### 4.1 Exigences de performance
- Temps de réponse de la page < XXXms
- Prise en charge de XXX utilisateurs simultanés
### 4.2 Exigences de sécurité
- Stockage crypté des données
- Contrôle d'accès utilisateur
### 4.3 Exigences de disponibilité
- Disponibilité du système > 99,9 %
### 4.4 Exigences de compatibilité
- iOS 14+, Android 10+
- Compatibilité avec les navigateurs principaux

## 5. Parcours utilisateur
### 5.1 Parcours utilisateur
[Description du chemin utilisateur clé]
1. L'utilisateur entre → 2. Effectue une action → 3. Atteint l'objectif

### 5.2 Diagramme de flux de pages
[Description des relations de navigation entre pages]
- Page A → Page B → Page C

## 6. Risques projet et mesures d'atténuation
> Remarque : Cette section ne contient que les risques produit/métier, pas les risques d'implémentation technique (les risques techniques sont évalués par l'équipe de développement dans la solution technique).
| ID Risque | Description du risque | Probabilité | Impact | Mesure d'atténuation |
|:----------|:---------------------|:------------|:-------|:---------------------|
| R-001 | XXX | Élevée/Moyenne/Faible | Élevé/Moyen/Faible | XXX |
| R-002 | XXX | Élevée/Moyenne/Faible | Élevé/Moyen/Faible | XXX |

## 7. Recommandations de conformité

### 7.1 Résumé des points de conformité
[Résumé des points clés de l'analyse des experts en conformité]

### 7.2 Avertissements sur les risques
| Catégorie de risque | Description | Recommandation |
|:--------------------|:------------|:---------------|
| Conformité à la vie privée | [Traitement des données utilisateur impliquées] | [Recommandation de conformité] |
| Conformité du contenu | [Points de modération du contenu impliqués] | [Recommandation de conformité] |
| Sécurité des données | [Exigences de stockage et de transmission des données] | [Recommandation de conformité] |
| Conformité tierce | [Conformité des services tiers dépendants] | [Recommandation de conformité] |

### 7.3 Annexes du rapport de conformité
- [ ] Rapport d'analyse de conformité joint (si disponible, fournir le chemin)
- [ ] En attente d'examen de conformité (si nécessaire, planifier une évaluation par un expert en conformité)

...

[écourté pour la traduction]