Démarrage VibeCoding

Que fait Démarrage VibeCoding ?

Utilisez cette compétence pour donner à Codex un système d'ingénierie léger, de la première session de projet à la livraison et à l'observation. Le résultat souhaité est un projet qu'une session ultérieure pourra comprendre, examiner, vérifier, accepter et poursuivre en toute sécurité sans avoir à rejouer l'intégralité de la conversation.

Première action

Lisez le fichier AGENTS.md du projet, puis suivez cet ordre de contexte chaud :

1. docs/INDEX.md
2. docs/CURRENT.md
3. docs/PRODUCT.md
4. docs/PRD.md
5. docs/ACCEPTANCE.md

Lisez docs/CODEMAP.md, les ADR actifs, les plans, les journaux de travail, les normes et les preuves locales brutes uniquement lorsque la tâche en a besoin. Si le squelette des six documents est manquant, utilisez le mode INIT de la compétence compagnon vibecoding-project-knowledge avant l'implémentation.

Limite de projet non négociable

• Chaque projet reçoit le même squelette minimum : AGENTS.md, docs/INDEX.md, PRODUCT.md, PRD.md, ACCEPTANCE.md, CURRENT.md et CODEMAP.md.
• La complexité modifie la profondeur des documents et la force des barrières ; elle ne supprime pas le squelette.
• PRODUCT.md explique pourquoi, PRD.md explique quoi et ACCEPTANCE.md explique comment le prouver. Ne fusionnez pas silencieusement ces responsabilités.
• Mettez à jour PRD.md lorsque la session modifie une exigence, une fonctionnalité, un non-objectif, une contrainte ou un scénario utilisateur significatif.
• Conservez les sessions brutes, journaux, tentatives échouées, investigations et preuves localement par défaut dans .project-memory/. Promouvez uniquement des exemples édités et intentionnellement organisés vers docs/examples/.
• Préférez les capacités existantes du projet, la bibliothèque standard, les SDK/API/outils officiels, les projets open source matures, les paquets, les adaptateurs ou la composition avant l'infrastructure personnalisée.
• Ne construisez pas de base de données mémoire, base de données vectorielle, moteur de recherche, framework de test, framework de déploiement, service CI ou backend d'observabilité dans le cadre de ce workflow.

Barrières d'ingénierie

Utilisez le même vocabulaire pour chaque projet tout en adaptant la profondeur au risque :

G0 Périmètre
→ G1 Intention
→ G2 Réutilisation
→ G3 Plan
→ G4 Construction
→ G5 Revue Adversaire
→ G6 Vérification
→ G7 Acceptation Humaine
→ G8 Livraison
→ G9 Observation

G0 Périmètre

Classez le travail comme application/produit, intégration/adaptateur, ou infrastructure/sécurité/exécution. Plus le travail est proche de l'infrastructure, plus les preuves de réutilisation, de revue et de récupération doivent être solides.

G1 Intention

Rendez la chaîne explicite :

PRODUIT (Pourquoi) → PRD (Quoi) → ACCEPTATION (Comment prouver)

Enregistrez le problème, les utilisateurs, les états actuel et souhaité, les exigences fonctionnelles, les non-objectifs, les contraintes, l'acceptation et les risques avant l'implémentation.

G2 Réutilisation

Pour toute capacité générale non triviale, cherchez avant de construire et décidez dans cet ordre :

UTILISER → ADAPTER → COMPOSER → CONSTRUIRE → STOPPER

Si CONSTRUIRE est sélectionné, enregistrez les alternatives recherchées, les voies de réutilisation rejetées, la responsabilité de maintenance et la méthode d'acceptation du propriétaire dans un ADR. La capacité d'un modèle à écrire du code n'est pas une preuve que le code personnalisé est le bon choix.

G3 Plan

Décomposez le travail complexe en petites étapes avec un point de vérification après chaque étape. Arrêtez-vous et replanifiez lorsque le périmètre, l'architecture ou le risque change de manière substantielle.

G4 Construction

Gardez l'implémentation petite et réversible. Utilisez la chaîne d'outils existante et évitez les abstractions, dépendances et infrastructures spéculatives.

G5 Revue Adversaire

Un relecteur indépendant examine PRODUCT.md, PRD.md, ACCEPTANCE.md, les décisions actives, la structure pertinente, le diff et les tests. Recherchez les omissions, les mauvaises hypothèses, les régressions, les capacités dupliquées, la sur-conception, les risques de sécurité/données, les lacunes de test et les échecs de rollback. L'auteur ne doit pas être le relecteur final pour un changement important.

G6 Vérification

Couvrez les chemins normal, d'erreur, limite, d'entrée invalide, de régression et de récupération en proportion du risque. Signalez les preuves machine et une explication lisible par le propriétaire ; un coche vert ne prouve que l'invariant qu'il vérifie réellement.

G7 Acceptation Humaine

Le propriétaire confirme que le résultat est le produit attendu et que son comportement observable est compréhensible. Les vérifications automatisées et la revue indépendante ne remplacent pas cette étape.

G8 Livraison

Enregistrez la version, le dernier état connu bon, les notes de version, la sauvegarde, la méthode de rollback, le risque de migration et la cible de livraison exacte avant une utilisation réelle.

G9 Observation

Après la livraison, observez l'état de santé et les preuves utilisateur. Continuez uniquement lorsque le système est sain ; arrêtez-vous et effectuez un rollback ou un roll forward lorsque les preuves montrent un problème. Réinjectez le résultat dans les tests, le journal de travail, l'ADR, l'intention du produit, l'acceptation ou un post-mortem selon le cas.

Clôture des connaissances

À la fin de chaque session substantielle, utilisez le mode UPDATE de la compétence compagnon vibecoding-project-knowledge :

1. Conservez les détails bruts de la session et les sorties volumineuses dans le répertoire local .project-memory/.
2. Organisez CURRENT.md et les documents actifs pertinents.
3. Mettez à jour CODEMAP.md lorsque la structure change.
4. Mettez à jour PRD.md lorsque les exigences, fonctionnalités, non-objectifs, contraintes ou scénarios utilisateur changent.
5. Enregistrez les choix matériels dans un ADR.
6. Mettez à jour les index et le journal de travail.
7. Exécutez les audits déterministes pertinents.

N'affirmez pas la complétion sans preuve machine, une explication lisible par un humain et une méthode d'acceptation du propriétaire.

Références

• Lisez Standard v1.3 pour les règles normatives et la limite de livraison.
• Lisez la compétence compagnon vibecoding-project-knowledge pour les procédures INIT, UPDATE ou AUDIT.