linsaber1012-coder/pm-prd-to-demo

PM · PRD → Démo – Workflow intégré

Parcourez la chaîne complète depuis « une idée produit » jusqu’à « alignement → document → prototype cliquable », en produisant un PRD livrable pour le développement, une définition autonome des indicateurs, et un prototype partageable qui réutilise l’interface réelle d’un dépôt de base. Ce workflow est indépendant de l’hôte (Claude Code / Codex / Cursor / Gemini) ; les instructions de portabilité se trouvent dans la section « Adaptation à l’hôte ».

Quand l’utiliser

• L’utilisateur joue le rôle du chef de produit et doit produire des livrables comme un PRD, des définitions d’indicateurs ou une maquette interactive.
• Il s’agit généralement d’améliorer un dépôt ou système existant en réutilisant sa structure réelle.
• On souhaite en même temps obtenir un prototype préliminaire, cliquable et partageable pour faciliter la revue.

Ne convient pas : tâches de pure implémentation de code, modification d’une ou deux lignes seulement, travail sans composante décisionnelle produit.

Ce que vous produirez

1. PRD.md — la source unique de vérité (quoi faire, pour qui, périmètre, risques, description détaillée des pages et de l’interaction).
2. Définition des indicateurs.md — un document de spécification totalement autonome que les développeurs peuvent implémenter sans autre référence.
3. Prototype HTML partageable et autonome — à gauche l’interface cible (réutilisant l’UI réelle du dépôt de base + vos modifications, les données factices doivent être explicitement marquées), à droite le panneau complet du PRD.

---

Disciplines à respecter impérativement (non négociables)

1. Zéro fabrication, tout doit reposer sur des preuves : les spécifications s’ancrent dans le code source, la documentation officielle ou la confirmation de l’utilisateur ; si on ne trouve pas, on le dit clairement, on n’invente pas ; les données factices doivent être explicitement marquées.
2. Zéro emoji : aucun emoji / icône d’état dans la documentation ni le prototype ; les états sont toujours des libellés textuels (conservé / mis à niveau / ajouté / non testé / à vérifier, etc.).
3. Rédaction → révision contradictoire en boucle : tout document livrable est d’abord rédigé, puis révisé du point de vue d’un « PM senior exigeant » selon les instructions du prompts/reviewer-agent.md, puis corrigé jusqu’à validation.
4. Cohérence entre les livrables : PRD ↔ définition des indicateurs ↔ prototype doivent être cohérents ; tout élément orphelin ou contradiction est corrigé sur place.
5. Adapter le style d’interaction à l’utilisateur : certains préfèrent la conversation, d’autres les choix ; si une approche est rejetée une fois, changer de méthode, ne pas insister.
6. Ne pas avancer tant que les décisions ne sont pas verrouillées : avant de rédiger, clarifier les décisions clés ; si l’objectif n’est pas clair, s’arrêter et discuter, ne pas deviner.
7. Style d’écriture naturel (sans effet IA) : le texte du document doit être direct, naturel, comme écrit par un humain, en évitant activement les traces typiques du style IA (abus de tirets, « non seulement X, mais aussi Y », parallélismes creux / phrases à trois temps, hésitations excessives, ornements pompeux, vérités générales inutiles). On peut charger le skill local humanizer ou se référer à references/writing-style.md (compilation stop-slop / Humanizer-zh / blader-humanizer). Attention : la précision technique doit rester exacte — enlever l’effet IA ne signifie pas sacrifier l’exactitude ni ajouter du remplissage.

---

Phase 0 · Découverte interactive et verrouillage des décisions

Objectif : enquêter et clarifier la véritable intention, les besoins et les contraintes de l’utilisateur, puis verrouiller les décisions clés — c’est une interaction entre l’IA et l’humain, l’IA ne décide pas à la place de l’utilisateur.

1. Explorer les actifs existants : lire la structure réelle du dépôt / document / ancien système fourni par l’utilisateur (si l’hôte permet l’exploration parallèle, le faire ; sinon lire un par un). Comprendre ce qu’il fait réellement et ce qui peut être réutilisé.
2. Dégager les besoins par interaction : utiliser des questions pour aider l’utilisateur à transformer une idée floue en décisions claires — les décisions typiques à verrouiller : quel dépôt de base choisir, périmètre inclus/exclu, quels indicateurs/fonctionnalités, architecture d’affichage/information, non-objectifs explicites. Poser quelques questions clés à la fois, ne pas bombarder.
3. Produire un enregistrement des décisions : rédiger un court fichier « décisions / planification » qui servira d’entrée pour la phase 1.

Critère de sortie : chaque décision clé a une réponse claire, approuvée par l’utilisateur.

Phase 1 · Production du PRD + définition des indicateurs

Objectif : produire les deux documents livrables pour le développement.

