GanDaicheng/vibecoding-workflow

Vibe Coding Workflow

Aidez les débutants en programmation à faire passer un petit projet Web de l'idée à un résultat vérifiable. Discutez des décisions produit dans un langage compréhensible par l'utilisateur ; adaptez le processus en fonction de la taille de la tâche. Ce skill est une méthode de travail, il ne présuppose pas de framework, de base de données ou de plateforme de déploiement.

La première version se concentre sur une simple page de démonstration publique. La connexion, l'administration, l'upload de fichiers, le paiement et le traitement de données sensibles dépassent ce cadre simplifié ; lorsque ces besoins apparaissent, indiquez d'abord les nouvelles décisions produit, données, autorisations et déploiement nécessaires, puis planifiez en fonction de la portée étendue validée par l'utilisateur, sans les inclure silencieusement dans la roadmap initiale.

Entrée : d'abord trier, puis déterminer la destination et l'état actuel

1. À partir des propos de l'utilisateur, extrayez l'objectif, les contraintes et les autorisations, et déterminez s'il s'agit d'une petite modification claire, d'un nouveau projet ou d'une fonctionnalité en plusieurs étapes dans un projet existant. Les petites modifications suivent le chemin rapide ; les nouveaux projets et les fonctionnalités en plusieurs étapes suivent le chemin complet.
2. Si le chemin complet n'a pas encore précisé la destination de livraison, demandez à l'utilisateur ce qu'il souhaite : simplement clarifier la solution, rendre le projet exécutable localement, préparer le déploiement, ou publier officiellement. Pour les petites modifications, ne demandez que si la méthode de livraison affecte la tâche. Le travail ultérieur ne progresse que jusqu'au niveau choisi ou clairement autorisé par l'utilisateur.
3. Pour un projet existant, lisez d'abord le README du dépôt, le fichier AGENTS.md (s'il existe), le code pertinent, les méthodes d'exécution et de vérification, les documents de planification existants et l'état Git. Identifiez les modifications non soumises par l'utilisateur, ne les écrasez pas et ne les mélangez pas avec vos propres commits. Pour un répertoire vide, confirmez d'abord le produit à réaliser et les ressources existantes.
4. Présentez un résumé court listant les faits connus, les décisions produit en attente et les suggestions actuelles. Donnez la priorité à une seule question par tour qui impacte le plus l'étape suivante ; ne combinez les questions que lorsque plusieurs décisions sont étroitement liées et que l'utilisateur souhaite y répondre en bloc. Les détails à faible impact peuvent être présentés comme des hypothèses clairement marquées.

Chemin complet : d'abord définir le produit, puis choisir la méthode de mise en œuvre

1. Définir le produit de première version

• Clarifiez les utilisateurs cibles, le problème à résoudre, les critères de succès de la première version et les contraintes. Organisez les principales user stories par rôle, sélectionnez le chemin critique P0, et enregistrez les P1/P2 et ce qui n'est pas encore fait. Évitez d'ajouter toutes les fonctionnalités suggérées par l'IA dans la première version.
• À partir des stories, déduisez les pages, la navigation, les opérations principales et les états vides, de chargement, de succès et d'échec nécessaires. Permettez à l'utilisateur de décrire les étapes du scénario réel, de l'entrée sur le site à la réalisation de l'objectif.
• Transformez les objectifs vagues comme "convivial" ou "complet" en comportements observables. Si des histoires ou des priorités entrent en conflit, signalez d'abord le conflit.
• Conservez une correspondance concise : chaque histoire P0 est liée à une page ou un comportement, une tranche de développement et une méthode de vérification. Avant la fin de la planification, vérifiez qu'aucune histoire P0 n'est laissée sans tranche, afin d'éviter de documenter sans implémenter les fonctionnalités principales.

2. Proposer des recommandations techniques, de données et de déploiement

• Pour un projet existant, privilégiez les technologies et conventions existantes raisonnables. Pour un nouveau projet, vérifiez d'abord ce que l'utilisateur connaît ; s'il n'a pas de préférence, recommandez une combinaison qui répond aux besoins de la première version, facile à développer, déployer et maintenir. Expliquez les raisons de la recommandation et les principaux compromis ; ne présentez des alternatives que si l'utilisateur demande une comparaison.
• Demandez d'abord quelles données doivent être sauvegardées, mises à jour, partagées ou lues sur plusieurs appareils, avant de juger si une base de données est nécessaire. Si un contenu statique répond aux besoins de la première version, indiquez clairement qu'aucune base de données n'est nécessaire. Si une persistance est vraiment nécessaire, décrivez les entités de données, les relations, le chemin de lecture/écriture, l'impact d'une perte de données et la méthode de migration ; n'ajoutez pas de backend ou de système de comptes sans raison.
• En fonction de la destination de livraison, anticipez l'environnement d'exécution, l'emplacement des données, les variables d'environnement, les coûts, le nom de domaine, la méthode de build et le rollback. Pour les aspects liés à la version actuelle, la compatibilité, les capacités de la plateforme ou les prix, vérifiez les sources officielles et indiquez les sources et les incertitudes.
• Demandez à l'utilisateur de confirmer les décisions qui modifient le coût, les données, l'architecture ou la maintenance future. Ne demandez pas à un débutant de deviner le nom du framework, la base de données ou les champs de table.

3. Commencer après confirmation de la feuille de route

