tieveto666-code/product-prototype-builder

Constructeur de prototype produit

Utilisez cette compétence pour faire passer une idée produit floue de 0 à 1 en trois livrables :

1. Discussion sur les besoins
2. Spécification des besoins (PRD)
3. Prototype HTML interactif mono-fichier

L'utilisateur peut fournir uniquement une idée initiale. Ne passez pas directement à la génération du PRD ou du prototype sans avoir suffisamment d'informations validées par l'utilisateur à l'étape précédente.

Règles fondamentales

• Lorsque l'utilisateur utilise le chinois, communiquez et livrez par défaut en chinois.
• Considérez ce processus comme une exploration produit collaborative, pas une génération de documents unique.
• Documentez en continu les besoins, décisions, questions ouvertes, hypothèses et changements de version.
• Les décisions produit importantes doivent d'abord être confirmées avec l'utilisateur avant d'être intégrées au document final.
• Ne générez pas de PRD avant que l'utilisateur ait clairement confirmé que la discussion sur les besoins est suffisamment complète.
• Ne générez pas de prototype avant que l'utilisateur ait clairement confirmé que le PRD est correct et que la génération du prototype peut commencer.
• Si l'utilisateur modifie les besoins après la génération du PRD ou du prototype, mettez d'abord à jour le document de discussion, puis créez une nouvelle version du PRD ou du prototype en fonction de l'impact.
• Lorsque des informations sur le marché, la concurrence, la réglementation, la technologie, les prix ou l'état du secteur peuvent influencer le jugement sur les besoins, utilisez les outils de recherche en ligne disponibles pour rassembler des données supplémentaires, et résumez les sources et les conclusions. Les sources externes ne sont que des hypothèses ; elles doivent être confirmées par l'utilisateur pour devenir des exigences.

Structure de l'espace de travail

Créez et maintenez la structure suivante dans le répertoire de travail actuel :

workspace/
├── 01-discussions/
│   └── {nom-du-besoin}-discussion.md
├── 02-specifications/
│   └── {nom-du-besoin}/
│       ├── v001-{nom-du-besoin}-spec.md
│       ├── v002-{nom-du-besoin}-spec.md
│       └── index.md
└── 03-prototypes/
    └── {nom-du-besoin}/
        ├── v001-{nom-du-prototyoe}.html
        ├── v002-{nom-du-prototyoe}.html
        └── index.md

Si le projet contient déjà un répertoire racine approprié, utilisez-le et ne recréez pas inutilement workspace/. Les noms de fichiers doivent être concis, clairs et éviter les caractères spéciaux incompatibles avec les systèmes de fichiers.

Règles de gestion de version

• Le PRD et le prototype doivent utiliser des numéros de version tels que v001, v002, v003, etc.
• N'écrasez pas les fichiers de PRD ou de prototype déjà versionnés. Créez la version suivante pour chaque modification importante.
• Chaque index.md doit enregistrer :
  • le numéro de version
  • le chemin du fichier
  • la date de création ou de mise à jour, si disponible
  • une brève description du changement
  • le statut (par ex. draft, confirmed, superseded)
• Le fichier de discussion sur les besoins est la source de vérité évolutive ; il doit être mis à jour tout au long du processus.

Étape 1 : Discussion sur les besoins

Objectif : Transformer l'idée initiale de l'utilisateur en une base de besoins claire, complète et validée.

Actions :

1. Créez ou mettez à jour workspace/01-discussions/{nom-du-besoin}-discussion.md.
2. Posez des questions ciblées sous forme de dialogue libre. À chaque série, privilégiez 3 à 7 questions à forte valeur ajoutée.
3. Documentez les éléments suivants :
   • l'idée originale
   • les utilisateurs cibles et les cas d'usage
   • les points douloureux et la valeur du produit
   • le flux d'utilisation principal
   • les besoins fonctionnels
   • les objets de données et les champs clés
   • les rôles utilisateur et les autorisations
   • les règles métier
   • les attentes en matière d'interaction
   • les préférences visuelles et de style
   • les contraintes et le périmètre hors cible
   • les questions en suspens
   • les décisions confirmées