1. Se référer au modèle : consulter references/prd-checklist.md (liste complète adaptée au contexte chinois, avec ajustement selon le type de projet) pour déterminer les sections à produire et celles à ignorer.
2. Rédiger : suivre prompts/writer-agent.md pour rédiger le PRD et la définition des indicateurs. Points clés :
   • Le PRD couvre : contexte / objectifs / métriques de succès / périmètre / risques / structure fonctionnelle + architecture de l’information + schémas (Mermaid possible) / description détaillée de l’affichage et de l’interaction de chaque page (niveau champ) / glossaire / règles globales / parties prenantes.
   • La définition des indicateurs est totalement autonome : inclure toutes les spécifications en ligne, sans renvoi à d’autres documents ; un développeur peut l’implémenter en ne lisant que ce document.
3. Réviser : utiliser le persona « PM senior » de prompts/reviewer-agent.md pour une révision contradictoire (exhaustivité, exécutabilité, cohérence avec le code source, périmètre et non-objectifs, risques, zéro emoji, absence de liens morts, cohérence entre documents).
4. Boucle de correction : corriger selon les points obligatoires de la révision, revérifier jusqu’à validation.
5. Passer la checklist : avant livraison, parcourir references/pitfalls.md point par point (checklist des problèmes rencontrés lors des itérations précédentes).

Phase 2 · Production du prototype partageable

Objectif : un prototype cliquable avec à gauche l’interface cible, à droite le PRD complet ; la conception de l’interface est fidèle à la source définie (maquette de référence / dépôt de base / concurrent, voir ci-dessous). Règles impératives dans references/prototype-guardrails.md.

1. Déterminer la source de conception (par ordre de priorité) :
   • ① L’utilisateur a fourni un prototype de référence / une maquette → la prendre comme référence, reproduire fidèlement son aspect visuel et sa disposition.
   • ② On améliore un dépôt de base existant → cloner/lire son front-end, extraire les tokens de design réels et la disposition (couleurs / clair-sombre / barre latérale ou barre supérieure / cartes / champs réels des vues et colonnes des tableaux), reproduire sans improvisation.
   • ③ Ni l’un ni l’autre → l’IA construit par elle-même, en choisissant comme référence une page de produit similaire / concurrent pour créer le prototype, et en précisant dans le prototype la source de référence et la raison.
2. Créer un fichier HTML autonome : un seul fichier, à gauche = interface cible (fidélité au dépôt de base + vos modifications, les données factices doivent être marquées), à droite = panneau complet du PRD (intégrer le PRD via un rendu markdown minimaliste).
3. Autonome / Sécurité CSP : tout le CSS/JS est intégré en ligne, sans appel à des CDN / polices / icônes externes ; les éléments impossibles à rendre en direct (ex. certaines bibliothèques d’images) doivent être honnêtement signalés comme limités et dégradés en un affichage lisible.
4. Publier et itérer : publier sous forme de lien partageable ; lorsque l’utilisateur demande des modifications, modifier à la fois le prototype et le PRD en maintenant la cohérence, puis republier sur le même lien.

---

Checklist avant livraison (résumé, voir references/pitfalls.md pour le détail)

• Zéro emoji (y compris dans les étiquettes de nœuds des diagrammes / blocs de code)
• Aucune fabrication : tous les chiffres / spécifications sont traçables ; les données factices sont marquées
• La définition des indicateurs est autonome, pas de renvoi à d’autres documents
• Cohérence entre les livrables, pas d’élément orphelin ni de contradiction
• La conception du prototype est fidèle à la source définie (maquette de référence → reproduire ; dépôt de base → copier les tokens ; rien → se référer à un concurrent et le justifier), pas d’improvisation
• Les scores composites / totaux sont accompagnés de leur formule explicite et de leur composition
• Tout ce qui ne peut pas être rendu / n’est pas testé / est inconnu est honnêtement signalé, pas présenté comme un fait

---

Adaptation à l’hôte (portabilité)

Ce SKILL.md contient des instructions en langage naturel indépendantes de l’hôte, que tout LLM peut suivre. Les trois différences sont résolues en dehors du corps du document :

• Chargement / déclenchement : l’installation et l’appel sur chaque hôte sont décrits dans README.md (Claude Code → placer dans le répertoire des skills ; Codex → via son mécanisme skill/AGENTS.md ; Cursor/Gemini → selon leur propre chemin).
• Dégradation des capacités : partout où il est question de « lancer un sous-agent de révision/exploration », si l’hôte actuel ne supporte pas les sous-agents, vous devez refaire vous-même la même révision/exploration, sans changer les disciplines.
• Indépendance des outils : le corps du document ne décrit que des actions (chercher sur le web, lire un dépôt, écrire un fichier, publier un prototype) sans lier à un outil spécifique ; chaque hôte mappe ses propres outils.

Ressources jointes

• references/prd-checklist.md — liste des composants du PRD + ajustement selon le type de projet
• references/prototype-guardrails.md — règles impératives du prototype
• references/pitfalls.md — checklist des pièges issus de l’expérience
• references/writing-style.md — règles d’écriture naturelle sans effet IA (compilation stop-slop / Humanizer-zh / blader-humanizer + skill local humanizer)
• prompts/writer-agent.md — modèle de prompt pour l’agent rédacteur
• prompts/reviewer-agent.md — persona du PM senior + points de vérification pour l’agent de révision contradictoire
• templates/prd-skeleton.md / templates/metric-spec-skeleton.md — squelettes de modèles