• Divisez le travail en tranches de bout en bout dont l'utilisateur peut voir les résultats ; chaque tranche doit être clairement définie avec son objectif, son périmètre, ses dépendances, son comportement de vérification et sa méthode de validation. La première tranche doit donner la priorité à la mise en œuvre du chemin le plus important.
• Avant de commencer à modifier des fichiers pour un nouveau projet, présentez le périmètre produit, les principales décisions techniques et la première tranche. Si l'utilisateur n'a pas encore confirmé ces décisions, demandez confirmation ; si l'utilisateur a clairement confirmé et autorisé le début des travaux, continuez directement sans demander à nouveau. Les détails de mise en œuvre courants sont gérés par Codex ; ne réalignez que si le périmètre, l'architecture ou les décisions à fort impact changent.
• Si l'utilisateur ne souhaite qu'une solution, arrêtez-vous à la solution ou au document de planification demandé. Ne transformez pas automatiquement une demande de planification en codage ou publication.

Chemin rapide : petites modifications claires

Examinez le code pertinent et l'état de l'espace de travail, décrivez en une phrase le comportement attendu et la méthode de vérification, effectuez les modifications limitées et validez. Si l'utilisateur ne demande que des étapes ou une solution, expliquez également comment les modifications réelles seront vérifiées et distinguez les vérifications planifiées de celles déjà exécutées. Ne passez au chemin complet que si la demande implique plusieurs modules, structures de données, architecture ou méthode de publication. Il n'est pas nécessaire de créer de nouveaux documents produit ou frameworks de test pour de petites modifications.

Cycle de chaque tranche de développement

1. Avant de commencer, relisez la tranche actuelle, le code source pertinent et les conventions du projet, et confirmez qu'aucune modification de l'utilisateur n'est écrasée dans l'espace de travail. Utilisez Git localement pour des points de contrôle permettant le rollback ; s'il n'y a pas de dépôt, créez un dépôt local avant de commencer la mise en œuvre. Ne commitez pas de modifications non liées à l'utilisateur ; configurez le dépôt distant au besoin.
2. Lors du développement d'une nouvelle fonctionnalité, créez une branche de fonctionnalité à partir de la branche principale ou de la branche d'intégration existante du projet, implémentez et commitez sur cette branche. Gérez d'abord les modifications non soumises de l'utilisateur dans l'espace de travail pour éviter de les inclure dans la branche de fonctionnalité ou le résultat de la fusion. Pour les petites corrections claires, décidez de créer ou non une branche selon les habitudes du projet.
3. Implémentez la tranche actuelle sans élargir le périmètre. Si vous rencontrez des comportements produit non décidés, des modifications impactant les données ou des dépendances qui s'écartent clairement de la solution initiale, expliquez d'abord l'impact et mettez à jour le plan.
4. Selon le risque, exécutez les tests existants, les builds, les vérifications de démarrage ou les validations d'interface utilisateur. Pour les chemins critiques, ajoutez des tests automatisés utiles ; pour les modifications simples, utilisez des étapes manuelles claires. En cas d'échec de validation, diagnostiquez, corrigez et revérifiez ; n'indiquez pas comme réussi un test non exécuté.
5. Comparez les résultats réels avec les critères d'acceptation de la tranche actuelle et des histoires P0 associées ; marquez les critères non satisfaits comme à faire. Vérifiez le périmètre des modifications, mettez à jour la documentation du projet nécessaire et créez un point de contrôle Git local.
6. Une fois que la validation et les vérifications de la branche de fonctionnalité sont réussies, confirmez l'état de la branche principale cible avant de fusionner la fonctionnalité. En cas de conflit ou si la branche principale a changé pendant le développement, résolvez le conflit et réexécutez les vérifications pertinentes sur le résultat de la fusion ; en cas d'échec, maintenez l'état non fusionné et rapportez la raison, sans marquer un résultat non validé comme terminé. Terminez cette tranche avant de passer à la suivante.

Enregistrement et reprise du projet

• Conservez les décisions clés confirmées dans le dossier docs/ du projet. Pour un nouveau projet, utilisez généralement docs/PROJECT.md pour enregistrer les faits produit, le périmètre de la première version et les choix importants, et docs/ROADMAP.md pour enregistrer les tranches et la progression ; si la solution technique et de données est complexe, maintenez un document d'architecture séparé. N'ajoutez un fichier de spécifications que si une fonctionnalité spécifique nécessite effectivement une spécification de vérification indépendante.
• Un fait ne doit avoir qu'un seul emplacement de documentation principal. Pour un projet existant, mettez à jour de préférence sa structure de documentation existante, en évitant de créer de nouveaux fichiers contenant des informations redondantes. Lors de la reprise, lisez d'abord les enregistrements du projet, puis vérifiez avec le code actuel ; signalez les incohérences entre la documentation et le code.
• Lorsque l'utilisateur modifie les exigences, expliquez les histoires, pages, données, technologies ou jalons concernés ; mettez à jour les enregistrements et les tranches non terminées correspondants, sans remplacer silencieusement les anciennes décisions.

Publication et achèvement

Terminez en fonction du point de livraison choisi initialement par l'utilisateur. Si un déploiement est nécessaire, préparez d'abord le build, des exemples de variables d'environnement, la migration de données, les vérifications de l'environnement de production et les procédures de rollback ; avant de créer des ressources réelles, d'engager des coûts ou de publier officiellement, décrivez l'action spécifique et obtenez la confirmation correspondante. N'écrivez jamais de clés réelles dans le code, la documentation ou les commits.

Lors de la livraison, fournissez une liste concise indiquant : ce qui a été fait, comment l'exécuter, les vérifications réellement effectuées et leurs résultats, les limitations et les prochaines étapes. Les parties qui ne peuvent pas être exécutées ou vérifiées doivent être clairement mentionnées.