4. Si vous découvrez des exigences irréalistes, risquées, contradictoires ou manquantes, signalez le problème, expliquez son impact et proposez des alternatives.
5. Si nécessaire, effectuez des recherches sur les produits similaires, les pratiques du secteur, les contraintes réglementaires ou la faisabilité technique. Résumez les résultats de la recherche et demandez à l'utilisateur s'il souhaite adopter les hypothèses correspondantes.
6. Résumez régulièrement les besoins actuels au cours de la discussion et mettez à jour le fichier de discussion en conséquence.

Porte d'étape :

• Avant de passer à l'étape 2, vous devez demander à l'utilisateur de confirmer que les besoins sont suffisamment complets pour générer le PRD.
• Les confirmations acceptables incluent des expressions synonymes telles que "Vous pouvez générer le PRD", "Les besoins sont corrects", "Générez le document de spécification", etc.
• Si l'utilisateur demande prématurément à générer le PRD, résumez d'abord les lacunes actuelles, puis ne posez que les questions les plus nécessaires.

Étape 2 : Spécification des besoins

Objectif : Générer un document PRD Markdown complet et structuré.

Créez la version suivante dans le chemin :

workspace/02-specifications/{nom-du-besoin}/v00N-{nom-du-besoin}-spec.md

Structure PRD recommandée :

# Document de spécification produit {nom-du-besoin} v00N

## 1. Objectifs du besoin
## 2. Contexte et points douloureux utilisateur
## 3. Rôles utilisateur et scénarios clés
## 4. Périmètre du besoin
## 5. Périmètre hors cible
## 6. Architecture produit
## 7. Flux d'utilisation
## 8. Style produit et disposition fonctionnelle
## 9. Détails fonctionnels et logique d'interaction
## 10. Objets de données et champs
## 11. Statuts, règles et gestion des exceptions
## 12. Liste des pages du prototype
## 13. Critères d'acceptation
## 14. Questions en suspens
## 15. Historique des versions

Exigences de qualité du PRD :

• Le contenu doit être suffisamment spécifique pour supporter la génération du prototype.
• Ne vous contentez pas d'énumérer les noms de fonctionnalités ; décrivez le comportement au niveau de la page et des composants.
• Décrivez si nécessaire les états vides, les états de chargement, les états d'erreur, les états d'autorisation et les cas limites importants.
• La structure produit doit être esthétique, facile à utiliser et logique d'un point de vue fonctionnel.
• Toutes les hypothèses doivent être clairement marquées, en précisant si elles sont confirmées ou en suspens.

Après livraison :

• Mettez à jour le index.md dans la zone de spécification.
• Demandez à l'utilisateur s'il souhaite modifier le PRD.
• Si l'utilisateur demande des modifications, mettez d'abord à jour le fichier de discussion, puis créez une nouvelle version du PRD.

Porte d'étape :

• Ne passez pas à l'étape 3 avant que l'utilisateur ait clairement confirmé que le PRD est correct et que la génération du prototype peut commencer.
• Les confirmations acceptables incluent des expressions synonymes telles que "Le PRD est correct", "Vous pouvez générer le prototype", "Commencez le HTML", etc.

Étape 3 : Prototype HTML interactif

Objectif : Générer un prototype HTML mono-fichier esthétique, unifié, utilisable et immersif.

En entrant dans cette étape, vous devez lire et exécuter les spécifications de qualité du prototype dans references/prototype-quality.md.

Avant de générer le fichier :

• Informez brièvement l'utilisateur de l'effet attendu du prototype, y compris les pages principales, la profondeur d'interaction, le style visuel et la logique de simulation.
• Ne mentionnez les limitations clés que si nécessaire.
• Générez une "liste d'interactions du prototype" précisant le comportement interactif de chaque page, navigation, bouton, onglet, filtre, recherche, formulaire, fenêtre modale, tiroir, opérations CRUD et composants dynamiques.
• Pour les composants complexes tels que l'orchestration de flux de travail, les diagrammes visuels, les organigrammes, les tableaux Kanban, le glisser-déposer, les relations de nœuds, etc., vous devez préciser quelles interactions dynamiques seront implémentées ; ne vous contentez pas d'un affichage statique.

Créez la version suivante dans le chemin :

workspace/03-prototypes/{nom-du-besoin}/v00N-{nom-du-prototyoe}.html

Exigences du prototype :

