vibe-build

Vibe Build

Un workflow complet de construction que l'agent exécute de manière autonome. L'utilisateur prend les décisions produit ; vous prenez les décisions de processus. Ne demandez jamais à l'utilisateur d'expliquer le workflow — suivez-le. Interrogez l'utilisateur uniquement sur ce qu'il faut construire, ses préférences et pour approbation aux étapes clés.

La règle unique

Décisions produit = apport de l'utilisateur. Processus = le vôtre. Avant de demander quoi que ce soit à l'utilisateur, vérifiez s'il s'agit d'une décision produit. Si ce n'est pas le cas, décidez vous-même et continuez.

Phase 0 — Bootstrap (nouveaux projets uniquement)

1. Identifiez la stack. Si le projet est complètement indéfini, posez exactement une question : "Que devons-nous construire ? (une phrase suffit)". Ne faites pas d'interview.
2. Recherchez la stack vous-même : versions actuelles des frameworks, configuration recommandée et structure de projet standard, en utilisant la recherche web et la documentation des frameworks (utilisez la capacité de recherche de documentation du projet ou la recherche web). Résumez les décisions en 5 lignes maximum — ne collez pas de longs murs de recherche à l'utilisateur.
3. Écrivez AGENTS.md à la racine du projet en utilisant le modèle dans references/agentsmd-template.md. C'est la constitution du projet : chaque phase ultérieure le lit avant les décisions structurelles, afin que l'utilisateur n'ait jamais à réexpliquer les conventions.
4. Installez les skills temporaires dont le projet a besoin (max 5), en suivant references/temp-skills.md. Ignorez complètement l'installation de skill si le projet est simple ou si vos skills existants le couvrent.
5. Rapportez le bootstrap en ≤ 15 lignes, présentez votre plan numéroté proposé, et attendez l'approbation avant d'écrire du code pour le projet.

Phase 1 — Planification

• Produisez un plan numéroté et cadré. Petites tâches réalisables en une session, éléments explicitement reportés pour plus tard.
• Obtenez une approbation explicite. Si l'utilisateur modifie le plan, les modifications l'emportent.
• Méfiez-vous de l'entrelacement : ne commencez pas à construire tant que le plan est encore ouvert.

Phase 2 — Construction

• Suivez une discipline de test lorsque cela correspond au projet : tests pour la logique, vérification manuelle pour le code jetable. N'inventez pas de frameworks de tests lourds pour des constructions simples ; ne sautez pas les tests pour une logique dont un bug serait dommageable.
• Gardez les dépendances minimales. Chaque dépendance est un passif que l'utilisateur hérite — privilégiez la bibliothèque standard / zéro-dépendance à moins d'un gain clair.
• Vérifiez AGENTS.md avant chaque décision structurelle. Commitez en petites étapes nommées pour que le travail soit bisectable.

Phase 3 — Vérification (avant de déclarer "fini")

Exécutez le projet, puis prouvez qu'il fonctionne :

• UI existe → parcourez-la dans un vrai navigateur (Playwright ou l'outil navigateur de votre agent), vérifiez les erreurs console, validez les flux principaux de bout en bout.
• Web UI → auditez la qualité d'accessibilité et d'interaction (états de focus, formulaires, mode sombre, tactile) : utilisez un skill de revue des directives de conception si disponible, sinon vérifiez vous-même.
• Authentification, secrets, paiements ou saisie utilisateur touchés → faites un passage sécurité : validation des entrées, gestion des secrets (ne committez jamais de secrets ; utilisez la substitution d'environnement), privilèges minimaux par défaut.
• Preuves avant affirmations : rapportez ce qui a été exécuté et ce qui a réussi, ou admettez l'échec et corrigez d'abord.

Phase 4 — Livraison

• "Déployer / mettre en ligne / lien de prévisualisation" → déployez via le chemin documenté du projet. Pour les projets hébergeables sur Vercel, faites un git-push vers le projet lié, en dernier recours utilisez vercel deploy --temporary s'il n'y a pas de connexion, puis renvoyez l'URL.
• Pull requests : corps concis — ce qui a changé, pourquoi, comment tester — pas de narration du diff.
• Un commit "fini" signifie que la construction + les tests passent sur les preuves que vous venez de rassembler.

Phase 5 — Hygiène des skills temporaires

Les skills temporaires (Phase 0 étape 4) sont limités au projet. À la fin du projet ou lorsqu'un skill temporaire s'avère largement utile, recommandez de le promouvoir dans le répertoire de skills partagés de l'utilisateur (ou de le supprimer). Ne laissez jamais les skills temporaires se transformer silencieusement en installations globales permanentes.

Économie de tokens (toutes phases)

Lisez la plage de fichiers la plus petite suffisante ; ne relisez pas des fichiers entiers déjà vus. Résumez une phase terminée une fois au lieu de décrire chaque étape. Préférez exécuter des scripts et outils plutôt que de coller leur contenu dans la conversation. Laissez les skills se charger paresseusement par déclencheur — ne déversez jamais le corps d'un skill dans la conversation.

Références

• references/agentsmd-template.md — à lire et remplir pendant la Phase 0 étape 3.
• references/temp-skills.md — à lire pendant la Phase 0 étape 4, avant d'installer un skill temporaire.