• Livrez un fichier .html autonome.
• Par défaut, tout le HTML, CSS et JavaScript sont intégrés dans le même fichier.
• Le fichier doit pouvoir être ouvert directement dans un navigateur moderne.
• Le prototype doit être un prototype fonctionnel interactif, pas une capture d'écran statique.
• Implémentez des états d'interface utilisateur réalistes, des transitions de page, des formulaires, des fenêtres modales, des tiroirs, des onglets, des filtres, des recherches, des validations, des flux simulés et de la logique métier en fonction des besoins.
• Tous les éléments cliquables doivent avoir un résultat interactif perceptible. Les boutons, menus, onglets, icônes cliquables ou points d'entrée d'action qui semblent cliquables mais ne réagissent pas ne sont pas acceptables.
• Les boutons CRUD doivent avoir une logique simulée, par exemple ajouter des données, modifier des valeurs préremplies, confirmer la suppression, afficher les détails, filtrer la recherche, mettre à jour le statut ou émettre un retour d'information.
• La mise en page doit être vérifiée pour l'espacement : évitez que la barre latérale ne touche la zone de contenu, que les boutons ne soient trop serrés, que le texte ne dépasse, que les éléments ne se chevauchent ou que le contenu ne soit masqué.
• Utilisez des données simulées et un état côté navigateur. Pour améliorer l'expérience, vous pouvez utiliser localStorage pour conserver des données temporaires.
• Par défaut, ne dépendez pas d'un backend, d'une base de données réelle, d'étapes de construction, d'installation de paquets ou d'API externes.
• Ne dépendez pas de CDN externes, sauf si l'utilisateur l'accepte explicitement.
• Le système visuel global doit être unifié, y compris l'espacement, les polices, les couleurs, les styles de composants, les boutons, les tableaux, les cartes, les formulaires, les graphiques, la navigation et les états de retour.
• Tous les flux principaux doivent pouvoir être démontrés avec des exemples de données.
• La profondeur d'interaction doit être suffisante pour que l'utilisateur puisse expérimenter le comportement principal du produit.

Remarques importantes :

• "Prototype HTML mono-fichier" ne signifie pas "sans interaction".
• Cela signifie que le prototype peut fonctionner localement dans le navigateur et implémenter des interactions et une logique métier via une simulation côté client.
• Si l'utilisateur demande une vraie connexion, de vraies API, une persistance de base de données, des paiements, un stockage de fichiers ou un déploiement en production, expliquez que cela dépasse le cadre du prototype mono-fichier et demandez s'il souhaite simuler ces aspects dans le prototype ou passer à un plan d'implémentation technique.

Exigences de validation :

• Vérifiez que le HTML généré ne contient pas de références invalides.
• Si un navigateur ou un outil de rendu est disponible, ouvrez le HTML et vérifiez la mise en page, le comportement responsive et les interactions principales.
• Avant la livraison, corrigez les problèmes évidents de chevauchement de mise en page, de rupture de flux, d'absence d'état ou d'erreurs JavaScript.
• Utilisez la liste de contrôle de pré-livraison dans references/prototype-quality.md et auto-vérifiez chaque élément. Si quelque chose n'est pas implémenté, non réactif ou mal positionné, corrigez-le d'abord avant de livrer.

Après livraison :

• Mettez à jour le index.md dans la zone du prototype.
• Informez l'utilisateur du chemin du fichier et du numéro de version créé.
• Résumez d'abord le contenu du prototype, puis demandez un retour.

Style de dialogue

• Restez proactif, mais respectez strictement les portes d'étape.
• Ne posez des questions que si elles améliorent significativement le résultat.
• Lorsque l'utilisateur est incertain, proposez 2 à 4 options concrètes avec une recommandation.
• Lorsque l'utilisateur demande d'aller vite, vous pouvez créer une première version basée sur des hypothèses raisonnables, mais obtenez toujours une confirmation avant de franchir une étape.
• Lorsque l'utilisateur demande des modifications, déterminez si elles affectent la discussion sur les besoins, le PRD, le prototype, ou les trois.
• Lorsque l'utilisateur demande un retour en arrière, utilisez le index.md correspondant et les fichiers versionnés pour localiser la version cible.

Note de portabilité

Cette compétence est rédigée sous forme d'instructions de workflow Markwell génériques. Lors de la migration vers un outil autre que Codex, vous pouvez utiliser references/portable-prompt.md comme prompt système, instructions personnalisées, règle de projet ou règle d'agent.